From mailman-bounces@ietf.org Sun Aug 1 07:34: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 HAA13625 for ; Sun, 1 Aug 2004 07:34: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 1BrCal-00057A-As for megaco-archive@lists.ietf.org; Sun, 01 Aug 2004 05:25:19 -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: Sun, 01 Aug 2004 05:06:44 -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 Aug 2 07:04:21 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 HAA29435 for ; Mon, 2 Aug 2004 07:04:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BraUA-0004Jk-9h; Mon, 02 Aug 2004 06:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BraTY-0003yJ-0t for megaco@megatron.ietf.org; Mon, 02 Aug 2004 06:55: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 GAA29111 for ; Mon, 2 Aug 2004 06:55:25 -0400 (EDT) Received: from mailrelay1.alcatel.de ([194.113.59.55] helo=mailrelay2.alcatel.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BraWN-0003Mp-IR for megaco@ietf.org; Mon, 02 Aug 2004 06:58:24 -0400 Received: from [149.204.189.77] (sls1cd.ad1.ad.alcatel.com [149.204.189.77]) by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i72AsrRE029753 for ; Mon, 2 Aug 2004 10:54:53 GMT Message-ID: <410E1D3F.1090602@alcatel.de> Date: Mon, 02 Aug 2004 12:53:51 +0200 From: Carsten Waitzmann User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org References: <4108BC88.9020906@alcatel.de> In-Reply-To: <4108BC88.9020906@alcatel.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Alcanet-virus-scanned: i72AsrRE029753 at mailrelay2.alcatel.de X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [Megaco] Question about network package, ServiceChange 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 Resent - because I am not sure whether message got through ... Carsten Hi, A MGW with transmission ports houses mulitple "network terminations" (terminology according to E.11 network package). The terminology of network termination is exclusivly used in the textual description of this package, thus one could conclude that this packet applies to: - Packet (IP, ATM or possibly others) *network terminations* as well as - Switched Circuit *network terminations*. Looking to the package itself, it looks to me that the intention of the package is in fact more packet network termination related. Is it allowed to apply the package for switched circuit network terminations as well? If not, my suggestion is to add "packet" to the description: "This package defines properties of *packet* network terminations independent of network type". The network package defines properties, events and statistics. The netfail event especially is used to notify per termination (if the MGC previously has subscribed for) the MGC "upon detection of a failure due to external or internal network reasons". Assuming that a transmission port of the MGW fails the MG will send a bunch of netfail events related to all concerned network terminations. Additionally I assume that the MG will notify the MGC by means of ServiceChange (Method=Forced, Reason=transmission failure) for all concerned network terminations. Is a netfail event subscription by the MGC making it obsolete for the MG to send ServiceChange? If not, what is in general the added value of the netfail event compared to an anyhow sent ServiceChange notification? thanks Carsten Carsten Waitzmann wrote: > <<< No Message Collected >>> > > _______________________________________________ > Megaco mailing 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 Aug 2 10:07:04 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 KAA08199 for ; Mon, 2 Aug 2004 10:07:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrdOo-0004dT-8Q; Mon, 02 Aug 2004 10:02:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrdMQ-0003CV-LZ for megaco@megatron.ietf.org; Mon, 02 Aug 2004 10:00: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 KAA07863 for ; Mon, 2 Aug 2004 10:00:16 -0400 (EDT) Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrdPH-0005t4-D2 for megaco@ietf.org; Mon, 02 Aug 2004 10:03:16 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i72Dxia15870 for ; Mon, 2 Aug 2004 09:59:44 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Aug 2004 09:59:45 -0400 Message-ID: From: "Kevin Boyle" To: megaco@ietf.org Subject: RE: [Megaco] Question about network package, ServiceChange Date: Mon, 2 Aug 2004 09:59:43 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 The nt package is applicable to any termination type. Note that the tdmc package extends nt. Note that the network can fail without the termination going out of service. ServiceChange indicates changes of the ServiceState. Netfail indicates failure of the network. While the two can be related, they do not have to be. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] Sent: Monday, August 02, 2004 6:54 AM To: megaco@ietf.org Subject: [Megaco] Question about network package, ServiceChange Resent - because I am not sure whether message got through ... Carsten Hi, A MGW with transmission ports houses mulitple "network terminations" (terminology according to E.11 network package). The terminology of network termination is exclusivly used in the textual description of this package, thus one could conclude that this packet applies to: - Packet (IP, ATM or possibly others) *network terminations* as well as - Switched Circuit *network terminations*. Looking to the package itself, it looks to me that the intention of the package is in fact more packet network termination related. Is it allowed to apply the package for switched circuit network terminations as well? If not, my suggestion is to add "packet" to the description: "This package defines properties of *packet* network terminations independent of network type". The network package defines properties, events and statistics. The netfail event especially is used to notify per termination (if the MGC previously has subscribed for) the MGC "upon detection of a failure due to external or internal network reasons". Assuming that a transmission port of the MGW fails the MG will send a bunch of netfail events related to all concerned network terminations. Additionally I assume that the MG will notify the MGC by means of ServiceChange (Method=Forced, Reason=transmission failure) for all concerned network terminations. Is a netfail event subscription by the MGC making it obsolete for the MG to send ServiceChange? If not, what is in general the added value of the netfail event compared to an anyhow sent ServiceChange notification? thanks Carsten Carsten Waitzmann wrote: > <<< No Message Collected >>> > > _______________________________________________ > Megaco mailing 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 Wed Aug 4 03:34: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 DAA16074 for ; Wed, 4 Aug 2004 03:34: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 1BsGGR-0006rb-CP; Wed, 04 Aug 2004 03:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsGFO-0006mo-Us for megaco@megatron.ietf.org; Wed, 04 Aug 2004 03:31: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 DAA15980 for ; Wed, 4 Aug 2004 03:31:37 -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 1BsGIc-0002sS-Ns for megaco@ietf.org; Wed, 04 Aug 2004 03:35:00 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.ccpu.com (Postfix) with ESMTP id 4379634687C for ; Wed, 4 Aug 2004 00:31:31 -0700 (PDT) Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (VaMailArmor-2.0.1.16) id 23293-41CF3CD0; Wed, 04 Aug 2004 00:31:29 -0700 Received: from Mahesh (unknown [172.25.0.61]) by smtp.ccpu.com (Postfix) with ESMTP id AE617346801 for ; Wed, 4 Aug 2004 00:31:27 -0700 (PDT) From: "Mahesh" To: Date: Wed, 4 Aug 2004 13:01:22 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcR59Qpx/SpUyvwAQwWDl6Qa51ySRg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: <20040804073127.AE617346801@smtp.ccpu.com> X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.26.0.10; VDF: 6.26.0.58; host: smtp) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [Megaco] H 2.48.5 (Transport over ATM) 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="===============0064330839==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0064330839== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01C47A23.25672FE0" This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C47A23.25672FE0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit HI, Could you please explain the concept of Megaco over MTP3B and ATM(H.248.5) . In such cases what will be the actual destination address . Could you please give examples for the call flow for the same . Thanks in Advance Mahesh --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002 ------=_NextPart_000_0055_01C47A23.25672FE0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

HI,

 

Could you please explain the concept of Megaco over = MTP3B and ATM(H.248.5) .

In such cases what will be the actual destination = address .

Could you please give examples for the call flow for = the same .

 

Thanks in Advance

Mahesh

 


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002

------=_NextPart_000_0055_01C47A23.25672FE0-- --===============0064330839== 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 --===============0064330839==-- From megaco-bounces@ietf.org Wed Aug 4 14:59: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 OAA28904 for ; Wed, 4 Aug 2004 14:59: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 1BsQl7-0001cX-HC; Wed, 04 Aug 2004 14:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQVe-0006KW-1p for megaco@megatron.ietf.org; Wed, 04 Aug 2004 14:29: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 OAA26411 for ; Wed, 4 Aug 2004 14:29:04 -0400 (EDT) Message-Id: <200408041829.OAA26411@ietf.org> Received: from host217-45-197-114.in-addr.btopenworld.com ([217.45.197.114] helo=aegir.engineering.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsQYx-0005W2-5R for megaco@ietf.org; Wed, 04 Aug 2004 14:32:33 -0400 Received: from localhost ([127.0.0.1]) by aegir.engineering.newport-networks.com; Wed, 4 Aug 2004 19:25:31 +0100 From: "Ed Luff" To: "'Brad Steinka'" , Subject: RE: [Megaco] ToS byte marking Date: Wed, 4 Aug 2004 14:25:31 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcRvhDBNfZfb9S/YQ8qO4GI4CJYyZAKmdIsQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.2 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c 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="===============1667492971==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1667492971== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01C47A2E.E6124DA0" This is a multi-part message in MIME format. ------=_NextPart_000_0064_01C47A2E.E6124DA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Brad, We have defined the 'QoSOverride' property in our Megaco package for explicitly setting the ToS bits within the RTP media stream. If this property is not set, the MG uses the Media and Codec types specified in the SDP to generate the mapping. If neither of the above is applicable, the MG will use a static mapping table which is configured by the operator. The next release of our product will support setting the full 6 QoS bits. Hope this is useful. Cheers, Ed QoS Override PropertyId: QoSOverride(0x0005) Description: The ToS mapping to use for this termination. Type: octet string. In the text encoding of MEGACO/H.248 this is represented as a string, that is the values are 0 to 7. Possible Values: as configured in the MGC. Default: No override is applied. Defined in: LocalControl. Characteristics: read-write. _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Brad Steinka Sent: Wednesday, July 21, 2004 6:11 PM To: megaco@ietf.org Subject: [Megaco] ToS byte marking Hi, Is there a mechanism in place either in a MEGACO package or through SDP to specify what the TOS byte should be set too on packets transmitted by an MG to facilitate DIFFServ/Qos behavior in the core network? I looked that the SDP attributes at IANA and didn't see anything that fit the bill. Thanks brad ------=_NextPart_000_0064_01C47A2E.E6124DA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brad,

 

We have defined = the ‘QoSOverride’ property in our Megaco package for explicitly = setting the ToS bits within the RTP media stream.  If this property is not = set, the MG uses the Media and Codec types specified in the SDP to generate = the mapping.  If neither of the above is applicable, the MG will use a static mapping = table which is configured by the operator.  The next release of our = product will support setting the full 6 QoS bits.  Hope this is = useful.

 =

Cheers,

Ed

QoS = Override

PropertyId: QoSOverride(0x0005)

Description: The ToS mapping to use for this termination. =

Type: octet string.  In the text encoding of MEGACO/H.248 = this is represented as a string, that is the values are 0 to 7. =

Possible Values: as configured in the MGC.   =

Default: No override is applied.

Defined in: LocalControl.

Characteristics: read-write.

 

 

From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Brad Steinka
Sent: Wednesday, July 21, = 2004 6:11 PM
To: megaco@ietf.org
Subject: [Megaco] ToS = byte marking

 

Hi,

 

Is there a mechanism in place either in a MEGACO = package or through SDP to specify what the TOS byte should be set too on packets transmitted by an MG  to facilitate DIFFServ/Qos behavior in the = core network?   

 

I looked that the SDP attributes at IANA and = didn’t see anything that fit the bill.

 

Thanks

brad

------=_NextPart_000_0064_01C47A2E.E6124DA0-- --===============1667492971== 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 --===============1667492971==-- From megaco-bounces@ietf.org Sat Aug 7 16:11:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20262 for ; Sat, 7 Aug 2004 16:11:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtXUh-0000vX-RD; Sat, 07 Aug 2004 16: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 1BtXSq-0000YZ-PC for megaco@megatron.ietf.org; Sat, 07 Aug 2004 16:06:48 -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 QAA19979 for ; Sat, 7 Aug 2004 16:06:46 -0400 (EDT) Received: from [212.179.22.140] (helo=imss) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtXWo-0000vn-7x for megaco@ietf.org; Sat, 07 Aug 2004 16:10:55 -0400 Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan Messaging Security Suite; Tue, 27 Jul 2004 17:03:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jul 2004 16:58:04 +0300 Message-ID: Thread-Topic: MEGACO: Question about H.248.25 - bcasaddr package Thread-Index: AcRv9B6f8olLa7dbQxy6avUWDreM0QD7Oz2g From: "Nurit Shenhar" To: "Kevin Boyle" , X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Subject: [Megaco] MEGACO: Question about H.248.25 - bcasaddr package 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 Hi While looking at H.248.25 and the correction to it from the ITU site (published at 03/2004), I found out that the list of address coding in the 'addr' event parameter and the 'addr' signal parameter is not the same. In the signal it is: DTMF 0x0001 MF 0x0002 DP 0x0003 While in the event: MF 0x0001 DTMF 0x0002 DP 0x0003 Is it intentional? If not, can it be corrected to be the same order? Thanks, Nurit ***************************************************************************= ********************************* 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. ***************************************************************************= ******************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 9 10:27: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 KAA02341 for ; Mon, 9 Aug 2004 10:27:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuB44-0007Dm-Nt; Mon, 09 Aug 2004 10:23:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuB2q-0004Y1-NS for megaco@megatron.ietf.org; Mon, 09 Aug 2004 10:22: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 KAA02181 for ; Mon, 9 Aug 2004 10:22:34 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuB78-0005i3-SX for megaco@ietf.org; Mon, 09 Aug 2004 10:27:06 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i79EMVAh029526 for ; Mon, 9 Aug 2004 16:22:31 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Aug 2004 16:22:31 +0200 Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PR28W292; Mon, 9 Aug 2004 16:22:31 +0200 Received: from amrod (amrod [134.138.176.177]) by super.du.uab.ericsson.se (8.10.1/8.10.1/erix-1.8) with ESMTP id i79EMUn05914 for ; Mon, 9 Aug 2004 16:22:31 +0200 (MET DST) Date: Mon, 9 Aug 2004 16:22:30 +0200 (CEST) X-Sybari-Trust: 9b54be02 74470f8f b57bedf5 00000138 From: Hakan Mattsson To: megaco@ietf.org Subject: Re: [Megaco] Ambiguity in ABNF of indAudauditReturnParameter in H.248 v2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 09 Aug 2004 14:22:31.0654 (UTC) FILETIME=[4EA07860:01C47E1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 CHG> Hello Francois, CHG> CHG> CHG> I'm having some problem understanding what the ambiguity is. Please see my comments below. CHG> CHG> Regards, Christian CHG> CHG> CHG> Francois Plagnard wrote: CHG> CHG> CHG> > Hello, CHG> > CHG> > CHG> > In H.248v2, in indAudauditReturnParameter ABNF, according to my CHG> > understanding, there are several ambiguities. CHG> > CHG> > CHG> > For example, CHG> > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT CHG> > means for me that you have only 1 instance of indAudmediaParm. CHG> > CHG> CHG> [CHG] Yes I agree. The Megaco standard is not consistent in this regard. In the ASN.1 encoding it is allowed with one each of streamMode, reserveValue, reserveGroup and propertyParms: IndAudLocalControlDescriptor ::= SEQUENCE { streamMode NULL OPTIONAL, reserveValue NULL OPTIONAL, reserveGroup NULL OPTIONAL, propertyParms SEQUENCE OF IndAudPropertyParm OPTIONAL, ... } while the textual encoding only allows exactly one indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT ; at-most-once per item ; and either streamParm or streamDescriptor but not both indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / indAudterminationStateDescriptor) CHG> CHG> > CHG> > CHG> > But, its definition is : CHG> > ; at-most-once per item CHG> > ; and either streamParm or streamDescriptor but not both CHG> > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / CHG> > indAudterminationStateDescriptor) CHG> > which implies that you may have several instances ! CHG> > CHG> CHG> [CHG] Doesn't this imply that you "choose" one instance from the alternatives? CHG> CHG> > CHG> > CHG> > You have the same ambiguity with : CHG> > - indAudlocalParm CHG> > - indAudterminationStateParm CHG> > ... CHG> > CHG> > CHG> > May we have 1 or several instances of them ? CHG> > And, if we may have several instances, how are they separated ? CHG> > CHG> > CHG> > Best regards, CHG> > CHG> > CHG> > =================================================================== CHG> > Francois Plagnard, CHG> > Netbricks CHG> > 31 rue Jean Rostand CHG> > 91893 ORSAY -- FRANCE CHG> > Email: francois.plagnard at netbricks.com - WEB : www.netbricks.com CHG> > Tel: +33 (0)1 69 33 12 57 -- Fax: +33 (0)1 69 85 54 26 CHG> > =================================================================== _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 9 11:58: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 LAA07833 for ; Mon, 9 Aug 2004 11:58: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 1BuCWA-0007cQ-Os; Mon, 09 Aug 2004 11:56:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuCUv-0007U5-UK for megaco@megatron.ietf.org; Mon, 09 Aug 2004 11:55:42 -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 LAA07642 for ; Mon, 9 Aug 2004 11:55:39 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuCZ4-00079I-Vh for megaco@ietf.org; Mon, 09 Aug 2004 12:00:12 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i79FtRAh018883 for ; Mon, 9 Aug 2004 17:55:27 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Aug 2004 17:55:26 +0200 Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PR28W8TV; Mon, 9 Aug 2004 17:55:26 +0200 Received: from amrod (amrod [134.138.176.177]) by super.du.uab.ericsson.se (8.10.1/8.10.1/erix-1.8) with ESMTP id i79FtQn06665 for ; Mon, 9 Aug 2004 17:55:26 +0200 (MET DST) Date: Mon, 9 Aug 2004 17:55:26 +0200 (CEST) X-Sybari-Trust: 3a01e3db 74470f8f 0dc78a90 00000138 From: Hakan Mattsson To: megaco@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by super.du.uab.ericsson.se id i79FtQn06665 X-OriginalArrivalTime: 09 Aug 2004 15:55:26.0955 (UTC) FILETIME=[49C3E3B0:01C47E29] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] IndAudlocalControlDescriptor inconsistency 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 In the ASN.1 specification of IndAudLocalControlDescriptor it is allowed with one each of stream mode, reserve value and reserve group plus a any number of package names: IndAudLocalControlDescriptor ::=3D SEQUENCE=20 {=20 streamMode NULL OPTIONAL,=20 reserveValue NULL OPTIONAL,=20 reserveGroup NULL OPTIONAL,=20 propertyParms SEQUENCE OF IndAudPropertyParm OPTIONAL,= =20 ...=20 }=20 =20 IndAudPropertyParm ::=3D SEQUENCE=20 {=20 name PkgdName,=20 ...=20 }=20 =20 while it in the ABNF specification of indAudlocalControlDescriptor is limited to be exactly one of stream mode, reserve value, reserve group and package name: indAudlocalControlDescriptor =3D LocalControlToken =20 LBRKT indAudlocalParm RBRKT=20 =20 ; at-most-once per item=20 indAudlocalParm =3D ( ModeToken / pkgdName /=20 ReservedValueToken /=20 ReservedGroupToken )=20 For example this means that it is possible to have both stream mode and package name in ASN.1, while this is not allowed in ABNF. To me this looks like a bug in the Megaco standard as the ASN.1 encoding and ABNF encoding is not semantically equivalent in this case. I suggest that the ABNF should be changed to the following in order to be compliant with ASN.1: indAudlocalControlDescriptor =3D LocalControlToken =20 LBRKT indAudlocalParm *(COMMA indAudlocalParm) R= BRKT=20 I would appreciate if someone on the list could clarify whether this Megaco bug is in ABNF or ASN.1. /H=E5kan --- H=E5kan Mattsson, Ericsson AB High Availability Software, DBMS Internals http://www.erlang.org/~hakan/ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 9 12:45: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 MAA12101 for ; Mon, 9 Aug 2004 12:45: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 1BuD1E-0004Xn-CW; Mon, 09 Aug 2004 12:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuCun-0003mr-Hs for megaco@megatron.ietf.org; Mon, 09 Aug 2004 12:22: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 MAA09517 for ; Mon, 9 Aug 2004 12:22:22 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuCz8-0007du-4u for megaco@ietf.org; Mon, 09 Aug 2004 12:26:56 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i79GMIWR007985 for ; Mon, 9 Aug 2004 18:22:18 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Aug 2004 18:22:18 +0200 Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QF45FB24; Mon, 9 Aug 2004 18:22:18 +0200 Received: from amrod (amrod [134.138.176.177]) by super.du.uab.ericsson.se (8.10.1/8.10.1/erix-1.8) with ESMTP id i79GMHn07017 for ; Mon, 9 Aug 2004 18:22:17 +0200 (MET DST) Date: Mon, 9 Aug 2004 18:22:17 +0200 (CEST) X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Hakan Mattsson To: megaco@ietf.org Subject: Re: [Megaco] Ambiguity in ABNF of indAudauditReturnParameter in H.248 v2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by super.du.uab.ericsson.se id i79GMHn07017 X-OriginalArrivalTime: 09 Aug 2004 16:22:18.0579 (UTC) FILETIME=[0A5E3230:01C47E2D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable 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 Please, forget about my previous mail with this subject and read the one with the subject "IndAudlocalControlDescriptor inconsistency" instead. /H=E5kan --- H=E5kan Mattsson, Ericsson AB High Availability Software, DBMS Internals http://www.erlang.org/~hakan/ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 9 17:53: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 RAA22875 for ; Mon, 9 Aug 2004 17:53: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 1BuHmN-0001pV-5U; Mon, 09 Aug 2004 17:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuHYb-0006lA-0g for megaco@megatron.ietf.org; Mon, 09 Aug 2004 17:19:49 -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 RAA19336 for ; Mon, 9 Aug 2004 17:19:46 -0400 (EDT) Received: from lin1-118-34-24.ciena.com ([63.118.34.24] helo=ripley.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuHd0-00028w-1a for megaco@ietf.org; Mon, 09 Aug 2004 17:24:22 -0400 Received: from unknown (HELO CAT01S2.catena.com) (209.29.220.94) by ripley.ciena.com with ESMTP; 09 Aug 2004 17:36:24 -0400 Message-ID: <026543599E95D3428761420B0DF65556021F2DF2@cat01s2b.catena.com> From: "Donak, John" To: "'Christian Groves'" , "'tom.batsele@alcatel.be'" Subject: RE: [Megaco] codec incompatibility Date: Mon, 9 Aug 2004 17:19:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 Is the specific behaviour for codec negotiation specified anywhere within MEGACO? (as in RFC3435 for MGCP). I could not find it. John -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com] Sent: Wednesday, March 03, 2004 5:29 PM To: tom.batsele@alcatel.be Cc: megaco@ietf.org Subject: Re: [Megaco] codec incompatibility Hello Tom, You are allowed to have a different codecs in the local and remote descriptor for a particular stream. It is typical for a bi-directional connections that the same codec is used in either direction but H.248 does not mandate this. If you are concerned that MG1 may support different codecs to MG2 then it is up to negotiation to determine whether a call can take place. In BICC networks this codec negotiation is done at the MGC level. In other network types the MG1 will provide a list of codecs that are sent to the MG2 to choose from. Regards, Christian tom.batsele@alcatel.be wrote: > Hello, > > What should happen in case MGC passes to a MG2 a localDescriptor with a > different codec then in the remoteDescriptor. > I.e MG1 only supports codec 8 and MG2 only supports codec 0. > Which entity is responsible to detect that conversation will not be > possible > > Must the MG generate 510 as described in section 7.1.8 of RFC3015 > > * If ReserveGroup is False and ReserveValue is false, then the MG > SHOULD apply the following rules to resolve Local and Remote to a > single alternative each: > > * The MG chooses the first alternative in Local for which it is able > to support at least one alternative in Remote. > > * If the MG is unable to support at least one Local and one Remote > alternative, it returns Error 510 (Insufficient Resources). > > or should the MGC not send such commands > > Example: > > 14. The MGC will now associate A5555 with a new Context on MG2, and > establish an RTP Stream (i.e, A5556 will be assigned), SendReceive > connection through to the originating user, User 1. The MGC also sets > ring on A5555. > > MGC to MG2: > MEGACO/1 [123.123.123.4]:55555 > Transaction = 50003 { > Context = $ { > Add = A5555 { Media { > Stream = 1 { > LocalControl {Mode = SendReceive} }}, > Events=1234{al/of}, > Signals {al/ri} > }, > Add = $ {Media { > Stream = 1 { > LocalControl { > Mode = SendReceive, > nt/jit=40 ; in ms > }, > Local { > v=0 > c=IN IP4 $ > m=audio $ RTP/AVP 0 > a=ptime:30 > }, > Remote { > v=0 > c=IN IP4 124.124.124.222 > m=audio 2222 RTP/AVP 8 > a=ptime:30 > } ; } > } > } > } > } > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Megaco mailing 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 Aug 10 00:39:37 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 AAA00527 for ; Tue, 10 Aug 2004 00:39:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuONR-0005BI-78; Tue, 10 Aug 2004 00:36:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuOMQ-0004wi-Ds for megaco@megatron.ietf.org; Tue, 10 Aug 2004 00:35:42 -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 AAA00302 for ; Tue, 10 Aug 2004 00:35:30 -0400 (EDT) Received: from [202.54.10.77] (helo=ibnhost.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuOQi-0003HE-96 for megaco@ietf.org; Tue, 10 Aug 2004 00:40:11 -0400 Received: from localhost ([203.199.141.41]) by godwishsec.com (ibnhost.net [202.54.10.77]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 60-md50000000038.tmp for ; Tue, 10 Aug 2004 09:52:11 +0530 Received: from 10.89.224.95 (10.89.224.95) by actiserver.alliancetelephony.com From: "Atul Khandelwal" To: Date: Tue, 10 Aug 2004 10:18:35 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-Spam-Processed: ibnhost.net, Tue, 10 Aug 2004 09:52:11 +0530 (not processed: message from valid local sender) X-MDRemoteIP: 203.199.141.41 X-Return-Path: atul.khandelwal@alliancetelephony.com X-MDaemon-Deliver-To: megaco@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Megaco] MEGACO Software 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 Group, Can any one tell me where can i find a free down load for MEGACO software. Also pls let me know which version of CISCO Call Manager/CISCO BTS supports MEGACO, or any other Softswitch that supports MEGACO. Also is there any difference between context and context id...i mean for one context can we have two context ids, or is it like the call from RG1 to MGC is one context and the call from RG2 to MGC is another, both with separate context ids. Thanks Atul _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Aug 10 01:17: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 BAA03524 for ; Tue, 10 Aug 2004 01:17: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 1BuOxs-0002m8-TH; Tue, 10 Aug 2004 01:14:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuOk9-0000kB-Aq for megaco@megatron.ietf.org; Tue, 10 Aug 2004 01:00: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 BAA02318 for ; Tue, 10 Aug 2004 01:00:12 -0400 (EDT) From: assingh@hss.hns.com Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuOoX-0003jS-Pm for megaco@ietf.org; Tue, 10 Aug 2004 01:04:50 -0400 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 i7A4qPNH016478; Tue, 10 Aug 2004 10:22:25 +0530 (IST) In-Reply-To: Subject: Re: [Megaco] MEGACO Software To: "Atul Khandelwal" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Tue, 10 Aug 2004 10:19:49 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 10/08/2004 10:29:14 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.3 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Atul, Yes one context is created for each MG at MGC. You can visit following link for open source code for Megaco/H.248 www.erlang.org/project/megaco/ Thanks Ashish "Atul Khandelwal" Sent by: cc megaco-bounces@ie tf.org Subject [Megaco] MEGACO Software 08/10/2004 10:18 AM Hi Group, Can any one tell me where can i find a free down load for MEGACO software. Also pls let me know which version of CISCO Call Manager/CISCO BTS supports MEGACO, or any other Softswitch that supports MEGACO. Also is there any difference between context and context id...i mean for one context can we have two context ids, or is it like the call from RG1 to MGC is one context and the call from RG2 to MGC is another, both with separate context ids. Thanks Atul _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco *********************** HSS-Unclassified *********************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Aug 10 13:38: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 NAA16006 for ; Tue, 10 Aug 2004 13:38: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 1BuaFW-0004CF-G1; Tue, 10 Aug 2004 13:17:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bua5A-00010o-35 for megaco@megatron.ietf.org; Tue, 10 Aug 2004 13:06:42 -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 NAA12768 for ; Tue, 10 Aug 2004 13:06:36 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bua9j-0000Nm-12 for megaco@ietf.org; Tue, 10 Aug 2004 13:11:24 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7AH5u207714 for ; Tue, 10 Aug 2004 13:05:56 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Aug 2004 13:05:32 -0400 Message-ID: From: "Kevin Boyle" To: Atul Khandelwal , megaco@ietf.org Subject: RE: [Megaco] MEGACO Software Date: Tue, 10 Aug 2004 13:05:25 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Contexts are identified by their contextID, similar to people being identified by their name. Note that Contexts do not denote connections between the MG and the MGC -- they denote groupings of interconnected terminations. For information about Cisco products, I suggest you contact Cisco. Note that this list is not to be used for commercial purposes. There are many softswitches in the marketplace that use H.248. Kevin -----Original Message----- From: Atul Khandelwal [mailto:atul.khandelwal@alliancetelephony.com] Sent: Tuesday, August 10, 2004 12:49 AM To: megaco@ietf.org Subject: [Megaco] MEGACO Software Hi Group, Can any one tell me where can i find a free down load for MEGACO software. Also pls let me know which version of CISCO Call Manager/CISCO BTS supports MEGACO, or any other Softswitch that supports MEGACO. Also is there any difference between context and context id...i mean for one context can we have two context ids, or is it like the call from RG1 to MGC is one context and the call from RG2 to MGC is another, both with separate context ids. Thanks Atul _______________________________________________ Megaco mailing 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 Aug 10 21:27:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22342 for ; Tue, 10 Aug 2004 21:27:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buhk2-0001pn-HS; Tue, 10 Aug 2004 21:17:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buhe2-0000IM-IU for megaco@megatron.ietf.org; Tue, 10 Aug 2004 21:11: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 VAA21543 for ; Tue, 10 Aug 2004 21:11:08 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuhiV-0002zx-BN for megaco@ietf.org; Tue, 10 Aug 2004 21:15:59 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7B1AuPA014418 for ; Wed, 11 Aug 2004 03:10:57 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 03:10:56 +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 PR29DQDH; Wed, 11 Aug 2004 03:10:56 +0200 Received: from ericsson.com (wap-ws.epa.ericsson.se [146.11.22.17]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PVK82PBK; Wed, 11 Aug 2004 11:10:52 +1000 Message-ID: <41197244.1050105@ericsson.com> Date: Wed, 11 Aug 2004 11:11:32 +1000 X-Sybari-Trust: 5205f84e 74470f8f d235b554 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: "Donak, John" Subject: Re: [Megaco] codec incompatibility References: <026543599E95D3428761420B0DF65556021F2DF2@cat01s2b.catena.com> In-Reply-To: <026543599E95D3428761420B0DF65556021F2DF2@cat01s2b.catena.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Aug 2004 01:10:56.0931 (UTC) FILETIME=[0E645F30:01C47F40] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: "'tom.batsele@alcatel.be'" , "'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 Hello Donak, There is no specific behaviour for "codec" negotiation in H.248.1. The general rules of h.248.1 sect 7.1.7 and 7.1.8 applies for codecs as well. Regards, Christian Donak, John wrote: > Is the specific behaviour for codec negotiation specified anywhere within > MEGACO? (as in RFC3435 for MGCP). > > I could not find it. > > > John > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Wednesday, March 03, 2004 5:29 PM > To: tom.batsele@alcatel.be > Cc: megaco@ietf.org > Subject: Re: [Megaco] codec incompatibility > > > Hello Tom, > > You are allowed to have a different codecs in the local and remote > descriptor > for a particular stream. It is typical for a bi-directional connections that > the > same codec is used in either direction but H.248 does not mandate this. > > If you are concerned that MG1 may support different codecs to MG2 then it is > up > to negotiation to determine whether a call can take place. In BICC networks > this > codec negotiation is done at the MGC level. In other network types the MG1 > will > provide a list of codecs that are sent to the MG2 to choose from. > > Regards, Christian > > tom.batsele@alcatel.be wrote: > > >>Hello, >> >>What should happen in case MGC passes to a MG2 a localDescriptor with a >>different codec then in the remoteDescriptor. >>I.e MG1 only supports codec 8 and MG2 only supports codec 0. >>Which entity is responsible to detect that conversation will not be >>possible >> >>Must the MG generate 510 as described in section 7.1.8 of RFC3015 >> >>* If ReserveGroup is False and ReserveValue is false, then the MG >> SHOULD apply the following rules to resolve Local and Remote to a >> single alternative each: >> >> * The MG chooses the first alternative in Local for which it is able >> to support at least one alternative in Remote. >> >> * If the MG is unable to support at least one Local and one Remote >> alternative, it returns Error 510 (Insufficient Resources). >> >>or should the MGC not send such commands >> >>Example: >> >>14. The MGC will now associate A5555 with a new Context on MG2, and >> establish an RTP Stream (i.e, A5556 will be assigned), SendReceive >> connection through to the originating user, User 1. The MGC also sets >> ring on A5555. >> >> MGC to MG2: >> MEGACO/1 [123.123.123.4]:55555 >> Transaction = 50003 { >> Context = $ { >> Add = A5555 { Media { >> Stream = 1 { >> LocalControl {Mode = SendReceive} }}, >> Events=1234{al/of}, >> Signals {al/ri} >> }, >> Add = $ {Media { >> Stream = 1 { >> LocalControl { >> Mode = SendReceive, >> nt/jit=40 ; in ms >> }, >> Local { >> v=0 >> c=IN IP4 $ >> m=audio $ RTP/AVP 0 >> a=ptime:30 >> }, >> Remote { >> v=0 >> c=IN IP4 124.124.124.222 >> m=audio 2222 RTP/AVP 8 >> a=ptime:30 >> } ; } >> } >> } >> } >> } >> >> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> > > > > This communication is confidential and intended solely for the addressee(s). > Any unauthorized review, use, disclosure or distribution is prohibited. If > you believe this message has been sent to you in error, please notify the > sender by replying to this transmission and delete the message without > disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any such > corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > > _______________________________________________ > Megaco mailing 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 Aug 11 10:51:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09939 for ; Wed, 11 Aug 2004 10:51:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuuFP-0001ZS-Ol; Wed, 11 Aug 2004 10:38:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuuBG-0000sU-PB for megaco@megatron.ietf.org; Wed, 11 Aug 2004 10:34: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 KAA08928 for ; Wed, 11 Aug 2004 10:34:15 -0400 (EDT) Received: from [212.179.22.140] (helo=imss) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuuFz-0000Hb-AV for megaco@ietf.org; Wed, 11 Aug 2004 10:39:13 -0400 Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan Messaging Security Suite; Wed, 11 Aug 2004 17:36:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [MEGACO] Is there a way to exchange keys for media encryption? Date: Wed, 11 Aug 2004 17:30:45 +0300 Message-ID: Thread-Topic: [MEGACO] Is there a way to exchange keys for media encryption? Thread-Index: AcR/r8nfShwyjSqXSfaYnHUShMR+CA== From: "Nurit Shenhar" To: X-Spam-Score: 0.6 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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="===============1395236191==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1395236191== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47FAF.C9752420" This is a multi-part message in MIME format. ------_=_NextPart_001_01C47FAF.C9752420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =0D Is there some SDP attribute or MEGACO package which defines a way to exchange keys for media encryption? I know there is such thing in TGCP, but I couldn't find any general/formal way. =0D Thanks, =0D Nurit ***************************************************************************= ********************************* 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_001_01C47FAF.C9752420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

Is there some SDP attribute or MEGACO package which= defines a way to exchange keys for media encryption? I know there is such thing in TGCP, but I couldn’t find any general/formal= way.

 

Thanks,

 

Nurit

------_=_NextPart_001_01C47FAF.C9752420-- --===============1395236191== 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 --===============1395236191==-- From megaco-bounces@ietf.org Wed Aug 11 11:48:16 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 LAA13912 for ; Wed, 11 Aug 2004 11:48:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuvCi-0004uf-JR; Wed, 11 Aug 2004 11:39:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuvBd-0004WF-Jx for megaco@megatron.ietf.org; Wed, 11 Aug 2004 11:38:45 -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 LAA13238 for ; Wed, 11 Aug 2004 11:38:43 -0400 (EDT) Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuvGO-0001V6-KP for megaco@ietf.org; Wed, 11 Aug 2004 11:43:42 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7BFcAQ12594 for ; Wed, 11 Aug 2004 11:38:10 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Aug 2004 11:38:11 -0400 Message-ID: From: "Kevin Boyle" To: Nurit Shenhar , megaco@ietf.org Subject: RE: [MEGACO] Is there a way to exchange keys for media encryption ? Date: Wed, 11 Aug 2004 11:38:06 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.2 (/) 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: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org It seems to me that would be an issue for SDP exchange, and not really an H.248 issue. H.248 carries session descriptions; it does not define how session descriptions are used by the MGs to set up the bearer. I believe that the SRTP IETF work describes how to perform key exchange for bearers. Kevin _____ From: Nurit Shenhar [mailto:NuritS@audiocodes.com] Sent: Wednesday, August 11, 2004 10:31 AM To: megaco@ietf.org Subject: [MEGACO] Is there a way to exchange keys for media encryption? Hi Is there some SDP attribute or MEGACO package which defines a way to exchange keys for media encryption? I know there is such thing in TGCP, but I couldn't find any general/formal way. Thanks, Nurit **************************************************************************** ******************************** 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. **************************************************************************** ******************************* _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Aug 12 23:09: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 XAA27506 for ; Thu, 12 Aug 2004 23:09: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 1BvSPm-0007mK-No; Thu, 12 Aug 2004 23:07:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvSNR-00076r-DP for megaco@megatron.ietf.org; Thu, 12 Aug 2004 23:05: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 XAA27125 for ; Thu, 12 Aug 2004 23:05:06 -0400 (EDT) Received: from ns1.nec.com.au ([147.76.180.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvSSU-0004Ji-Vv for megaco@ietf.org; Thu, 12 Aug 2004 23:10:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ns1.nec.com.au (Postfix) with ESMTP id EDE5B3779A for ; Fri, 13 Aug 2004 13:04:32 +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 09624-01-74 for ; Fri, 13 Aug 2004 13:04:32 +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 DCF5137786 for ; Fri, 13 Aug 2004 13:04:32 +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 i7D34WGh021337 for ; Fri, 13 Aug 2004 13:04:32 +1000 Received: from GWANGXP ([147.76.211.59]) by tns.neca.nec.com.au (8.12.8/8.12.8) with SMTP id i7D34ViN004587 for ; Fri, 13 Aug 2004 13:04:32 +1000 From: "Gillian Wang" To: Date: Fri, 13 Aug 2004 13:02:20 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Megaco] Profile negotiation 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, I'm trying to figure out how the Profile works in normal H.248 procedures. For a MG implementation, it needs to have some agreement with MGC about the packages supported, naming conventions, digit map listings, etc before startup. They are specified in a Profile. How is the agreement achieved? I believe this is done via both parties implementing their own H.248 stack on the same profile agreement rather than a dynamic procedure. is it correct? I also noticed that the ServiceChange descriptor had a parameter referred to a profile supported. Is it specified for the dynamic negotiation procedure or information only? As for a digitmap which can be preloaded from the MGC, is it also outside the normal H.248 procedure? Thanks Gillian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Aug 13 05:14: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 FAA29497 for ; Fri, 13 Aug 2004 05:14: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 1BvY8Q-0001Ji-FS; Fri, 13 Aug 2004 05:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvY56-0000un-S5 for megaco@megatron.ietf.org; Fri, 13 Aug 2004 05:10: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 FAA29230 for ; Fri, 13 Aug 2004 05:10:31 -0400 (EDT) Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvYAA-0001s1-Qc for megaco@ietf.org; Fri, 13 Aug 2004 05:15:52 -0400 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id i7D94Zhi010327 for ; Fri, 13 Aug 2004 17:04:41 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Aug 13 17:08:48 2004 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Aug 2004 17:08:48 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 13 Aug 2004 17:08:47 +0800 Message-ID: <01F6E1FBEE83B543868895AE9CAB189F5E4588@bellnet-mail3.sbell.com.cn> Thread-Topic: DigitMap question Thread-Index: AcSBFSN8fX+FgugOTcmt4z343jQKEQ== From: "FCG Wang SiHai" To: X-OriginalArrivalTime: 13 Aug 2004 09:08:48.0132 (UTC) FILETIME=[2495F440:01C48115] X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [Megaco] DigitMap question 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="===============1530469217==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1530469217== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48115.2476FF72" This is a multi-part message in MIME format. ------_=_NextPart_001_01C48115.2476FF72 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hello: When implement DigitMap deletion, we meet a problem. As RFC3525 description: - A DigitMap is deleted by supplying an empty value for a name = that is already defined. Terminations presently using the digitmap shall continue to use the old definition. Whether DigitMap descriptor format is: DigitMap=3D Dialplan0=20 or=20 DigitMap=3D Dialplan0{} =20 From Annex B ABNF definition: digitMapDescriptor =3D DigitMapToken EQUAL ( ( LBRKT digitMapValue RBRKT ) / (digitMapName [ LBRKT digitMapValue RBRKT ]) ) When digitvalue is null, whether {} is needed? =20 Thank you! ------_=_NextPart_001_01C48115.2476FF72 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hello:
     When=20 implement DigitMap deletion, we meet a problem.
     As=20 RFC3525 description:
     =20 -  A DigitMap is deleted by supplying an empty value for a name=20 that
      is already defined.  = Terminations=20 presently using the digitmap
      shall = continue to=20 use the old definition.
     =20 Whether DigitMap descriptor format is:
     =20 DigitMap=3D Dialplan0
     =20 or
     =20 DigitMap=3D Dialplan0{}
     =20
     =20 >From Annex B ABNF definition:
   =   =20 digitMapDescriptor  =3D DigitMapToken=20 EQUAL
          &nbs= p;            = ;=20 ( ( LBRKT digitMapValue RBRKT )=20 /
           &n= bsp;           =20 (digitMapName [ LBRKT digitMapValue RBRKT ]) )
     =20 When digitvalue is null, whether {} is needed?
    =20
     =20 Thank you!
------_=_NextPart_001_01C48115.2476FF72-- --===============1530469217== 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 --===============1530469217==-- From megaco-bounces@ietf.org Fri Aug 13 05:49: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 FAA01367 for ; Fri, 13 Aug 2004 05:49: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 1BvYdf-00067z-93; Fri, 13 Aug 2004 05:46:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvYcb-0005tQ-7Z for megaco@megatron.ietf.org; Fri, 13 Aug 2004 05:45: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 FAA00970 for ; Fri, 13 Aug 2004 05:45:10 -0400 (EDT) From: raverma@hss.hns.com Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvYhe-0002Qb-K3 for megaco@ietf.org; Fri, 13 Aug 2004 05:50:32 -0400 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 i7D9arNH002443; Fri, 13 Aug 2004 15:06:53 +0530 (IST) In-Reply-To: <01F6E1FBEE83B543868895AE9CAB189F5E4588@bellnet-mail3.sbell.com.cn> MIME-Version: 1.0 To: "FCG Wang SiHai" Subject: Re: [Megaco] DigitMap question X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Fri, 13 Aug 2004 14:43:13 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 13/08/2004 03:14:28 PM, Serialize complete at 13/08/2004 03:14:28 PM X-Spam-Score: 0.8 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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: , Content-Type: multipart/mixed; boundary="===============0424104579==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multipart message in MIME format. --===============0424104579== Content-Type: multipart/alternative; boundary="=_alternative 0034E1E065256EEF_=" This is a multipart message in MIME format. --=_alternative 0034E1E065256EEF_= Content-Type: text/plain; charset="US-ASCII" Hi, When digitMapValue is null , you need not specify {} as '[ LBRKT digitMapValue RBRKT ]' is optional. i.e. DigitMap descriptor format is: DigitMap= Dialplan0 regards Rakhi Sent by: megaco-bounces@ietf.org To: cc: Subject: [Megaco] DigitMap question Hello: When implement DigitMap deletion, we meet a problem. As RFC3525 description: - A DigitMap is deleted by supplying an empty value for a name that is already defined. Terminations presently using the digitmap shall continue to use the old definition. Whether DigitMap descriptor format is: DigitMap= Dialplan0 or DigitMap= Dialplan0{} >From Annex B ABNF definition: digitMapDescriptor = DigitMapToken EQUAL ( ( LBRKT digitMapValue RBRKT ) / (digitMapName [ LBRKT digitMapValue RBRKT ]) ) When digitvalue is null, whether {} is needed? Thank you! _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ***************** HSS-Private ************* --=_alternative 0034E1E065256EEF_= Content-Type: text/html; charset="US-ASCII"
Hi,
           When digitMapValue is null , you need not specify {}  as  '[ LBRKT digitMapValue RBRKT ]' is optional.
            i.e.
            DigitMap descriptor format is:
                 DigitMap= Dialplan0
           
regards
Rakhi

Sent by:        megaco-bounces@ietf.org

To:        <megaco@ietf.org>
cc:        

Subject:        [Megaco] DigitMap question




Hello:
     When  implement DigitMap deletion, we meet a problem.
     As  RFC3525 description:
       -  A DigitMap is deleted by supplying an empty value for a name  that
      is already defined.  Terminations  presently using the digitmap
      shall continue to  use the old definition.
       Whether DigitMap descriptor format is:
       DigitMap= Dialplan0
       or
       DigitMap= Dialplan0{}
       
       >From Annex B ABNF definition:
       digitMapDescriptor  = DigitMapToken  EQUAL
                         ( ( LBRKT digitMapValue RBRKT )  /
                         (digitMapName [ LBRKT digitMapValue RBRKT ]) )
       When digitvalue is null, whether {} is needed?
      
       Thank you!
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



*****************    HSS-Private    ************* --=_alternative 0034E1E065256EEF_=-- --===============0424104579== 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 --===============0424104579==-- From megaco-bounces@ietf.org Fri Aug 13 13:52:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01638 for ; Fri, 13 Aug 2004 13:52:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvgAs-0007Ez-GD; Fri, 13 Aug 2004 13:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvg9o-0006zW-Ne for megaco@megatron.ietf.org; Fri, 13 Aug 2004 13:48:00 -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 NAA01508 for ; Fri, 13 Aug 2004 13:47:59 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvgF0-0002y5-Ph for megaco@ietf.org; Fri, 13 Aug 2004 13:53:24 -0400 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7DHlOtr017891; Fri, 13 Aug 2004 10:47:24 -0700 (PDT) Received: from musharmaw2k03 (dhcp-171-71-248-130.cisco.com [171.71.248.130]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id ATB67979; Fri, 13 Aug 2004 10:47:16 -0700 (PDT) From: "Mukul Sharma" To: Date: Fri, 13 Aug 2004 10:48:56 -0700 Message-ID: <02b801c4815d$ce7bd4a0$92f847ab@amer.cisco.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "'Mukul Sharma'" Subject: [Megaco] megaco syntax/callflows for ground-start protocol 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="===============1112193958==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1112193958== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B9_01C48123.221CFCA0" This is a multi-part message in MIME format. ------=_NextPart_000_02B9_01C48123.221CFCA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 Can someone pl point me to the document which has megaco syntax and callflows for ground-start protocol? =20 basic cas package and rbs package has reference to wink-start protocol = and I didn't see any reference to ground-start protocol. =20 Regards Mukul ------=_NextPart_000_02B9_01C48123.221CFCA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi=20 All,
 
Can = someone pl point=20 me to the document which has megaco syntax and callflows for = ground-start=20 protocol?
 
basic = cas package=20 and rbs package has reference to wink-start protocol and I didn't see = any=20 reference to ground-start protocol.
 
Regards
Mukul
------=_NextPart_000_02B9_01C48123.221CFCA0-- --===============1112193958== 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 --===============1112193958==-- From megaco-bounces@ietf.org Fri Aug 13 22:46:37 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 WAA04253 for ; Fri, 13 Aug 2004 22:46:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvoWW-0002BW-3o; Fri, 13 Aug 2004 22:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvoW2-00021w-EE for megaco@megatron.ietf.org; Fri, 13 Aug 2004 22:43: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 WAA04130 for ; Fri, 13 Aug 2004 22:43:27 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvobJ-0004Kg-Ib for megaco@ietf.org; Fri, 13 Aug 2004 22:48:58 -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 i7E2guo25104 for ; Fri, 13 Aug 2004 22:42:56 -0400 (EDT) Received: from [47.102.177.139] (archt0q9.us.nortel.com [47.102.177.139]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALTFPQT; Fri, 13 Aug 2004 22:42:56 -0400 Message-ID: <411D7C13.1070106@nortelnetworks.com> Date: Fri, 13 Aug 2004 22:42:27 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Megaco] Behaviour of out-of-service terminations 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 If the MG reports a termination is out of service, it seems reasonable to assume that it will neither report events nor continue to apply signals which were active on it when it made the transition. Is this totally obvious or should a note to this effect be added to the specification? Tom Taylor _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Sat Aug 14 04:11: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 EAA00845 for ; Sat, 14 Aug 2004 04:11: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 1BvtbR-00032u-Rd; Sat, 14 Aug 2004 04:09:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvtYp-0002gz-HB for megaco@megatron.ietf.org; Sat, 14 Aug 2004 04:06: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 EAA00675 for ; Sat, 14 Aug 2004 04:06:41 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvte5-00005I-EB for megaco@ietf.org; Sat, 14 Aug 2004 04:12:15 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7E86aAh028774 for ; Sat, 14 Aug 2004 10:06:36 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Aug 2004 10:06:36 +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 Q6GYDGMP; Sat, 14 Aug 2004 10:06:36 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.22.11]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PVK8KYB2; Sat, 14 Aug 2004 18:06:33 +1000 Message-ID: <411DC837.9090904@ericsson.com> Date: Sat, 14 Aug 2004 18:07:19 +1000 X-Sybari-Trust: ffebe46e 477d8de1 4541b650 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: Tom Taylor Subject: Re: [Megaco] Behaviour of out-of-service terminations References: <411D7C13.1070106@nortelnetworks.com> In-Reply-To: <411D7C13.1070106@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2004 08:06:36.0346 (UTC) FILETIME=[9EAE59A0:01C481D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 G'Day Tom, I had hoped this would be obvious. But if someone is asking this then maybe its not? Regards, Christian Tom Taylor wrote: > If the MG reports a termination is out of service, it seems reasonable > to assume that it will neither report events nor continue to apply > signals which were active on it when it made the transition. Is this > totally obvious or should a note to this effect be added to the > specification? > > Tom Taylor > > _______________________________________________ > Megaco mailing 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 Aug 16 00:24:17 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 AAA20590 for ; Mon, 16 Aug 2004 00:24:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwZ04-00042I-BB; Mon, 16 Aug 2004 00:21:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwYxH-0003ml-WB for megaco@megatron.ietf.org; Mon, 16 Aug 2004 00:18: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 AAA20390 for ; Mon, 16 Aug 2004 00:18:39 -0400 (EDT) From: bvswamy@hss.hns.com Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwZ2u-0000Sn-8K for megaco@ietf.org; Mon, 16 Aug 2004 00:24:38 -0400 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 i7G4FoNH001200; Mon, 16 Aug 2004 09:45:51 +0530 (IST) In-Reply-To: <411DC837.9090904@ericsson.com> Subject: Re: [Megaco] Behaviour of out-of-service terminations To: megaco@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Mon, 16 Aug 2004 09:52:21 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 16/08/2004 09:54:07 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Tom Taylor , Christian Groves 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 I do agree with Christian that though its obvious but as we seen in the past there has been queries raised in the mailing list on the termination behaviour in the out-of-service state, so surely this topic demands little clarification in the specification. Just to add few more points to the Tom's query about the service change behaviour: 1) Validity of descriptors for the null-context terminations when a termination is made Out-Of-Service. Though protocol has clearly mentioned that for terminations in valid context, MGC should send subtract, which would clear the descriptors, but there is no clarification for null-context terminations. 2) Can a MGC brings a termination in-service, if MG has made it out-of-service. Also what are the commands valid for a out-of-service terminations. 3) How to cancel a previously generated service change with delay. However it make sense that any new service change should completely overwrite the previous service change command, but here also it needs to be clarified in the specifications. Regards B Venkat S.R Swamy Hughes Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.hssworld.com Christian Groves To Sent by: Tom Taylor megaco-bounces@ie tf.org cc megaco@ietf.org Subject 08/14/2004 01:37 Re: [Megaco] Behaviour of PM out-of-service terminations G'Day Tom, I had hoped this would be obvious. But if someone is asking this then maybe its not? Regards, Christian Tom Taylor wrote: > If the MG reports a termination is out of service, it seems reasonable > to assume that it will neither report events nor continue to apply > signals which were active on it when it made the transition. Is this > totally obvious or should a note to this effect be added to the > specification? > > Tom Taylor > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco *********************** HSS-Unclassified *********************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 16 09:49: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 JAA04232 for ; Mon, 16 Aug 2004 09:49:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwhpq-00080z-9q; Mon, 16 Aug 2004 09:47:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwhoJ-0007kZ-27 for megaco@megatron.ietf.org; Mon, 16 Aug 2004 09:46:03 -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 JAA04149 for ; Mon, 16 Aug 2004 09:46:01 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwhu5-0001Zg-5Z for megaco@ietf.org; Mon, 16 Aug 2004 09:52:02 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7GDjxWR003277 for ; Mon, 16 Aug 2004 15:45:59 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 15:45:59 +0200 Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QMTY783V; Mon, 16 Aug 2004 15:45:59 +0200 Received: from amrod (amrod [134.138.176.177]) by super.du.uab.ericsson.se (8.10.1/8.10.1/erix-1.8) with ESMTP id i7GDjwH03318 for ; Mon, 16 Aug 2004 15:45:58 +0200 (MET DST) Date: Mon, 16 Aug 2004 15:45:58 +0200 (CEST) X-Sybari-Trust: ed691d11 74470f8f 0a9eeb00 00000138 From: Hakan Mattsson To: megaco@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by super.du.uab.ericsson.se id i7GDjwH03318 X-OriginalArrivalTime: 16 Aug 2004 13:45:59.0101 (UTC) FILETIME=[5CA7AED0:01C48397] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] Re: IndAudlocalControlDescriptor inconsistency 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 Please, can someone clarify this issue? I did not get any replies at all on the posting below. /H=E5kan On Mon, 9 Aug 2004, Hakan Mattsson wrote: HM> Date: Mon, 9 Aug 2004 17:55:26 +0200 (CEST) HM> From: Hakan Mattsson HM> To: megaco@ietf.org HM> Subject: IndAudlocalControlDescriptor inconsistency HM>=20 HM>=20 HM> In the ASN.1 specification of IndAudLocalControlDescriptor it is HM> allowed with one each of stream mode, reserve value and reserve group HM> plus a any number of package names: HM>=20 HM>=20 HM> IndAudLocalControlDescriptor ::=3D SEQUENCE=20 HM> {=20 HM> streamMode NULL OPTIONAL,=20 HM> reserveValue NULL OPTIONAL,=20 HM> reserveGroup NULL OPTIONAL,=20 HM> propertyParms SEQUENCE OF IndAudPropertyParm OPTIO= NAL,=20 HM> ...=20 HM> }=20 HM> =20 HM> IndAudPropertyParm ::=3D SEQUENCE=20 HM> {=20 HM> name PkgdName,=20 HM> ...=20 HM> }=20 HM> =20 HM> while it in the ABNF specification of indAudlocalControlDescriptor is HM> limited to be exactly one of stream mode, reserve value, reserve grou= p HM> and package name: HM>=20 HM> indAudlocalControlDescriptor =3D LocalControlToken =20 HM> LBRKT indAudlocalParm RBRKT=20 HM> =20 HM> ; at-most-once per item=20 HM> indAudlocalParm =3D ( ModeToken / pkgdName /=20 HM> ReservedValueToken /=20 HM> ReservedGroupToken )=20 HM>=20 HM> For example this means that it is possible to have both stream mode HM> and package name in ASN.1, while this is not allowed in ABNF. HM>=20 HM> To me this looks like a bug in the Megaco standard as the ASN.1 HM> encoding and ABNF encoding is not semantically equivalent in this HM> case. HM>=20 HM> I suggest that the ABNF should be changed to the following in order t= o HM> be compliant with ASN.1: HM>=20 HM> indAudlocalControlDescriptor =3D LocalControlToken =20 HM> LBRKT indAudlocalParm *(COMMA indAudlocalPar= m) RBRKT=20 HM>=20 HM> I would appreciate if someone on the list could clarify whether this HM> Megaco bug is in ABNF or ASN.1. HM>=20 HM> /H=E5kan HM>=20 HM> --- HM> H=E5kan Mattsson, Ericsson AB HM> High Availability Software, DBMS Internals HM> http://www.erlang.org/~hakan/ HM>=20 HM>=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 16 11:40: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 LAA11711 for ; Mon, 16 Aug 2004 11:40: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 1BwjZm-0005UB-UO; Mon, 16 Aug 2004 11:39:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwjYO-0005NK-RL for megaco@megatron.ietf.org; Mon, 16 Aug 2004 11: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 LAA11572 for ; Mon, 16 Aug 2004 11:37:42 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwjeD-0003Oa-Px for megaco@ietf.org; Mon, 16 Aug 2004 11:43:46 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7GFaqI01059; Mon, 16 Aug 2004 11:36:52 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Aug 2004 11:36:53 -0400 Message-ID: From: "Kevin Boyle" To: bvswamy@hss.hns.com, megaco@ietf.org Subject: RE: [Megaco] Behaviour of out-of-service terminations Date: Mon, 16 Aug 2004 11:36:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Cc: Tom-PT Taylor , Christian Groves 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="===============2062967584==" 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. --===============2062967584== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C483A6.DA3EEEC6" 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_01C483A6.DA3EEEC6 Content-Type: text/plain Many of these items will be covered by the text in the forthcoming Annex F. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] Sent: Monday, August 16, 2004 12:22 AM To: megaco@ietf.org Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; Christian Groves Subject: Re: [Megaco] Behaviour of out-of-service terminations Hi I do agree with Christian that though its obvious but as we seen in the past there has been queries raised in the mailing list on the termination behaviour in the out-of-service state, so surely this topic demands little clarification in the specification. Just to add few more points to the Tom's query about the service change behaviour: 1) Validity of descriptors for the null-context terminations when a termination is made Out-Of-Service. Though protocol has clearly mentioned that for terminations in valid context, MGC should send subtract, which would clear the descriptors, but there is no clarification for null-context terminations. 2) Can a MGC brings a termination in-service, if MG has made it out-of-service. Also what are the commands valid for a out-of-service terminations. 3) How to cancel a previously generated service change with delay. However it make sense that any new service change should completely overwrite the previous service change command, but here also it needs to be clarified in the specifications. Regards B Venkat S.R Swamy Hughes Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.hssworld.com Christian Groves To Sent by: Tom Taylor megaco-bounces@ie tf.org cc megaco@ietf.org Subject 08/14/2004 01:37 Re: [Megaco] Behaviour of PM out-of-service terminations G'Day Tom, I had hoped this would be obvious. But if someone is asking this then maybe its not? Regards, Christian Tom Taylor wrote: > If the MG reports a termination is out of service, it seems reasonable > to assume that it will neither report events nor continue to apply > signals which were active on it when it made the transition. Is this > totally obvious or should a note to this effect be added to the > specification? > > Tom Taylor > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco *********************** HSS-Unclassified *********************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C483A6.DA3EEEC6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Behaviour of out-of-service terminations

Many of these items will be covered by the text in = the forthcoming Annex F.

Kevin

-----Original Message-----
From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]
Sent: Monday, August 16, 2004 12:22 AM
To: megaco@ietf.org
Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; Christian = Groves
Subject: Re: [Megaco] Behaviour of out-of-service = terminations





Hi
      I do agree with = Christian that though its obvious but as we seen in the past there has = been queries raised in the mailing list on the termination behaviour in = the out-of-service state, so surely this topic demands little = clarification in the specification. Just to add few more points to the = Tom's query about the service change behaviour:

1) Validity of descriptors for the null-context = terminations when a termination is made Out-Of-Service. Though protocol = has clearly mentioned that for terminations in valid context, MGC = should send subtract, which would clear the  descriptors, but = there is no clarification for null-context terminations.

2) Can a MGC brings a termination in-service, if MG = has made it out-of-service.  Also what are the commands valid for = a out-of-service terminations.

3) How to cancel a previously generated service = change with delay. However it make sense that any new service change = should completely overwrite the previous service change command, but = here also it needs to be clarified in the specifications.


Regards
B Venkat S.R Swamy
Hughes Software Systems
Phone:  +91-124-2455555 Extn 3620
Fax: +91-124-2455345
web: www.hssworld.com



          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   
          &nb= sp;  Christian = Groves           =             =             =           
          &nb= sp;  = <christian.groves        &nbs= p;           &nbs= p;           &nbs= p;            =
          &nb= sp;  = @ericsson.com>         &= nbsp;           &= nbsp;           &= nbsp;           To =
          &nb= sp;  Sent = by:           &nb= sp;      Tom = Taylor           =             =   
          &nb= sp;  = megaco-bounces@ie         = <taylor@nortelnetworks.com>      &nb= sp; 
          &nb= sp;  = tf.org           =             =             =             =       cc
          &nb= sp;           &nb= sp;           &nb= sp;    = megaco@ietf.org         &nb= sp;          
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;        Subject
          &nb= sp;  08/14/2004 = 01:37          Re: = [Megaco] Behaviour = of          
          &nb= sp;  = PM           &nbs= p;            = out-of-service = terminations        
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   




G'Day Tom,

I had hoped this would be obvious. But if someone is = asking this then maybe its not?

Regards, Christian

Tom Taylor wrote:

> If the MG reports a termination is out of = service, it seems reasonable
> to assume that it will neither report events = nor continue to apply
> signals which were active on it when it made = the transition.  Is this
> totally obvious or should a note to this effect = be added to the
> specification?
>
> Tom Taylor
>
> = _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>


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


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


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

------_=_NextPart_001_01C483A6.DA3EEEC6-- --===============2062967584== 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 --===============2062967584==-- From megaco-bounces@ietf.org Tue Aug 17 07:51:18 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 HAA09546 for ; Tue, 17 Aug 2004 07:51:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx2T9-00011o-Lf; Tue, 17 Aug 2004 07:49:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx2Qx-0000Z6-B1 for megaco@megatron.ietf.org; Tue, 17 Aug 2004 07:47:19 -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 HAA09352 for ; Tue, 17 Aug 2004 07:47:18 -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 1Bx2Wu-00020B-7U for megaco@ietf.org; Tue, 17 Aug 2004 07:53:31 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.ccpu.com (Postfix) with ESMTP id 8EB9E346846 for ; Tue, 17 Aug 2004 04:47:09 -0700 (PDT) Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (VaMailArmor-2.0.1.16) id 22879-2104A609; Tue, 17 Aug 2004 04:47:03 -0700 Received: from CCIN00339 (dhcp58.ccin.ccpu.com [172.25.0.58]) by smtp.ccpu.com (Postfix) with ESMTP id 0929C346846 for ; Tue, 17 Aug 2004 04:47:02 -0700 (PDT) From: "Karthikeyan S" To: Date: Tue, 17 Aug 2004 17:17:00 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcSET+fVD3q+o6q9Sr6ebtMgGbSe/A== Message-Id: <20040817114702.0929C346846@smtp.ccpu.com> X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.4; VDF: 6.27.0.15; host: smtp) X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Subject: [Megaco] Command Timeout 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="===============1906678390==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1906678390== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0093_01C4847E.02C5A6F0" This is a multi-part message in MIME format. ------=_NextPart_000_0093_01C4847E.02C5A6F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit HI, Can anyone clarify me the way command timeout should be handled in Megaco? Say a MG application taking more time to respond to a command request but it has replied to the previous commands of the same transaction. Does the transaction response need to be sent with the command replies being answered and leaving the un responded command when the time taken exceeds (~ MGOriginatedPendingLimit * MGExecutionTime) I will greatly appreciate if someone could reply me on this regard. Thanks Karthik ------=_NextPart_000_0093_01C4847E.02C5A6F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI,

 

Can anyone clarify me the way command timeout should = be handled in Megaco? Say a MG application taking more time to respond to a command request but it has replied to the previous commands of the same transaction. Does the transaction response need to be sent with the = command replies being answered and leaving the un responded command when the = time taken exceeds (~ MGOriginatedPendingLimit * = MGExecutionTime)

 

I will greatly appreciate if someone could reply me = on this regard.

 

Thanks

Karthik

 

------=_NextPart_000_0093_01C4847E.02C5A6F0-- --===============1906678390== 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 --===============1906678390==-- From megaco-bounces@ietf.org Tue Aug 17 12:36:06 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 MAA27465 for ; Tue, 17 Aug 2004 12:36:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx6mz-0000jY-Qv; Tue, 17 Aug 2004 12:26:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx6YV-0004l7-LF for megaco@megatron.ietf.org; Tue, 17 Aug 2004 12:11: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 MAA25660 for ; Tue, 17 Aug 2004 12:11:20 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx6eX-0006y0-4O for megaco@ietf.org; Tue, 17 Aug 2004 12:17:38 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7HGAnF26029 for ; Tue, 17 Aug 2004 12:10:49 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Aug 2004 12:10:49 -0400 Message-ID: From: "Kevin Boyle" To: Karthikeyan S , megaco@ietf.org Subject: RE: [Megaco] Command Timeout Date: Tue, 17 Aug 2004 12:10:46 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 The responder could use Pending to indicate the processing is taking longer than normal. Note that there is a practical limit on how long a responder can send Pendings -- eventually it will have to send an error as the response for the command in question if it cannot complete it in a reasonable time. Kevin _____ From: Karthikeyan S [mailto:karthiks@ccpu.com] Sent: Tuesday, August 17, 2004 7:47 AM To: megaco@ietf.org Subject: [Megaco] Command Timeout HI, Can anyone clarify me the way command timeout should be handled in Megaco? Say a MG application taking more time to respond to a command request but it has replied to the previous commands of the same transaction. Does the transaction response need to be sent with the command replies being answered and leaving the un responded command when the time taken exceeds (~ MGOriginatedPendingLimit * MGExecutionTime) I will greatly appreciate if someone could reply me on this regard. Thanks Karthik _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Aug 17 16:33: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 QAA13381 for ; Tue, 17 Aug 2004 16:33:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxAc8-0006ie-7g; Tue, 17 Aug 2004 16:31:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxAZA-0006As-6w for megaco@megatron.ietf.org; Tue, 17 Aug 2004 16:28:20 -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 QAA13149 for ; Tue, 17 Aug 2004 16:28:17 -0400 (EDT) Received: from adicia.telenet-ops.be ([195.130.132.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxAfD-0003lS-Re for megaco@ietf.org; Tue, 17 Aug 2004 16:34:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by adicia.telenet-ops.be (Postfix) with SMTP id 16ACD440D1 for ; Tue, 17 Aug 2004 22:28:17 +0200 (MEST) Received: from pas (D5778A4F.kabel.telenet.be [213.119.138.79]) by adicia.telenet-ops.be (Postfix) with SMTP id B35D4441F7 for ; Tue, 17 Aug 2004 22:28:16 +0200 (MEST) Message-ID: <003601c48499$3b241660$c400a8c0@pandora.be> From: "Pascal Lambers" To: Date: Tue, 17 Aug 2004 22:31:52 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.8 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Megaco] Modify to do Audit hook state X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pascal Lambers List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0348033741==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0348033741== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C484A9.FE83B380" This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C484A9.FE83B380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Megaco does not provide an Audit message to audit a termination's hook = status directly. That's clear. Instead, to know whether a termination is Off Hook, the MGC must send a = Modify with an Off Hook (strict/failWrong) Events descriptor. = Consequently, if the termination is already off hook, the MG will reply = with an error. Is it sure that in such a case the events and signals = implemented on this termination before the Modify arrived, are still = present? In other words, is it sure that messages from the MGC to the MG = replied to with an error do not have any negative effect? Kind regards, Pascal ------=_NextPart_000_0033_01C484A9.FE83B380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
Megaco does not provide an Audit = message to audit a=20 termination's hook status directly. That's clear.
 
Instead, to know whether a = termination is=20 Off Hook, the MGC must send a Modify with an Off=20 Hook (strict/failWrong) Events descriptor.  Consequently, if = the=20 termination is already off hook, the MG will reply with an error. Is it = sure=20 that in such a case the events and signals implemented on this = termination=20 before the Modify arrived, are still present? In other words, is it sure = that=20 messages from the MGC to the MG replied to with an error do = not have=20 any negative effect?
 
Kind regards,
Pascal
 
 
------=_NextPart_000_0033_01C484A9.FE83B380-- --===============0348033741== 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 --===============0348033741==-- From megaco-bounces@ietf.org Tue Aug 17 16:48:09 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 QAA14017 for ; Tue, 17 Aug 2004 16:48:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxAqo-00010N-Uj; Tue, 17 Aug 2004 16:46:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxAqB-0000nv-6N for megaco@megatron.ietf.org; Tue, 17 Aug 2004 16:45:55 -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 QAA13920 for ; Tue, 17 Aug 2004 16:45:52 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxAwF-000401-1T for megaco@ietf.org; Tue, 17 Aug 2004 16:52:12 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7HKjLh18904 for ; Tue, 17 Aug 2004 16:45:21 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Aug 2004 16:45:20 -0400 Message-ID: From: "Kevin Boyle" To: Pascal Lambers , megaco@ietf.org Subject: RE: [Megaco] Modify to do Audit hook state Date: Tue, 17 Aug 2004 16:45:12 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 The MGC must account for these kinds of issues when it is building messages. I would note that there are two other possible values for the strict parm that may be of more use: 'state' and 'exact'. If having the MG generate errors is a problem, then you could use one of the other two options instead. Kevin _____ From: Pascal Lambers [mailto:pascal.lambers@pandora.be] Sent: Tuesday, August 17, 2004 4:32 PM To: megaco@ietf.org Subject: [Megaco] Modify to do Audit hook state Hello, Megaco does not provide an Audit message to audit a termination's hook status directly. That's clear. Instead, to know whether a termination is Off Hook, the MGC must send a Modify with an Off Hook (strict/failWrong) Events descriptor. Consequently, if the termination is already off hook, the MG will reply with an error. Is it sure that in such a case the events and signals implemented on this termination before the Modify arrived, are still present? In other words, is it sure that messages from the MGC to the MG replied to with an error do not have any negative effect? Kind regards, Pascal _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Aug 17 17:10: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 RAA14728 for ; Tue, 17 Aug 2004 17:10: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 1BxB98-0003sm-EA; Tue, 17 Aug 2004 17:05:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxB3P-0002qA-Td for megaco@megatron.ietf.org; Tue, 17 Aug 2004 16:59:35 -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 QAA14354 for ; Tue, 17 Aug 2004 16:59:33 -0400 (EDT) Received: from adicia.telenet-ops.be ([195.130.132.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxB9T-0004Cm-Un for megaco@ietf.org; Tue, 17 Aug 2004 17:05:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by adicia.telenet-ops.be (Postfix) with SMTP id 9B6F0440EE for ; Tue, 17 Aug 2004 22:59:33 +0200 (MEST) Received: from pas (D5778A4F.kabel.telenet.be [213.119.138.79]) by adicia.telenet-ops.be (Postfix) with SMTP id 7363E440A3 for ; Tue, 17 Aug 2004 22:59:33 +0200 (MEST) Message-ID: <007401c4849d$99cd0a60$c400a8c0@pandora.be> From: "Pascal Lambers" To: References: Subject: Re: [Megaco] Modify to do Audit hook state Date: Tue, 17 Aug 2004 23:03:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pascal Lambers 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 Kevin, "The MGC must account for these kinds of issues when it is building messages". By this you mean, that if the MG returns an error "termination allready off/on hook", the MGC has no longer any guarantee as to which events are still programmed on the termination? If so, the strict/exact and strict/state won't be of any help I'm afraid: the Modify will always overwrite events that were present on the termination before... and if the MGC just sent this Modify to know whether the hook status of a termination is still as it expected, without taking anything else, this is a problem. Do I interpret this correctly? Pascal ----- Original Message ----- From: "Kevin Boyle" To: "Pascal Lambers" ; Sent: Tuesday, August 17, 2004 10:45 PM Subject: RE: [Megaco] Modify to do Audit hook state > The MGC must account for these kinds of issues when it is building messages. > > I would note that there are two other possible values for the strict parm > that may be of more use: 'state' and 'exact'. If having the MG generate > errors is a problem, then you could use one of the other two options > instead. > > Kevin > > > > _____ > > From: Pascal Lambers [mailto:pascal.lambers@pandora.be] > Sent: Tuesday, August 17, 2004 4:32 PM > To: megaco@ietf.org > Subject: [Megaco] Modify to do Audit hook state > > > Hello, > > Megaco does not provide an Audit message to audit a termination's hook > status directly. That's clear. > > Instead, to know whether a termination is Off Hook, the MGC must send a > Modify with an Off Hook (strict/failWrong) Events descriptor. Consequently, > if the termination is already off hook, the MG will reply with an error. Is > it sure that in such a case the events and signals implemented on this > termination before the Modify arrived, are still present? In other words, is > it sure that messages from the MGC to the MG replied to with an error do not > have any negative effect? > > Kind regards, > Pascal > > > > > _______________________________________________ > Megaco mailing 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 Aug 17 18:00:16 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 SAA17387 for ; Tue, 17 Aug 2004 18:00:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxBve-0004Wa-9I; Tue, 17 Aug 2004 17:55:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxBqh-0003SN-Mr for megaco@megatron.ietf.org; Tue, 17 Aug 2004 17:50:31 -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 RAA16965 for ; Tue, 17 Aug 2004 17:50:28 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxBwl-0005Bk-VQ for megaco@ietf.org; Tue, 17 Aug 2004 17:56:49 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7HLnvd20292 for ; Tue, 17 Aug 2004 17:49:57 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Aug 2004 17:49:58 -0400 Message-ID: From: "Kevin Boyle" To: Pascal Lambers , megaco@ietf.org Subject: RE: [Megaco] Modify to do Audit hook state Date: Tue, 17 Aug 2004 17:49:55 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 The MGC would have to include any events previously present in the Events descriptor in order to guarantee their continued detection, yes. Kevin -----Original Message----- From: Pascal Lambers [mailto:pascal.lambers@pandora.be] Sent: Tuesday, August 17, 2004 5:03 PM To: megaco@ietf.org Subject: Re: [Megaco] Modify to do Audit hook state Kevin, "The MGC must account for these kinds of issues when it is building messages". By this you mean, that if the MG returns an error "termination allready off/on hook", the MGC has no longer any guarantee as to which events are still programmed on the termination? If so, the strict/exact and strict/state won't be of any help I'm afraid: the Modify will always overwrite events that were present on the termination before... and if the MGC just sent this Modify to know whether the hook status of a termination is still as it expected, without taking anything else, this is a problem. Do I interpret this correctly? Pascal ----- Original Message ----- From: "Kevin Boyle" To: "Pascal Lambers" ; Sent: Tuesday, August 17, 2004 10:45 PM Subject: RE: [Megaco] Modify to do Audit hook state > The MGC must account for these kinds of issues when it is building messages. > > I would note that there are two other possible values for the strict parm > that may be of more use: 'state' and 'exact'. If having the MG generate > errors is a problem, then you could use one of the other two options > instead. > > Kevin > > > > _____ > > From: Pascal Lambers [mailto:pascal.lambers@pandora.be] > Sent: Tuesday, August 17, 2004 4:32 PM > To: megaco@ietf.org > Subject: [Megaco] Modify to do Audit hook state > > > Hello, > > Megaco does not provide an Audit message to audit a termination's hook > status directly. That's clear. > > Instead, to know whether a termination is Off Hook, the MGC must send a > Modify with an Off Hook (strict/failWrong) Events descriptor. Consequently, > if the termination is already off hook, the MG will reply with an error. Is > it sure that in such a case the events and signals implemented on this > termination before the Modify arrived, are still present? In other words, is > it sure that messages from the MGC to the MG replied to with an error do not > have any negative effect? > > Kind regards, > Pascal > > > > > _______________________________________________ > Megaco mailing 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 Aug 17 18:18:36 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 SAA19523 for ; Tue, 17 Aug 2004 18:18:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxCAt-0003cH-NL; Tue, 17 Aug 2004 18:11:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxC0b-0005jJ-RG for megaco@megatron.ietf.org; Tue, 17 Aug 2004 18:00:45 -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 SAA17410 for ; Tue, 17 Aug 2004 18:00:42 -0400 (EDT) Received: from adicia.telenet-ops.be ([195.130.132.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxC6g-0005O1-Nx for megaco@ietf.org; Tue, 17 Aug 2004 18:07:03 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by adicia.telenet-ops.be (Postfix) with SMTP id 9A18644030 for ; Wed, 18 Aug 2004 00:00:43 +0200 (MEST) Received: from pas (D5778A4F.kabel.telenet.be [213.119.138.79]) by adicia.telenet-ops.be (Postfix) with SMTP id 117D744013 for ; Wed, 18 Aug 2004 00:00:43 +0200 (MEST) Message-ID: <009c01c484a6$2533b600$c400a8c0@pandora.be> From: "Pascal Lambers" To: References: Subject: Re: [Megaco] Modify to do Audit hook state Date: Wed, 18 Aug 2004 00:04:19 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.8 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pascal Lambers List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0935408652==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0935408652== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01C484B6.E8935320" This is a multi-part message in MIME format. ------=_NextPart_000_0099_01C484B6.E8935320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Modify to do Audit hook stateIn this case a separate Audit = Hook status mechanism makes sense. It makes sure there is no influence = on call related funcionality. And as long as the MGC receives the = expected answer it must not take any corrective action. If I'm not = mistaken, MGCP allows a separate Audit. Pascal ----- Original Message -----=20 From: Kevin Boyle=20 To: Pascal Lambers ; megaco@ietf.org=20 Sent: Tuesday, August 17, 2004 11:49 PM Subject: RE: [Megaco] Modify to do Audit hook state The MGC would have to include any events previously present in the = Events descriptor in order to guarantee their continued detection, yes. Kevin=20 -----Original Message-----=20 From: Pascal Lambers [mailto:pascal.lambers@pandora.be]=20 Sent: Tuesday, August 17, 2004 5:03 PM=20 To: megaco@ietf.org=20 Subject: Re: [Megaco] Modify to do Audit hook state=20 Kevin,=20 "The MGC must account for these kinds of issues when it is building = messages".=20 By this you mean, that if the MG returns an error "termination = allready off/on hook", the MGC has no longer any guarantee as to which = events are still programmed on the termination? If so, the strict/exact and strict/state won't be of any help I'm = afraid:=20 the Modify will always overwrite events that were present on the = termination before... and if the MGC just sent this Modify to know = whether the hook status of a termination is still as it expected, = without taking anything else, this is a problem. Do I interpret this = correctly? Pascal=20 ----- Original Message -----=20 From: "Kevin Boyle" =20 To: "Pascal Lambers" ; =20 Sent: Tuesday, August 17, 2004 10:45 PM=20 Subject: RE: [Megaco] Modify to do Audit hook state=20 > The MGC must account for these kinds of issues when it is building=20 messages.=20 >=20 > I would note that there are two other possible values for the strict = parm=20 > that may be of more use: 'state' and 'exact'. If having the MG = generate=20 > errors is a problem, then you could use one of the other two options = > instead.=20 >=20 > Kevin=20 >=20 >=20 >=20 > _____=20 >=20 > From: Pascal Lambers [mailto:pascal.lambers@pandora.be]=20 > Sent: Tuesday, August 17, 2004 4:32 PM=20 > To: megaco@ietf.org=20 > Subject: [Megaco] Modify to do Audit hook state=20 >=20 >=20 > Hello,=20 >=20 > Megaco does not provide an Audit message to audit a termination's = hook=20 > status directly. That's clear.=20 >=20 > Instead, to know whether a termination is Off Hook, the MGC must = send a=20 > Modify with an Off Hook (strict/failWrong) Events descriptor.=20 Consequently,=20 > if the termination is already off hook, the MG will reply with an = error.=20 Is=20 > it sure that in such a case the events and signals implemented on = this=20 > termination before the Modify arrived, are still present? In other = words,=20 is=20 > it sure that messages from the MGC to the MG replied to with an = error do=20 not=20 > have any negative effect?=20 >=20 > Kind regards,=20 > Pascal=20 >=20 >=20 >=20 >=20 > _______________________________________________=20 > Megaco mailing list=20 > Megaco@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/megaco=20 >=20 _______________________________________________=20 Megaco mailing list=20 Megaco@ietf.org=20 https://www1.ietf.org/mailman/listinfo/megaco=20 ------=_NextPart_000_0099_01C484B6.E8935320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Modify to do Audit hook state
In this case a separate Audit Hook = status mechanism=20 makes sense. It makes sure there is no influence on call related = funcionality.=20 And as long as the MGC receives the expected answer it must not take any = corrective action. If I'm not mistaken, MGCP allows a separate=20 Audit.
 
 
Pascal
 
 
----- Original Message -----
From:=20 Kevin Boyle
To: Pascal Lambers ; megaco@ietf.org
Sent: Tuesday, August 17, 2004 = 11:49=20 PM
Subject: RE: [Megaco] Modify to = do Audit=20 hook state

The MGC would have to include any events previously = present in=20 the Events descriptor in order to guarantee their continued detection, = yes.

Kevin

-----Original Message-----
From:=20 Pascal Lambers [mailto:pascal.lambers@pandora.b= e]=20
Sent: Tuesday, August 17, 2004 5:03 = PM=20
To: megaco@ietf.org
Subject: Re: [Megaco] Modify to do Audit hook state =

Kevin,

"The MGC must account for these kinds of issues when = it is=20 building messages".
By this you mean, that = if the MG=20 returns an error "termination allready off/on hook", the MGC has no = longer any=20 guarantee as to which events are still programmed on the=20 termination?

If so, the strict/exact and strict/state won't be of = any help=20 I'm afraid:
the Modify will always overwrite = events=20 that were present on the termination before... and if the MGC just = sent this=20 Modify to know whether the hook status of a termination is still as it = expected, without taking anything else, this is a problem. Do I = interpret this=20 correctly?

Pascal


----- Original Message -----
From:=20 "Kevin Boyle" <kboyle@nortelnetworks.com>
To:=20 "Pascal Lambers" <pascal.lambers@pandora.be>;=20 <megaco@ietf.org>
Sent: Tuesday, = August 17, 2004=20 10:45 PM
Subject: RE: [Megaco] Modify to do = Audit hook=20 state


> The MGC must account for these kinds of issues = when it is=20 building
messages.
>=20
> I would note that there are two other possible = values=20 for the strict parm
> that may be of more = use:=20 'state' and 'exact'.  If having the MG generate
> errors is a problem, then you could use one of the other = two=20 options
> instead.
>
> Kevin
>
>
>=20
>   _____
>=20
> From: Pascal Lambers [mailto:pascal.lambers@pandora.b= e]=20
> Sent: Tuesday, August 17, 2004 4:32 PM =
> To: megaco@ietf.org
> = Subject: [Megaco]=20 Modify to do Audit hook state
> =
>
> Hello,
>
> Megaco does not provide = an Audit=20 message to audit a termination's hook
> = status=20 directly. That's clear.
> =
> Instead, to know whether a termination is Off Hook, the = MGC must=20 send a
> Modify with an Off Hook = (strict/failWrong)=20 Events descriptor.
Consequently, =
> if the termination is already off hook, the MG will = reply with an=20 error.
Is
> it = sure that in=20 such a case the events and signals implemented on this =
> termination before the Modify arrived, are still = present? In other=20 words,
is
> it = sure that=20 messages from the MGC to the MG replied to with an error do =
not
> have any negative = effect?=20
>
> Kind = regards,=20
> Pascal
> =
>
>
>=20
> = _______________________________________________=20
> Megaco mailing list
>=20 Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco =
>


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

------=_NextPart_000_0099_01C484B6.E8935320-- --===============0935408652== 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 --===============0935408652==-- From megaco-bounces@ietf.org Tue Aug 17 19:16:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22419 for ; Tue, 17 Aug 2004 19:16:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxD7u-00008A-Gx; Tue, 17 Aug 2004 19:12:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxD5C-00084S-Sv for megaco@megatron.ietf.org; Tue, 17 Aug 2004 19:09:34 -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 TAA22219 for ; Tue, 17 Aug 2004 19:09:31 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxDBJ-0006ds-2x for megaco@ietf.org; Tue, 17 Aug 2004 19:15:53 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7HN8vd17662 for ; Tue, 17 Aug 2004 19:08:57 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Aug 2004 19:08:58 -0400 Message-ID: From: "Kevin Boyle" To: Pascal Lambers , megaco@ietf.org Subject: RE: [Megaco] Modify to do Audit hook state Date: Tue, 17 Aug 2004 19:08:53 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org I fail to see the need for this. The MGC must account for the current call processing state at all times. It is, after all, the CONTROLLER. It seems to me that the MGC has to know what the current status of the Events descriptor is. If it doesn't know, it can audit the Events descriptor. Any action the MGC takes is up to the MGC, whether the answer is expected or not. It seems to me that terminations that have a hook-state should have either onhook detection or offhook detection in the Events descriptor at all times, unless the term is undergoing some kind of test or is OOS. Otherwise, how will state transitions be detected? By using the 'state' value for the parm, the MG will return the state desired if a) a transition occurs or b) the term is already in that state. This allows the MGC to quickly resync itself with the MG. If the MG does not report the event upon receipt of the events descriptor, then the MGC can assume the hookswitch is in the opposite state and is already looking for the correct transition. If the event is reported, the MGC can update the Events descriptor to change the hookstate detector while still leaving the other events intact. One final comment: What MGCP does or doesn't do is largely irrelevant. H.248 provides the ability for the MGC and MG to get resynced, and that is what matters. Kevin _____ From: Pascal Lambers [mailto:pascal.lambers@pandora.be] Sent: Tuesday, August 17, 2004 6:04 PM To: megaco@ietf.org Subject: Re: [Megaco] Modify to do Audit hook state In this case a separate Audit Hook status mechanism makes sense. It makes sure there is no influence on call related funcionality. And as long as the MGC receives the expected answer it must not take any corrective action. If I'm not mistaken, MGCP allows a separate Audit. Pascal ----- Original Message ----- From: Kevin Boyle To: Pascal Lambers ; megaco@ietf.org Sent: Tuesday, August 17, 2004 11:49 PM Subject: RE: [Megaco] Modify to do Audit hook state The MGC would have to include any events previously present in the Events descriptor in order to guarantee their continued detection, yes. Kevin -----Original Message----- From: Pascal Lambers [mailto:pascal.lambers@pandora.be ] Sent: Tuesday, August 17, 2004 5:03 PM To: megaco@ietf.org Subject: Re: [Megaco] Modify to do Audit hook state Kevin, "The MGC must account for these kinds of issues when it is building messages". By this you mean, that if the MG returns an error "termination allready off/on hook", the MGC has no longer any guarantee as to which events are still programmed on the termination? If so, the strict/exact and strict/state won't be of any help I'm afraid: the Modify will always overwrite events that were present on the termination before... and if the MGC just sent this Modify to know whether the hook status of a termination is still as it expected, without taking anything else, this is a problem. Do I interpret this correctly? Pascal ----- Original Message ----- From: "Kevin Boyle" To: "Pascal Lambers" ; Sent: Tuesday, August 17, 2004 10:45 PM Subject: RE: [Megaco] Modify to do Audit hook state > The MGC must account for these kinds of issues when it is building messages. > > I would note that there are two other possible values for the strict parm > that may be of more use: 'state' and 'exact'. If having the MG generate > errors is a problem, then you could use one of the other two options > instead. > > Kevin > > > > _____ > > From: Pascal Lambers [mailto:pascal.lambers@pandora.be ] > Sent: Tuesday, August 17, 2004 4:32 PM > To: megaco@ietf.org > Subject: [Megaco] Modify to do Audit hook state > > > Hello, > > Megaco does not provide an Audit message to audit a termination's hook > status directly. That's clear. > > Instead, to know whether a termination is Off Hook, the MGC must send a > Modify with an Off Hook (strict/failWrong) Events descriptor. Consequently, > if the termination is already off hook, the MG will reply with an error. Is > it sure that in such a case the events and signals implemented on this > termination before the Modify arrived, are still present? In other words, is > it sure that messages from the MGC to the MG replied to with an error do not > have any negative effect? > > Kind regards, > Pascal > > > > > _______________________________________________ > Megaco mailing 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 Wed Aug 18 12:51: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 MAA21081 for ; Wed, 18 Aug 2004 12:51: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 1BxTVH-0004Ao-8q; Wed, 18 Aug 2004 12:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxTGv-0001FR-It for megaco@megatron.ietf.org; Wed, 18 Aug 2004 12:26: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 MAA19232 for ; Wed, 18 Aug 2004 12:26:42 -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 1BxTN9-0000hE-SP for megaco@ietf.org; Wed, 18 Aug 2004 12:33:13 -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 i7IG1CRE020588; Wed, 18 Aug 2004 16:01:12 GMT To: raymond.forbes@MARCONI.COM, jan.lindquist@ericsson.com, d.chohan@ftel.co.uk X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Wed, 18 Aug 2004 18:01:10 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 08/18/2004 18:01:11 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Alcanet-virus-scanned: i7IG1CRE020588 at mailrelay2.alcatel.de X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: TISPAN_WG3@LIST.ETSI.ORG, megaco@ietf.org, itu-sg16@external.cisco.com Subject: [Megaco] H.248.V5 vs H.248.STIMAL; Re: [LS to SG16 RGW stimal package] Approved 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 Dear All! A proposal for a H.248 V5 Package was presented at the last WP2/16 meet= ing: http://ftp3.itu.int/av-arch/avc-site/0405_Bei/AVD-2502a.zip Question: is H.248.STIMAL replacing the H.248.V5 package proposal? Thanks for clarification! Best regards Albrecht Raymond Forbes @LIST.ETSI.ORG> on 18/08/200= 4 17:33:46 Please respond to Raymond Forbes Sent by: "TISPAN_WG3: Protocols" To: TISPAN_WG3@LIST.ETSI.ORG cc: Subject: Fw: [LS to SG16 RGW stimal package] Approved WG3 delegates, The Liaison Statement to ITU SG16 is now approved, see attachment. Regards, Ray Forbes. (TISPAN WG3 Chairman) +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. =A0If you are not the= intended recipient, please notify us immediately by reply e-mail and th= en delete this message from your system. (See attached file: 03bTDxxx LS_to_SG16_on_stimal_pkg_v2 approved.doc) = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Aug 18 12:56: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 MAA21554 for ; Wed, 18 Aug 2004 12:56: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 1BxTWr-0004SA-GJ; Wed, 18 Aug 2004 12:43:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxTOb-0002ds-IL for megaco@megatron.ietf.org; Wed, 18 Aug 2004 12:34:41 -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 MAA19738 for ; Wed, 18 Aug 2004 12:34:38 -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 1BxTUp-0000rk-Ux for megaco@ietf.org; Wed, 18 Aug 2004 12:41:09 -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 i7IG1CRE020588; Wed, 18 Aug 2004 16:01:12 GMT To: raymond.forbes@MARCONI.COM, jan.lindquist@ericsson.com, d.chohan@ftel.co.uk X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Wed, 18 Aug 2004 18:01:10 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 08/18/2004 18:01:11 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: TISPAN_WG3@LIST.ETSI.ORG, megaco@ietf.org, itu-sg16@external.cisco.com Subject: [Megaco] H.248.V5 vs H.248.STIMAL; Re: [LS to SG16 RGW stimal package] Approved 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 Dear All! A proposal for a H.248 V5 Package was presented at the last WP2/16 meet= ing: http://ftp3.itu.int/av-arch/avc-site/0405_Bei/AVD-2502a.zip Question: is H.248.STIMAL replacing the H.248.V5 package proposal? Thanks for clarification! Best regards Albrecht Raymond Forbes @LIST.ETSI.ORG> on 18/08/200= 4 17:33:46 Please respond to Raymond Forbes Sent by: "TISPAN_WG3: Protocols" To: TISPAN_WG3@LIST.ETSI.ORG cc: Subject: Fw: [LS to SG16 RGW stimal package] Approved WG3 delegates, The Liaison Statement to ITU SG16 is now approved, see attachment. Regards, Ray Forbes. (TISPAN WG3 Chairman) +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. =A0If you are not the= intended recipient, please notify us immediately by reply e-mail and th= en delete this message from your system. (See attached file: 03bTDxxx LS_to_SG16_on_stimal_pkg_v2 approved.doc) = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Aug 18 13:05:00 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 NAA22172 for ; Wed, 18 Aug 2004 13:05: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 1BxTnx-0007jQ-C9; Wed, 18 Aug 2004 13:00:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxTXA-0004Ul-6L for megaco@megatron.ietf.org; Wed, 18 Aug 2004 12:43: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 MAA20511 for ; Wed, 18 Aug 2004 12:43:29 -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 1BxTdM-00017C-PQ for megaco@ietf.org; Wed, 18 Aug 2004 12:50:00 -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 i7IG1CRE020588; Wed, 18 Aug 2004 16:01:12 GMT To: raymond.forbes@MARCONI.COM, jan.lindquist@ericsson.com, d.chohan@ftel.co.uk X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Wed, 18 Aug 2004 18:01:10 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 08/18/2004 18:01:11 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: TISPAN_WG3@LIST.ETSI.ORG, megaco@ietf.org, itu-sg16@external.cisco.com Subject: [Megaco] H.248.V5 vs H.248.STIMAL; Re: [LS to SG16 RGW stimal package] Approved 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 Dear All! A proposal for a H.248 V5 Package was presented at the last WP2/16 meet= ing: http://ftp3.itu.int/av-arch/avc-site/0405_Bei/AVD-2502a.zip Question: is H.248.STIMAL replacing the H.248.V5 package proposal? Thanks for clarification! Best regards Albrecht Raymond Forbes @LIST.ETSI.ORG> on 18/08/200= 4 17:33:46 Please respond to Raymond Forbes Sent by: "TISPAN_WG3: Protocols" To: TISPAN_WG3@LIST.ETSI.ORG cc: Subject: Fw: [LS to SG16 RGW stimal package] Approved WG3 delegates, The Liaison Statement to ITU SG16 is now approved, see attachment. Regards, Ray Forbes. (TISPAN WG3 Chairman) +44 24 7656 3106 phone +44 24 7656 3816 fax. +44 771 851 1361 Mobile/text ------------ This e-mail and any attachments are confidential. =A0If you are not the= intended recipient, please notify us immediately by reply e-mail and th= en delete this message from your system. (See attached file: 03bTDxxx LS_to_SG16_on_stimal_pkg_v2 approved.doc) = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Aug 19 04:29:06 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 EAA12345 for ; Thu, 19 Aug 2004 04:29:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxiDT-0003iE-07; Thu, 19 Aug 2004 04:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxi9T-0002xi-1W for megaco@megatron.ietf.org; Thu, 19 Aug 2004 04:20:03 -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 EAA11796 for ; Thu, 19 Aug 2004 04:20:01 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxiFd-0006YW-LD for megaco@ietf.org; Thu, 19 Aug 2004 04:26:39 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7J8JlAh014988 for ; Thu, 19 Aug 2004 10:19:47 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Aug 2004 10:19:47 +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 QZMC8ZFB; Thu, 19 Aug 2004 10:19:47 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.22.56]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id RAHRKCMN; Thu, 19 Aug 2004 18:19:44 +1000 Message-ID: <4120137C.6000404@ericsson.com> Date: Mon, 16 Aug 2004 11:53:00 +1000 X-Sybari-Trust: 44dad712 74470f8f 281d1819 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: Gillian Wang Subject: Re: [Megaco] Profile negotiation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Aug 2004 08:19:47.0557 (UTC) FILETIME=[4A585150:01C485C5] 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 Hello Gillian, A profile is a description of the capabilities of a H.248 interface. The MG can signal to a MGC that it can support certain profile/s. Using H.248 servicechange procedures the MGC can agree to use a certain profile. Once both the MGC and MG have agreed then the H.248 interface is limited to the functionality described in the profile. So the agreement on the profile is dynamic. The actual definition of the contents is static. Hopefully in the H.248.1v3 time frame we'll further enhance the definition of profiles. Regards, Christian Gillian Wang wrote: > Dear Megaco members, > > I'm trying to figure out how the Profile works in normal H.248 procedures. > > For a MG implementation, it needs to have some agreement with MGC about the > packages supported, naming conventions, digit map listings, etc before > startup. They are specified in a Profile. How is the agreement achieved? I > believe this is done via both parties implementing their own H.248 stack on > the same profile agreement rather than a dynamic procedure. is it correct? > I also noticed that the ServiceChange descriptor had a parameter referred to > a profile supported. Is it specified for the dynamic negotiation procedure > or information only? > > As for a digitmap which can be preloaded from the MGC, is it also outside > the normal H.248 procedure? > > Thanks > 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 Thu Aug 19 08:38: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 IAA27438 for ; Thu, 19 Aug 2004 08:38: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 1Bxm8F-0002pg-5C; Thu, 19 Aug 2004 08:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxm3P-0001aI-7j for megaco@megatron.ietf.org; Thu, 19 Aug 2004 08:30:03 -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 IAA26825 for ; Thu, 19 Aug 2004 08:30:02 -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 1Bxm9o-0002wS-7v for megaco@ietf.org; Thu, 19 Aug 2004 08:36:41 -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 i7JC6PRE022368; Thu, 19 Aug 2004 12:06:25 GMT In-Reply-To: <9547F8D6CC905145998556EF241A129C0B67CDE8@ESEALNT876.al.sw.ericsson.se> To: "Jan Lindquist (AL/EAB)" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Thu, 19 Aug 2004 14:06:22 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 08/19/2004 14:06:24 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Alcanet-virus-scanned: i7JC6PRE022368 at mailrelay2.alcatel.de X-Spam-Score: 0.3 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable Cc: TISPAN_WG3@LIST.ETSI.ORG, megaco@ietf.org, itu-sg16@external.cisco.com Subject: [Megaco] Stimulus Control Protocol; Re: H.248.V5 vs H.248.STIMAL; Re: [LS to SG16 RGW stimal package ] Approved 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 Just another thought when reading the package. I know, it's farfetched, but there seems to be already a "similar" solu= tion defined: There's already an H.248-based Stimulus Control Protocol: H.323 Annex = L. Annex L incorporates Simple Endpoint Types (SET) according H.323 Annex = F. Annex F incorporates "telephones with an RJ-45 connector", i.e., POTS terminals. =3D> for that specific network scenario, and from a high-level perspect= ive, there are obviously overlappings (e.g., analog line, H.248 control interface, stimulus control concept). But I guess that the comparison of H.248.STIMAL versus H.248-based H.32= 3 Annex L is inappropriate, mainly because - H.323 Annex L still uses normal call establihsment procedures of H.22= 5.0 - H.323 Annex L approach is scoping supplementary services, not basic c= all setup/release - H.248.STIMAL is scoping basic call service, PSTN supplementary servic= e are for instance scope of H.248.23 just an idea, Albrecht = =20 "Jan Lindquist = =20 (AL/EAB)" To: TISPAN_WG3@LIS= T.ETSI.ORG =20 Subject: Re: H.248.V5 v= s H.248.STIMAL; Re: [LS to SG16 RGW stimal package ] Approved =20 Sent by: = =20 "TISPAN_WG3: = =20 Protocols" = =20 = =20 = =20 = =20 19.08.2004 10:49 = =20 Please respond to = =20 "Jan Lindquist = =20 (AL/EAB)" = =20 = =20 Hello Albrecht, Actually the first liaison you refer to is indicating to SG16 the inten= tion of TISPAN WG3 to create a new package, at the time there was no agreed package or package name. The new liaison indicates that there is now a= package defined called stimal package and that there is an ambition to perform a joint publication between TISPAN and ITU-T, for more details refer to the new liaison. I hope this answers your question. Best regards, JanL > -----Original Message----- > From: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de= ] > Sent: den 18 augusti 2004 18:01 > To: raymond.forbes@MARCONI.COM; Jan Lindquist (AL/EAB); > d.chohan@ftel.co.uk > Cc: TISPAN_WG3@LIST.ETSI.ORG; megaco@ietf.org; > itu-sg16@external.cisco.com > Subject: H.248.V5 vs H.248.STIMAL; Re: [LS to SG16 RGW stimal package= ] > Approved > > > Dear All! > > A proposal for a H.248 V5 Package was presented at the last > WP2/16 meeting: > http://ftp3.itu.int/av-arch/avc-site/0405_Bei/AVD-2502a.zip > > Question: is H.248.STIMAL replacing the H.248.V5 package proposal? > > Thanks for clarification! > Best regards > Albrecht > > > Raymond Forbes @LIST.ETSI.ORG> on > 18/08/2004 > 17:33:46 > > Please respond to Raymond Forbes > > Sent by: "TISPAN_WG3: Protocols" > > > To: TISPAN_WG3@LIST.ETSI.ORG > cc: > Subject: Fw: [LS to SG16 RGW stimal package] Approved > > > > WG3 delegates, > > The Liaison Statement to ITU SG16 is now approved, see attachment. > > Regards, > > Ray Forbes. (TISPAN WG3 Chairman) > > +44 24 7656 3106 phone > +44 24 7656 3816 fax. > +44 771 851 1361 Mobile/text > ------------ > This e-mail and any attachments are confidential. =A0If you are not t= he > intended recipient, please notify us immediately by reply > e-mail and then > delete this message from your system. > > (See attached file: 03bTDxxx LS_to_SG16_on_stimal_pkg_v2 approved.doc= ) > > > ------------------------------------------------------------------- Mail archive for TISPAN_WG3 can be browsed at the following url : http://list.etsi.org/TISPAN_WG3.html ------------------------------------------------------------------- = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Aug 20 14:56: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 OAA05845 for ; Fri, 20 Aug 2004 14:56: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 1ByE2m-0004xr-8s; Fri, 20 Aug 2004 14:23:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByCkf-0003il-Gz for megaco@megatron.ietf.org; Fri, 20 Aug 2004 13:00: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 NAA27584 for ; Fri, 20 Aug 2004 13:00:21 -0400 (EDT) Received: from apate.telenet-ops.be ([195.130.132.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByCrC-0003Ue-9e for megaco@ietf.org; Fri, 20 Aug 2004 13:07:17 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by apate.telenet-ops.be (Postfix) with SMTP id 7B9C3248098 for ; Fri, 20 Aug 2004 19:00:18 +0200 (MEST) Received: from pas (D577886C.kabel.telenet.be [213.119.136.108]) by apate.telenet-ops.be (Postfix) with SMTP id 2B8D3248116 for ; Fri, 20 Aug 2004 19:00:18 +0200 (MEST) Message-ID: <001a01c486d7$b2c0ffe0$c400a8c0@pandora.be> From: "Pascal Lambers" To: Date: Fri, 20 Aug 2004 19:04:04 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.5 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Megaco] MG termination physically broken X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pascal Lambers List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0155230318==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0155230318== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C486E8.760FD420" This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C486E8.760FD420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, If a Termination on a Mediagateway has a physical or other permanent = problem, can the MGC count on the MG answering to messages for that = termination as long as the MG itself and the network are OK ? This is an important question because a MGC must have a way of finding = out whether only that termination is in trouble or whether the whole MG = is in trouble.... Kind regards, Pascal ------=_NextPart_000_0017_01C486E8.760FD420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
If a Termination on a Mediagateway has=20 a physical or other permanent problem, can the MGC count = on the=20 MG answering to messages for that termination as long as the MG itself = and the=20 network are OK ?
 
This is an important question because a = MGC must=20 have a way of finding out whether only that termination is in trouble or = whether=20 the whole MG is in trouble....
 
Kind regards,
Pascal
 
 
------=_NextPart_000_0017_01C486E8.760FD420-- --===============0155230318== 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 --===============0155230318==-- From megaco-bounces@ietf.org Fri Aug 20 17:06:59 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 RAA14103 for ; Fri, 20 Aug 2004 17:06: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 1ByG5v-0005BS-9j; Fri, 20 Aug 2004 16:34:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByFah-0005Ca-Hm for megaco@megatron.ietf.org; Fri, 20 Aug 2004 16:02: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 QAA10328 for ; Fri, 20 Aug 2004 16:02:16 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByFhG-0007V1-Vo for megaco@ietf.org; Fri, 20 Aug 2004 16:09:14 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7KK1VU14830 for ; Fri, 20 Aug 2004 16:01:31 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Aug 2004 16:01:31 -0400 Message-ID: <1E7140413C19AD4E827D63B820A24D2BCAF7C1@zrtphxm2.corp.nortel.com> From: "Kevin Boyle" To: Pascal Lambers , megaco@ietf.org Subject: RE: [Megaco] MG termination physically broken Date: Fri, 20 Aug 2004 16:01:17 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Just because a term is out of service doesn't mean the MG should act as if it doesn't exist. If the term starts having trouble, the MG would send a ServiceChange to take it OOS. The MG still has to respond to commands for that term, either by performing the commands, or sending errors back. Kevin _____ From: Pascal Lambers [mailto:pascal.lambers@pandora.be] Sent: Friday, August 20, 2004 1:04 PM To: megaco@ietf.org Subject: [Megaco] MG termination physically broken Hello, If a Termination on a Mediagateway has a physical or other permanent problem, can the MGC count on the MG answering to messages for that termination as long as the MG itself and the network are OK ? This is an important question because a MGC must have a way of finding out whether only that termination is in trouble or whether the whole MG is in trouble.... Kind regards, Pascal _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 23 00:11:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22552 for ; Mon, 23 Aug 2004 00:11:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz5y8-0000I8-Dq; Sun, 22 Aug 2004 23:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz5lL-0007NI-Rk for megaco@megatron.ietf.org; Sun, 22 Aug 2004 23:44: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 XAA20526 for ; Sun, 22 Aug 2004 23:44:44 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bz5lF-0002iQ-3e for megaco@ietf.org; Sun, 22 Aug 2004 23:45:01 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7N3iOWR024668 for ; Mon, 23 Aug 2004 05:44:28 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Aug 2004 05:44:24 +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 QZMDYADA; Mon, 23 Aug 2004 05:44:24 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.22.54]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id RAHRML7D; Mon, 23 Aug 2004 13:44:20 +1000 Message-ID: <41296854.9080300@ericsson.com> Date: Mon, 23 Aug 2004 13:45:24 +1000 X-Sybari-Trust: 1c731a64 74470f8f 29c5553b 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: Hakan Mattsson Subject: Re: [Megaco] Re: IndAudlocalControlDescriptor inconsistency References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 23 Aug 2004 03:44:24.0537 (UTC) FILETIME=[7B828C90:01C488C3] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.ericsson.se id i7N3iOWR024668 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 Hello Hakan, H.248.1 sect 7.2.5 states: "It is possible to audit multiple individual i= tems in=20 one request." So it seems the ABNF needs to be updated to accomodate multiple propertie= s. Your=20 suggestion seems OK to me. As this is a syntax change it probably should = be=20 incorporate as a change to H.248.1v3. Regards, Christian Hakan Mattsson wrote: > Please, can someone clarify this issue? >=20 > I did not get any replies at all on the posting below. >=20 > /H=E5kan >=20 > On Mon, 9 Aug 2004, Hakan Mattsson wrote: >=20 > HM> Date: Mon, 9 Aug 2004 17:55:26 +0200 (CEST) > HM> From: Hakan Mattsson > HM> To: megaco@ietf.org > HM> Subject: IndAudlocalControlDescriptor inconsistency > HM>=20 > HM>=20 > HM> In the ASN.1 specification of IndAudLocalControlDescriptor it is > HM> allowed with one each of stream mode, reserve value and reserve gro= up > HM> plus a any number of package names: > HM>=20 > HM>=20 > HM> IndAudLocalControlDescriptor ::=3D SEQUENCE=20 > HM> {=20 > HM> streamMode NULL OPTIONAL,=20 > HM> reserveValue NULL OPTIONAL,=20 > HM> reserveGroup NULL OPTIONAL,=20 > HM> propertyParms SEQUENCE OF IndAudPropertyParm OPT= IONAL,=20 > HM> ...=20 > HM> }=20 > HM> =20 > HM> IndAudPropertyParm ::=3D SEQUENCE=20 > HM> {=20 > HM> name PkgdName,=20 > HM> ...=20 > HM> }=20 > HM> =20 > HM> while it in the ABNF specification of indAudlocalControlDescriptor = is > HM> limited to be exactly one of stream mode, reserve value, reserve gr= oup > HM> and package name: > HM>=20 > HM> indAudlocalControlDescriptor =3D LocalControlToken =20 > HM> LBRKT indAudlocalParm RBRKT=20 > HM> =20 > HM> ; at-most-once per item=20 > HM> indAudlocalParm =3D ( ModeToken / pkgdName /=20 > HM> ReservedValueToken /=20 > HM> ReservedGroupToken )=20 > HM>=20 > HM> For example this means that it is possible to have both stream mode > HM> and package name in ASN.1, while this is not allowed in ABNF. > HM>=20 > HM> To me this looks like a bug in the Megaco standard as the ASN.1 > HM> encoding and ABNF encoding is not semantically equivalent in this > HM> case. > HM>=20 > HM> I suggest that the ABNF should be changed to the following in order= to > HM> be compliant with ASN.1: > HM>=20 > HM> indAudlocalControlDescriptor =3D LocalControlToken =20 > HM> LBRKT indAudlocalParm *(COMMA indAudlocalP= arm) RBRKT=20 > HM>=20 > HM> I would appreciate if someone on the list could clarify whether thi= s > HM> Megaco bug is in ABNF or ASN.1. > HM>=20 > HM> /H=E5kan > HM>=20 > HM> --- > HM> H=E5kan Mattsson, Ericsson AB > HM> High Availability Software, DBMS Internals > HM> http://www.erlang.org/~hakan/ > HM>=20 > HM>=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 Aug 23 10:17:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10689 for ; Mon, 23 Aug 2004 10:17:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzFMW-0004N3-An; Mon, 23 Aug 2004 09:59:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxibl-0006oz-TW for megaco@megatron.ietf.org; Thu, 19 Aug 2004 04:49: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 EAA13432 for ; Thu, 19 Aug 2004 04:49:16 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxiiA-00075y-0a for megaco@ietf.org; Thu, 19 Aug 2004 04:55:54 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7J8nFWR019983 for ; Thu, 19 Aug 2004 10:49:15 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Aug 2004 10:49:15 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 19 Aug 2004 10:49:15 +0200 Message-ID: <9547F8D6CC905145998556EF241A129C0B67CDE8@ESEALNT876.al.sw.ericsson.se> From: "Jan Lindquist (AL/EAB)" To: "'Albrecht.Schwarz@alcatel.de'" , raymond.forbes@MARCONI.COM, d.chohan@ftel.co.uk Date: Thu, 19 Aug 2004 10:49:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 19 Aug 2004 08:49:15.0814 (UTC) FILETIME=[684EEC60:01C485C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 23 Aug 2004 09:59:51 -0400 Cc: TISPAN_WG3@LIST.ETSI.ORG, megaco@ietf.org, itu-sg16@external.cisco.com Subject: [Megaco] RE: H.248.V5 vs H.248.STIMAL; Re: [LS to SG16 RGW stimal package ] Approved 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 Hello Albrecht, Actually the first liaison you refer to is indicating to SG16 the = intention of TISPAN WG3 to create a new package, at the time there was = no agreed package or package name. The new liaison indicates that = there is now a package defined called stimal package and that there is = an ambition to perform a joint publication between TISPAN and ITU-T, = for more details refer to the new liaison. I hope this answers your question. Best regards, JanL > -----Original Message----- > From: Albrecht.Schwarz@alcatel.de = [mailto:Albrecht.Schwarz@alcatel.de] > Sent: den 18 augusti 2004 18:01 > To: raymond.forbes@MARCONI.COM; Jan Lindquist (AL/EAB); > d.chohan@ftel.co.uk > Cc: TISPAN_WG3@LIST.ETSI.ORG; megaco@ietf.org; > itu-sg16@external.cisco.com > Subject: H.248.V5 vs H.248.STIMAL; Re: [LS to SG16 RGW stimal = package] > Approved >=20 >=20 > Dear All! >=20 > A proposal for a H.248 V5 Package was presented at the last=20 > WP2/16 meeting: > http://ftp3.itu.int/av-arch/avc-site/0405_Bei/AVD-2502a.zip >=20 > Question: is H.248.STIMAL replacing the H.248.V5 package proposal? >=20 > Thanks for clarification! > Best regards > Albrecht >=20 >=20 > Raymond Forbes @LIST.ETSI.ORG> on=20 > 18/08/2004 > 17:33:46 >=20 > Please respond to Raymond Forbes >=20 > Sent by: "TISPAN_WG3: Protocols" >=20 >=20 > To: TISPAN_WG3@LIST.ETSI.ORG > cc: > Subject: Fw: [LS to SG16 RGW stimal package] Approved >=20 >=20 >=20 > WG3 delegates, >=20 > The Liaison Statement to ITU SG16 is now approved, see attachment. >=20 > Regards, >=20 > Ray Forbes. (TISPAN WG3 Chairman) >=20 > +44 24 7656 3106 phone > +44 24 7656 3816 fax. > +44 771 851 1361 Mobile/text > ------------ > This e-mail and any attachments are confidential. =A0If you are not = the > intended recipient, please notify us immediately by reply=20 > e-mail and then > delete this message from your system. >=20 > (See attached file: 03bTDxxx LS_to_SG16_on_stimal_pkg_v2 = approved.doc) >=20 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Aug 27 17:13: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 RAA11384 for ; Fri, 27 Aug 2004 17:13: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 1C0nvJ-0003eJ-9t; Fri, 27 Aug 2004 17:06:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0nnj-0001KH-Rp for megaco@megatron.ietf.org; Fri, 27 Aug 2004 16:58: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 QAA10402 for ; Fri, 27 Aug 2004 16:58:20 -0400 (EDT) Received: from mx2.conexion.com.py ([65.198.40.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0nos-0004ns-5r for megaco@ietf.org; Fri, 27 Aug 2004 16:59:38 -0400 Received: from carlos (asudoor.conexion.com.py [65.198.40.11]) by mx2.conexion.com.py (8.12.10/8.12.10) with SMTP id i7RKvmVX001006 for ; Fri, 27 Aug 2004 16:57:49 -0400 Message-ID: <002a01c48c7b$35eb5de0$bb0aa8c0@carlos> From: "Carlos Rodriguez Alcala" To: References: <001901c38127$f1676a60$6600a8c0@carlos> <3F6F66FB.7020603@nortelnetworks.com> Date: Fri, 27 Aug 2004 17:17:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-ConexionGroup-MailScanner-Information: Please contact the ISP for more information X-ConexionGroup-MailScanner: Found to be clean X-ConexionGroup-MailScanner-SpamCheck: no es spam (whitelisted), SpamAssassin (puntaje=-4.9, requerido 3, autolearn=not spam, BAYES_00 -4.90) X-MailScanner-From: crav@conexion.com.py X-MailScanner-To: megaco@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Megaco] R2 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 there, there are nor one "annex R2" ???? only a draft ??? Thanks crav _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 30 03:08: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 DAA26507 for ; Mon, 30 Aug 2004 03:08: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 1C1gG3-0003yO-Nb; Mon, 30 Aug 2004 03:07:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1gEJ-0003mw-QH for megaco@megatron.ietf.org; Mon, 30 Aug 2004 03:05: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 DAA26398 for ; Mon, 30 Aug 2004 03:05:26 -0400 (EDT) Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1gFz-0003mA-E1 for megaco@ietf.org; Mon, 30 Aug 2004 03:07:14 -0400 Received: from vies1k7x.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i7U74mEP013434 for ; Mon, 30 Aug 2004 09:04:48 +0200 Received: from vies194a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i7U74lnW016402 for ; Mon, 30 Aug 2004 09:04:48 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Aug 2004 09:06:48 +0200 Message-ID: From: Kalleitner Franz To: megaco@ietf.org Date: Mon, 30 Aug 2004 09:06:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] SDP equivalents 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 Dear Megaco-List members, I would be interested in finding an implementation rule concerning SDP equivalents. As known the SDP lines can be imbedded as octet string in the binary encoded H248 local and remote descriptor. Further, as PkgdName the native property tags specified in Annex C11 = are used, to address specific SDP lines (e.g v=3D,m=3D,...) I wonder if the octet string includes the SDP description types as v=3D,m=3D,.... since this information is already present with the = property tag. I found nowhere a clear statement if these SDP "prefixes" are still = part of the octet string or not. It would be great if somebody could respond if variant 1 or 2 is the = correct format: Variant 1 (with SDP line descriptor 'm=3D'): .... localDescriptor { propGps { { { name =B40000B00F=B4H // SDP_M value { =B4m=3Daudio $ RTP/AVP 96' } } } } } Variant 2 (without SDP line descriptors 'm=3D'): .... localDescriptor { propGps { { { name =B40000B00F=B4H // SDP_M value { =B4audio $ RTP/AVP 96' } } } } } =09 =09 Thanks ! _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 30 10:20:42 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 KAA26930 for ; Mon, 30 Aug 2004 10:20:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1mwh-0003vT-V8; Mon, 30 Aug 2004 10:15:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1mr1-00026i-JH for megaco@megatron.ietf.org; Mon, 30 Aug 2004 10:09:52 -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 KAA25865 for ; Mon, 30 Aug 2004 10:09:49 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1msm-000522-JQ for megaco@ietf.org; Mon, 30 Aug 2004 10:11:41 -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 i7UE95928416; Mon, 30 Aug 2004 10:09:05 -0400 (EDT) Received: from [47.130.17.106] (acart237.ca.nortel.com [47.130.17.106]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALTHMDT; Mon, 30 Aug 2004 10:09:05 -0400 Message-ID: <413334FF.9040004@nortelnetworks.com> Date: Mon, 30 Aug 2004 10:09:03 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlos Rodriguez Alcala Subject: Re: [Megaco] R2 References: <002a01c48c7b$35eb5de0$bb0aa8c0@carlos> In-Reply-To: <002a01c48c7b$35eb5de0$bb0aa8c0@carlos> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 R2 is handled by the packages defined in H.248.25 and H.248.28. Carlos Rodriguez Alcala wrote: > Hi there, > > there are nor one "annex R2" ???? > only a draft ??? > Thanks > crav > > > _______________________________________________ > Megaco mailing 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 Aug 30 10:26: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 KAA27431 for ; Mon, 30 Aug 2004 10:26:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1n0K-0004ue-Ej; Mon, 30 Aug 2004 10:19:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1mwI-0003ka-2E for megaco@megatron.ietf.org; Mon, 30 Aug 2004 10:15:19 -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 KAA26335 for ; Mon, 30 Aug 2004 10:15:15 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1my3-000584-0K for megaco@ietf.org; Mon, 30 Aug 2004 10:17:08 -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 i7UEEXD02015; Mon, 30 Aug 2004 10:14:33 -0400 (EDT) Received: from [47.130.17.106] (acart237.ca.nortel.com [47.130.17.106]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALTHMF2; Mon, 30 Aug 2004 10:14:34 -0400 Message-ID: <41333648.7000304@nortelnetworks.com> Date: Mon, 30 Aug 2004 10:14:32 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kalleitner Franz Subject: Re: [Megaco] SDP equivalents References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 In my opinion, the second form would be the right one, but let's hear fro= m peoplke=20 who have implemented binary. Kalleitner Franz wrote: > Dear Megaco-List members, >=20 > I would be interested in finding an implementation rule concerning SDP > equivalents. > As known the SDP lines can be imbedded as octet string in the binary > encoded H248 local and remote descriptor. > Further, as PkgdName the native property tags specified in Annex C11 ar= e > used, to address specific SDP lines (e.g v=3D,m=3D,...) >=20 > I wonder if the octet string includes the SDP description types as > v=3D,m=3D,.... since this information is already present with the prope= rty tag. > I found nowhere a clear statement if these SDP "prefixes" are still par= t of > the octet string or not. > It would be great if somebody could respond if variant 1 or 2 is the=20 > correct > format: >=20 > Variant 1 (with SDP line descriptor 'm=3D'): > .... > localDescriptor { > propGps { > { > { > name =B40000B00F=B4H // SDP_M > value { > =B4m=3Daudio $ RTP/AVP 96' } } = } } } >=20 > Variant 2 (without SDP line descriptors 'm=3D'): > .... > localDescriptor { > propGps { > { > { > name =B40000B00F=B4H // SDP_M > value { > =B4audio $ RTP/AVP 96' } } } } = } > =20 > =20 > Thanks ! >=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 Aug 30 12:13: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 MAA04799 for ; Mon, 30 Aug 2004 12:13:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1oah-00032J-W1; Mon, 30 Aug 2004 12:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1oTU-0007nl-EE for megaco@megatron.ietf.org; Mon, 30 Aug 2004 11:53:40 -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 LAA03719 for ; Mon, 30 Aug 2004 11:53:37 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1oVH-0007Dj-Sm for megaco@ietf.org; Mon, 30 Aug 2004 11:55:32 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i7UFrcOS015052; Mon, 30 Aug 2004 08:53:38 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i7UFrK54008448; Mon, 30 Aug 2004 10:53:21 -0500 Message-Id: <5.2.1.1.0.20040830113704.04685e88@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 30 Aug 2004 11:38:53 -0400 To: Tom Taylor, Kalleitner Franz From: Aleksandr Ryabin Subject: Re: [Megaco] SDP equivalents In-Reply-To: <41333648.7000304@nortelnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 I agree, second form is the right one. Aleks At 10:14 AM 8/30/2004, Tom Taylor wrote: >In my opinion, the second form would be the right one, but let's hear from= =20 >peoplke who have implemented binary. > >Kalleitner Franz wrote: > >>Dear Megaco-List members, >>I would be interested in finding an implementation rule concerning SDP >>equivalents. >>As known the SDP lines can be imbedded as octet string in the binary >>encoded H248 local and remote descriptor. >>Further, as PkgdName the native property tags specified in Annex C11 are >>used, to address specific SDP lines (e.g v=3D,m=3D,...) >>I wonder if the octet string includes the SDP description types as >>v=3D,m=3D,.... since this information is already present with the property= tag. >>I found nowhere a clear statement if these SDP "prefixes" are still part= of >>the octet string or not. >>It would be great if somebody could respond if variant 1 or 2 is the= correct >>format: >>Variant 1 (with SDP line descriptor 'm=3D'): >>.... >>localDescriptor { >> propGps { >> { >> { >> name =B40000B00F=B4H // SDP_M >> value { >> =B4m=3Daudio $ RTP/AVP 96' } } }= } } >>Variant 2 (without SDP line descriptors 'm=3D'): >>.... >>localDescriptor { >> propGps { >> { >> { >> name =B40000B00F=B4H // SDP_M >> value { >> =B4audio $ RTP/AVP 96' } } } } } >> >> >>Thanks ! >> >>_______________________________________________ >>Megaco mailing 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 Aug 30 12:47: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 MAA07621 for ; Mon, 30 Aug 2004 12:47: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 1C1pDZ-0004Kp-9h; Mon, 30 Aug 2004 12:41:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1p4c-00034z-IG for megaco@megatron.ietf.org; Mon, 30 Aug 2004 12:32:03 -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 MAA06168 for ; Mon, 30 Aug 2004 12:31:59 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1p6N-0007zB-ER for megaco@ietf.org; Mon, 30 Aug 2004 12:33:54 -0400 Received: from wink.ho.lucent.com (h135-112-126-3.lucent.com [135.112.126.3]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7UGVu4N010010 for ; Mon, 30 Aug 2004 11:31:56 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id MAA13796; Mon, 30 Aug 2004 12:31:53 -0400 (EDT) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id MAA13792; Mon, 30 Aug 2004 12:31:53 -0400 (EDT) Message-ID: <4133566E.7000303@bell-labs.com> Date: Mon, 30 Aug 2004 12:31:42 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org, franz.kalleitner@siemens.com, taylor@nortelnetworks.com Subject: Re: [Megaco] SDP equivalents References: <200408301607.i7UG7r2p023262@hoemail1.lucent.com> In-Reply-To: <200408301607.i7UG7r2p023262@hoemail1.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail1.lucent.com id i7UGVu4N010010 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable 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 We implemented the second form. Don't miss the "double wrapping" defined in the Recommendation. -troy taylor@nortelnetworks.com wrote: >=20 > In my opinion, the second form would be the right one, but let's hear f= rom peoplke=20 > who have implemented binary. >=20 > Kalleitner Franz wrote: >=20 >=20 >>Dear Megaco-List members, >> >>I would be interested in finding an implementation rule concerning SDP >>equivalents. >>As known thec SDP lines an be imbedded as octet string in the binary >>encoded H248 local and remote descriptor. >>Further, as PkgdName the native property tags specified in Annex C11 ar= e >>used, to address specific SDP lines (e.g v=3D,m=3D,...) >> >>I wonder if the octet string includes the SDP description types as >>v=3D,m=3D,.... since this information is already present with the prope= rty tag. >>I found nowhere a clear statement if these SDP "prefixes" are still par= t of >>the octet string or not. >>It would be great if somebody could respond if variant 1 or 2 is the=20 >>correct >>format: >> >>Variant 1 (with SDP line descriptor 'm=3D'): >>.... >>localDescriptor { >> propGps { >> { >> { >> name =B40000B00F=B4H // SDP_M >> value { >> =B4m=3Daudio $ RTP/AVP 96' } } = } } } >> >>Variant 2 (without SDP line descriptors 'm=3D'): >>.... >>localDescriptor { >> propGps { >> { >> { >> name =B40000B00F=B4H // SDP_M >> value { >> =B4audio $ RTP/AVP 96' } } } } = } >> =20 >> =20 >>Thanks ! _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Aug 30 12:48: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 MAA07710 for ; Mon, 30 Aug 2004 12:48: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 1C1pFm-0004un-Uz; Mon, 30 Aug 2004 12:43:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1p63-0003LT-Pd for megaco@megatron.ietf.org; Mon, 30 Aug 2004 12:33:31 -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 MAA06303 for ; Mon, 30 Aug 2004 12:33:28 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1p7q-00080J-OX for megaco@ietf.org; Mon, 30 Aug 2004 12:35:24 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7UGWwS24082 for ; Mon, 30 Aug 2004 12:32:58 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Aug 2004 12:32:59 -0400 Message-ID: <1E7140413C19AD4E827D63B820A24D2B0109EFFB@zrtphxm2.corp.nortel.com> From: "Kevin Boyle" To: "Tom-PT Taylor" , Carlos Rodriguez Alcala Subject: RE: [Megaco] R2 Date: Mon, 30 Aug 2004 12:32:54 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 H.248.29 will also describe some necessary packages for R2. It is slated for consent in the November timeframe. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Monday, August 30, 2004 10:09 AM To: Carlos Rodriguez Alcala Cc: megaco@ietf.org Subject: Re: [Megaco] R2 R2 is handled by the packages defined in H.248.25 and H.248.28. Carlos Rodriguez Alcala wrote: > Hi there, > > there are nor one "annex R2" ???? > only a draft ??? > Thanks > crav > > > _______________________________________________ > Megaco mailing 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 Aug 31 06:08:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03032 for ; Tue, 31 Aug 2004 06:08:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C25Wn-0007Mi-0x; Tue, 31 Aug 2004 06:06:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C25Vc-000761-01 for megaco@megatron.ietf.org; Tue, 31 Aug 2004 06:05:00 -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 GAA02873 for ; Tue, 31 Aug 2004 06:04:57 -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 1C25XX-0007Fl-PN for megaco@ietf.org; Tue, 31 Aug 2004 06:07:01 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.ccpu.com (Postfix) with ESMTP id 1D6623468CE for ; Tue, 31 Aug 2004 03:04:48 -0700 (PDT) Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (VaMailArmor-2.0.1.16) id 23448-1081F15C; Tue, 31 Aug 2004 03:04:11 -0700 Received: from Mahesh (ccinpc10.ccin.ccpu.com [172.25.0.61]) by smtp.ccpu.com (Postfix) with ESMTP id 0CDF6346890 for ; Tue, 31 Aug 2004 03:04:10 -0700 (PDT) From: "Mahesh" To: Date: Tue, 31 Aug 2004 15:34:04 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSPQdg3uh39TcgpSyuTh0llgXfdmQ== Message-Id: <20040831100410.0CDF6346890@smtp.ccpu.com> X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.38; host: smtp) X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Subject: [Megaco] setting of MGOriginatedPendingLimit and MGCOriginatedPendingLimit 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="===============2021277020==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============2021277020== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01C48F6F.F39E5BC0" This is a multi-part message in MIME format. ------=_NextPart_000_005D_01C48F6F.F39E5BC0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit HI, Could you please let me know with what message will the MGC, inform the MG , the values of MGOriginatedPendingLimit and MGCOriginatedPendingLimit . With regards Mahesh ------=_NextPart_000_005D_01C48F6F.F39E5BC0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

HI,

 

Could you please let me know with what message will = the  MGC, inform the  MG ,

the values of  MGOriginatedPendingLimit  = and MGCOriginatedPendingLimit .

 

With regards

Mahesh

 

 

 

------=_NextPart_000_005D_01C48F6F.F39E5BC0-- --===============2021277020== 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 --===============2021277020==-- From megaco-bounces@ietf.org Tue Aug 31 10:30: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 KAA21703 for ; Tue, 31 Aug 2004 10:30: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 1C29bt-00036k-3v; Tue, 31 Aug 2004 10:27:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C29Wk-0002BX-U3 for megaco@megatron.ietf.org; Tue, 31 Aug 2004 10:22:27 -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 KAA21191 for ; Tue, 31 Aug 2004 10:22:25 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C29Yh-0004ZV-CQ for megaco@ietf.org; Tue, 31 Aug 2004 10:24:30 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7VELoE14863 for ; Tue, 31 Aug 2004 10:21:50 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Aug 2004 10:21:49 -0400 Message-ID: <1E7140413C19AD4E827D63B820A24D2B01141489@zrtphxm2> From: "Kevin Boyle" To: Mahesh , megaco@ietf.org Subject: RE: [Megaco] setting of MGOriginatedPendingLimit and MGCOriginate dPendingLimit Date: Tue, 31 Aug 2004 10:20:07 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 These, like all properties, can be set with a Modify command. Kevin _____ From: Mahesh [mailto:mahesh@ccpu.com] Sent: Tuesday, August 31, 2004 3:04 AM To: megaco@ietf.org Subject: [Megaco] setting of MGOriginatedPendingLimit and MGCOriginatedPendingLimit HI, Could you please let me know with what message will the MGC, inform the MG , the values of MGOriginatedPendingLimit and MGCOriginatedPendingLimit . With regards Mahesh _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Aug 31 15:18:34 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 PAA18542 for ; Tue, 31 Aug 2004 15:18:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2E7u-00086c-Nl; Tue, 31 Aug 2004 15:17:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2E1r-0005HG-SE for megaco@megatron.ietf.org; Tue, 31 Aug 2004 15:10:54 -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 PAA17544 for ; Tue, 31 Aug 2004 15:10:50 -0400 (EDT) Received: from [200.51.236.210] (helo=mail3.telefonica.com.ar) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2E3s-0003xf-GC for megaco@ietf.org; Tue, 31 Aug 2004 15:12:58 -0400 Received: from mailhub2.telefonica.com.ar ([10.249.7.13]) by mail3 with InterScan Messaging Security Suite; Tue, 31 Aug 2004 16:05:26 -0300 Received: by mailhub2.telefonica.com.ar with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Aug 2004 16:04:25 -0300 Message-ID: <6BB2DEB822D3D111817B00805FBE5F02151825AD@mstelefonica6.telefonica.com.ar> From: Pellegrino Jose Luis To: "'Kevin Boyle'" , Tom-PT Taylor , Carlos Rodriguez Alcala Subject: RE: [Megaco] R2 Date: Tue, 31 Aug 2004 16:04:19 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Are H.248.25/28/29 available (or will be) in the IETF site, or we must = look for they in the ITU-T one? Thanks=20 Jos=E9 -----Mensaje original----- De: Kevin Boyle [mailto:kboyle@nortelnetworks.com]=20 Enviado el: Lunes, 30 de Agosto de 2004 01:33 p.m. Para: Tom-PT Taylor; Carlos Rodriguez Alcala CC: megaco@ietf.org Asunto: RE: [Megaco] R2 H.248.29 will also describe some necessary packages for R2. It is = slated for consent in the November timeframe. Kevin=20 -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH]=20 Sent: Monday, August 30, 2004 10:09 AM To: Carlos Rodriguez Alcala Cc: megaco@ietf.org Subject: Re: [Megaco] R2 R2 is handled by the packages defined in H.248.25 and H.248.28. Carlos Rodriguez Alcala wrote: > Hi there, >=20 > there are nor one "annex R2" ???? > only a draft ??? > Thanks > crav >=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 _______________________________________________ Megaco mailing 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 Aug 31 15:26:43 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 PAA19483 for ; Tue, 31 Aug 2004 15:26:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2E8Y-0008Qu-N7; Tue, 31 Aug 2004 15:17:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2E5K-0006kS-KA for megaco@megatron.ietf.org; Tue, 31 Aug 2004 15:14:26 -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 PAA17974 for ; Tue, 31 Aug 2004 15:14:25 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2E7L-00042e-Iv for megaco@ietf.org; Tue, 31 Aug 2004 15:16:32 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7VJDls17387 for ; Tue, 31 Aug 2004 15:13:47 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Aug 2004 15:13:47 -0400 Message-ID: <1E7140413C19AD4E827D63B820A24D2B01141BA8@zrtphxm2> From: "Kevin Boyle" To: Pellegrino Jose Luis , "Tom-PT Taylor" , Carlos Rodriguez Alcala Subject: RE: [Megaco] R2 Date: Tue, 31 Aug 2004 15:13:36 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 H.245.25 and H.248.28 are available on the ITU website. H.248.29 is still in process, but will be available once it has consented and has been published. I know of no plans at this time to publish the H.248 subseries documents (other than H.248.1) as IETF RFCs. Kevin -----Original Message----- From: Pellegrino Jose Luis [mailto:pellegrj@TELEFONICA.COM.AR] Sent: Tuesday, August 31, 2004 3:04 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH]; Carlos Rodriguez Alcala Cc: megaco@ietf.org Subject: RE: [Megaco] R2 Are H.248.25/28/29 available (or will be) in the IETF site, or we must look for they in the ITU-T one? Thanks José -----Mensaje original----- De: Kevin Boyle [mailto:kboyle@nortelnetworks.com] Enviado el: Lunes, 30 de Agosto de 2004 01:33 p.m. Para: Tom-PT Taylor; Carlos Rodriguez Alcala CC: megaco@ietf.org Asunto: RE: [Megaco] R2 H.248.29 will also describe some necessary packages for R2. It is slated for consent in the November timeframe. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Monday, August 30, 2004 10:09 AM To: Carlos Rodriguez Alcala Cc: megaco@ietf.org Subject: Re: [Megaco] R2 R2 is handled by the packages defined in H.248.25 and H.248.28. Carlos Rodriguez Alcala wrote: > Hi there, > > there are nor one "annex R2" ???? > only a draft ??? > Thanks > crav > > > _______________________________________________ > Megaco mailing 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 Aug 31 16:22:02 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 QAA27512 for ; Tue, 31 Aug 2004 16:22:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2EX2-0003YR-Ad; Tue, 31 Aug 2004 15:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C28vd-00071C-7J for megaco@megatron.ietf.org; Tue, 31 Aug 2004 09:44:05 -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 JAA18065 for ; Tue, 31 Aug 2004 09:44:03 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C28xZ-0003nJ-CR for megaco@ietf.org; Tue, 31 Aug 2004 09:46:08 -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 i7VDhSg0025897 for ; Tue, 31 Aug 2004 08:43:29 -0500 (CDT) Received: by ma8117exch002u.inse.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 31 Aug 2004 09:43:28 -0400 Message-ID: <4F9DBE266768DC46A1F17E875D3716410978C760@ma8117exch002u.inse.lucent.com> From: "Steinka, Bradford R (Brad)" To: megaco@ietf.org Date: Tue, 31 Aug 2004 09:43:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b X-Mailman-Approved-At: Tue, 31 Aug 2004 15:43:02 -0400 Subject: [Megaco] BCAS Glare procedures 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="===============1120812665==" 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. --===============1120812665== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48F60.7C5595B9" 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_01C48F60.7C5595B9 Content-Type: text/plain Hi The procedures in the BCAS package specify a procedure for resolving glare in a cas trunk, see section 7.5.1. The situation arises when both sides of the trunk are provisioned to be "controlling". This is not normally how CAS is deployed in the field. Customers provision one side controller and the other side as non-controlling as specified in the following GR documents. GR-317-CORE - section 3.1.4.1 GR-505 - section 4.2.3.1 And GR-506 - section 11.5, R11-35 All specification stipulate that one MUST be provisioned 'controlling' and the other 'releasing'. Shouldn't the procedure section of the BCAS package be aligned with these GR specifications? Thanks Brad Steinka ------_=_NextPart_001_01C48F60.7C5595B9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hi

 

The procedures in = the BCAS package specify a procedure for resolving glare in a cas trunk, see = section 7.5.1.  The situation arises when both sides of the trunk are = provisioned to be “controlling”.

 

This is not = normally how CAS is deployed in the field.

Customers = provision one side controller and the other side as non-controlling as specified in the = following GR documents.

 

GR-317-CORE – section 3.1.4.1

GR-505 = – section 4.2.3.1

And = GR-506 – section 11.5,  R11-35

 

All specification = stipulate that one MUST be provisioned ‘controlling’ and the other = ‘releasing’.

 

Shouldn’t = the procedure section of the BCAS package be aligned with these GR = specifications?

 

Thanks

Brad = Steinka

 

------_=_NextPart_001_01C48F60.7C5595B9-- --===============1120812665== 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 --===============1120812665==-- From megaco-bounces@ietf.org Tue Aug 31 18:43:37 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 SAA09304 for ; Tue, 31 Aug 2004 18:43:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HKg-00034m-1Z; Tue, 31 Aug 2004 18:42:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HC9-0001Pv-Aq for megaco@megatron.ietf.org; Tue, 31 Aug 2004 18:33:41 -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 SAA08834 for ; Tue, 31 Aug 2004 18:33:38 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2HEA-0001cD-73 for megaco@ietf.org; Tue, 31 Aug 2004 18:35:49 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7VMX0K17696 for ; Tue, 31 Aug 2004 18:33:00 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Aug 2004 18:33:01 -0400 Message-ID: <1E7140413C19AD4E827D63B820A24D2B01141F39@zrtphxm2> From: "Kevin Boyle" To: "Steinka, Bradford R (Brad)" , megaco@ietf.org Subject: RE: [Megaco] BCAS Glare procedures Date: Tue, 31 Aug 2004 18:32:54 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Note that Telcordia documents only cover North America. The H.248 subseries are international standards and must accommodate variants from all over the world as much as possible. Also, how CAS works is not the domain of the H.248 subseries -- H.248.25 only describes the interface for carrying the relevant information between the MGC and the MG. If the local CAS standards dictate controlling/releasing provisioning requirements then those should be adhered to, even though it is outside the scope of H.248. Kevin _____ From: Steinka, Bradford R (Brad) [mailto:bsteinka@lucent.com] Sent: Tuesday, August 31, 2004 9:43 AM To: megaco@ietf.org Subject: [Megaco] BCAS Glare procedures Hi The procedures in the BCAS package specify a procedure for resolving glare in a cas trunk, see section 7.5.1. The situation arises when both sides of the trunk are provisioned to be "controlling". This is not normally how CAS is deployed in the field. Customers provision one side controller and the other side as non-controlling as specified in the following GR documents. GR-317-CORE - section 3.1.4.1 GR-505 - section 4.2.3.1 And GR-506 - section 11.5, R11-35 All specification stipulate that one MUST be provisioned 'controlling' and the other 'releasing'. Shouldn't the procedure section of the BCAS package be aligned with these GR specifications? Thanks Brad Steinka _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
****************************************************************= ********************************************
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.


********************************************************= ***************************************************