From megaco-bounces@ietf.org Wed Jun 01 07:42:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdRcQ-0001w2-Ea; Wed, 01 Jun 2005 07:42:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdRcO-0001vB-NA for megaco@megatron.ietf.org; Wed, 01 Jun 2005 07:42: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 HAA07873 for ; Wed, 1 Jun 2005 07:42:37 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DdRwC-0006Jg-67 for megaco@ietf.org; Wed, 01 Jun 2005 08:03:09 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1117573013; Wed Jun 01 14:42:05 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Jun 2005 14:45:06 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D30C9@MAILSERVER> From: Raphael Tryster To: "'Christian Groves'" , Rajeev K R Subject: RE: [Megaco] MGProvisionalResponsetimer Date: Wed, 1 Jun 2005 14:45:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 3.9 (+++) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: megaco@ietf.org, 'Kevin Boyle' X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0237046035==" 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. --===============0237046035== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C566A7.BC784F60" 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_01C566A7.BC784F60 Content-Type: text/plain; charset="WINDOWS-1255" I am unable to access the link below. Has it moved? Can I find it somewhere else? Raphael Tryster -----Original Message----- From: Christian Groves [mailto:christian.groves@ericsson.com] Sent: Monday, January 10, 2005 4:46 AM To: Rajeev K R Cc: megaco@ietf.org; 'Kevin Boyle' Subject: Re: [Megaco] MGProvisionalResponsetimer Hello Rajeev, At the September Q.3 meeting the issues around MGProvisionalResponse timers were discussed. An IG correction was accepted. See section titled: "H.248.1 Provisional Response Timer Clarification" http://avguest@ftp3.itu.int/av-arch/avc-site/2001-2004/0408_San/AVD-2569.zip Regards, Christian ------_=_NextPart_001_01C566A7.BC784F60 Content-Type: text/html; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable RE: [Megaco] MGProvisionalResponsetimer

I am unable to access the link below.  Has it move= d?  Can I find it somewhere else?

Raphael Tryster


 -----Original Message-----
From:   Christian Groves [mailto:christian.groves@ericsson.com]
Sent:   Monday, January 10, 2005 4:46 AM
To:     Rajeev K R
Cc:     megaco@ietf.org; 'Kevin Bo= yle'
Subject:        Re:= [Megaco] MGProvisionalResponsetimer

Hello Rajeev,

At the September Q.3 meeting the issues around MGProvis= ionalResponse timers were
discussed. An IG correction was accepted.

See section titled: "H.248.1 Provisional Response = Timer Clarification"
http://avguest@ftp3.= itu.int/av-arch/avc-site/2001-2004/0408_San/AVD-2569.zip

Regards, Christian

------_=_NextPart_001_01C566A7.BC784F60-- --===============0237046035== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0237046035==-- From megaco-bounces@ietf.org Wed Jun 01 10:54:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUcE-0000Wr-7c; Wed, 01 Jun 2005 10:54:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUcC-0000Wm-Io for megaco@megatron.ietf.org; Wed, 01 Jun 2005 10:54: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 KAA23389 for ; Wed, 1 Jun 2005 10:54:38 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdUw2-0007rY-Px for megaco@ietf.org; Wed, 01 Jun 2005 11:15:11 -0400 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 Subject: RE: [Megaco] Conformance tests question Date: Wed, 1 Jun 2005 10:54:29 -0400 Message-ID: Thread-Topic: [Megaco] Conformance tests question Thread-Index: AcVi5SVIDoEdhsDIQAiGRq0nm6zb3QDSMmFg From: "Steve Cipolli" To: "Kevin Boyle" , "B Venkat S.R Swamy" , X-Spam-Score: 0.2 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 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 Two points: 1. ETSI H.248 Conformance Tests assume that any given request will generate one and only one possible response. Clearly this is not a valid approach. The original posting is a good example of this problem. There is no specification outlining exactly what kinds of errors generate errors at what level in a given response. Therefore, the test must account for all possible legal responses. 2. The H.248.1 spec says responses can not contain '$' in the Context ID as indicated by the original poster. Clearly a conformance test can not violate the standard it tests. Stating that responses should be allowed to return '$' in Context ID does not make it so. Either the Conformance Test or the standard needs to be amended. --Stephen Stephen Cipolli Product Manager RADVISION Inc. 1-201-689-6339 scipolli@radvision.com www.radvision.com > -----Original Message----- > From: megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org] On Behalf Of Kevin Boyle > Sent: Friday, May 27, 2005 1:49 PM > To: B Venkat S.R Swamy; Seraya.Miletzki@ecitele.com > Cc: megaco@ietf.org > Subject: RE: [Megaco] Conformance tests question >=20 >=20 > In most cases, the MG knows it cannot allocate a context at > the time the request is detected -- that is, once the action=20 > is parsed. If the MG detects a problem, why would it=20 > continue to parse? The error descriptor ought to be placed=20 > at the action level, so there would not be a context=20 > indicated of any kind, let alone a CHOOSE wildcard. >=20 > Remember, error detection occurs at the earliest possible > time with the error descriptor occurring at the level of=20 > detection. If the MG was not able to detect that it was=20 > unable to allocate a context until the command or descriptor=20 > level, then the error descriptor would go at the lower level. >=20 > Kevin >=20 > -----Original Message----- > From: megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org] On Behalf Of B Venkat S.R Swamy > Sent: Thursday, May 26, 2005 8:25 AM > To: Seraya.Miletzki@ecitele.com > Cc: megaco@ietf.org > Subject: Re: [Megaco] Conformance tests question >=20 >=20 >=20 >=20 >=20 >=20 > Hi >=20 > IMO it is perfectly valid to specify CHOOSE for contextID in > response to the test cases you have mentioned below. As far=20 > as the protocol text you have mentioned it applies mostly to=20 > those scenario where you a valid context Id(includes wildcard=20 > also) or Null context. Where MG has never been able to create=20 > a context why should it return any other value. >=20 > Even the ABNF and ASN grammar in Appendix does not put any > limitation on the set of values that can be used in the Reply=20 > messages. >=20 > I however do agree that the relevant text should be modified > to clarify these scenario and request authors to take this in=20 > IG or upcoming V3 document. >=20 > regards > B Venkat S.R Swamy > Senior Technical Leader > Flextronics Software Systems > Phone: +91-124-2455555 Extn 3620 > Fax: +91-124-2455345 > web: www.hssworld.com >=20 >=20 >=20 >=20 >=20 > =20 > =20 > Seraya.Miletzki@e =20 > =20 > citele.com =20 > =20 > Sent by: =20 > To=20 > megaco-bounces@ie megaco@ietf.org =20 > =20 > tf.org =20 > cc > =20 > =20 > =20 > Subject=20 > 05/26/2005 05:17 [Megaco] Conformance=20 > tests question=20 > PM =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Hello all >=20 > I was performing conformance tests for the MEGACO according > ETSI TS 101 889-2 v1.1.1 (2002-08). I have a question=20 > regarding some of the expected results appeared on this > tests: > On error tests (BI type) there are several tests that send=20 > request with ContextID set to CHOOSE ($). The expected=20 > results on the tests contain action reply with ContextID set=20 > to CHOOSE. Here is an example for this tests : >=20 > TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1 [3] > clause 7.2.1 Selection criteria: ROOT termination implemented=20 > Initial condition: any Ensure that the IUT, on receipt of a=20 > Transaction Request containing > * Action request with > o CID set to CHOOSE > o ADD Command request wi > sends a Transaction Reply containing > * Action reply with > o CID set to CHOOSE > o ADD Command reply wi > RO >=20 > The H.248.1 v1 spec mandate that transaction reply may only > contain a specific ContextID, ALL (*), or NULL (-). >=20 > Here's the relevant text from the H.248.1 v1 spec: > 8.2.2 TransactionReply > ... > The ContextID parameter must specify a value to pertain to > all Responses for the action. The ContextID may be specific,=20 > all or null. >=20 > The following 19 items are the test cases with this requirement. >=20 > 1. TP/MG/AD/BI-01 > 2. TP/MG/AC/BI-01 > 3. TP/MG/AC/BI-02 > 4. TP/MG/AC/BI-03 > 5. TP/MG/AC/BI-04 > 6. TP/MG/AV/BI-01 > 7. TP/MG/AV/BI-02 > 8. TP/MG/AV/BI-03 > 9. TP/MG/AV/BI-04 > 10. TP/MG/MD/BI-01 > 11. TP/MG/MD/BI-02 > 12. TP/MG/MD/BI-03 > 13. TP/MG/MD/BI-09 > 14. TP/MG/SU/BI-01 > 15. TP/MG/SU/BI-02 > 16. TP/MG/SU/BI-03 > 17. TP/MG/SU/BI-04 > 18. TP/MG/MV/BI-01 > 19. TP/MG/MV/BI-02 >=20 >=20 > Please help me to clear this issue. >=20 > Thanks >=20 > Seraya_______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 >=20 >=20 > *********************** FSS-Restricted *********************** > "DISCLAIMER: This message is proprietary to Hughes Software > Systems Limited > (HSS) and is intended solely for the use of the individual to=20 > whom it is addressed. It may contain privileged or=20 > confidential information and should not be circulated or used=20 > for any purpose other than for what it is intended. If you=20 > have received this message in error, please notify the=20 > originator immediately. If you are not the intended=20 > recipient, you are notified that you are strictly prohibited=20 > from using, copying, altering, or disclosing the contents of=20 > this message. HSS accepts no responsibility for loss or=20 > damage arising from the use of the information transmitted by=20 > this email including damage from virus." > "DISCLAIMER: This message is proprietary to Flextronics=20 > Software Systems Limited (FSS) and is intended solely for the=20 > use of the individual to whom it is addressed. It may contain=20 > privileged or confidential information and should not be=20 > circulated or used for any purpose other than for what it is=20 > intended. If you have received this message in error, please=20 > notify the originator immediately.=20 > If you are not the intended recipient, you are notified that=20 > you are strictly prohibited from using, copying, altering,=20 > or disclosing the contents of this message. FSS accepts no =20 > responsibility for loss or damage arising from the use of =20 > the information transmitted by this email including damage=20 > from virus." >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Jun 01 19:01:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdcD1-0001uS-Dm; Wed, 01 Jun 2005 19:01:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdcCx-0001pq-Ax for megaco@megatron.ietf.org; Wed, 01 Jun 2005 19:01: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 TAA18204 for ; Wed, 1 Jun 2005 19:01:04 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdcWl-00042w-Oj for Megaco@ietf.org; Wed, 01 Jun 2005 19:21:42 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by delivery_mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 08EC6D1A; Thu, 2 Jun 2005 01:00:50 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by outbound_mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EB1C7D17; Thu, 2 Jun 2005 01:00:49 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 01:00:49 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 01:00:49 +0200 Received: from [146.11.22.2] (EG2E500202DSEGL [146.11.22.2]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LSLSGL5T; Thu, 2 Jun 2005 09:00:46 +1000 Message-ID: <429E3E2E.3040007@ericsson.com> Date: Thu, 02 Jun 2005 09:01:02 +1000 X-Sybari-Trust: f60cd55a 3280b041 4108617c 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: troy Subject: Re: [Megaco] querying termination state References: <429CC7C3.8020203@bell-labs.com> In-Reply-To: <429CC7C3.8020203@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2005 23:00:49.0489 (UTC) FILETIME=[C0A78410:01C566FD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Hello Troy, Lucent have put in a proposal for addition to H.248.1v3 to allow scoped audits. Therefore you would be able to Audit Context=ALL, Termination=ALL, ServiceState=OSS and get a response with the matching terminations and their contexts. The functionality has been accepted but not the actual changes to the syntax and procedures. Regards, Christian troy wrote: > Hi all, > > What Audit (?) form should be used to ask > "what terminations are disabled"? > > If there's more than one, I'm most interested > in forms with compact requests and responses. > > -troy > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 02 00:14:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddh5t-0002ZY-Ue; Thu, 02 Jun 2005 00:14:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddh5q-0002ZS-Ht for megaco@megatron.ietf.org; Thu, 02 Jun 2005 00:14:08 -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 AAA08333 for ; Thu, 2 Jun 2005 00:14:03 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdhPl-0002Ly-7C for megaco@ietf.org; Thu, 02 Jun 2005 00:34:43 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IHF00LPQVVS5U@szxga01-in.huawei.com> for megaco@ietf.org; Thu, 02 Jun 2005 12:16:40 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IHF00K2SVVRJX@szxga01-in.huawei.com> for megaco@ietf.org; Thu, 02 Jun 2005 12:16:40 +0800 (CST) Received: from z14593 ([10.70.32.79]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IHF00EF4W2GBL@szxml01-in.huawei.com>; Thu, 02 Jun 2005 12:20:40 +0800 (CST) Date: Thu, 02 Jun 2005 12:12:07 +0800 From: zhao bo To: kboyle@nortelnetworks.com Message-id: <000e01c56729$3dff78c0$4f20460a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7BIT Cc: megaco@ietf.org Subject: [Megaco] A question about andisp/dwa pattern X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello Kevin: In H.248.23, the description of pattern of anidisp/dwa is: "The pattern is an abstract indication of the distinctive alerting pattern that will be applied to the line. The default is no pattern which indicates that the data transmission should not be associated with any signalling." Does this mean if no pattern parameter present, the MG should not make any ringing before sending the data block? While the description of andisp signal does say: "Therefore, this signal implies alerting, which will be appropriately applied to the CPE by the gateway, based upon the on-hook/off-hook status of the line." So it's overrided by the pattern description? Thanks and best regard Zhao Bo Huawei Technologies _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 02 03:14:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdjuJ-0006fo-Hg; Thu, 02 Jun 2005 03:14:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdjuI-0006fO-Eq for megaco@megatron.ietf.org; Thu, 02 Jun 2005 03:14:22 -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 DAA12164 for ; Thu, 2 Jun 2005 03:14:20 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdkEE-0002xx-N0 for megaco@ietf.org; Thu, 02 Jun 2005 03:35:01 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by delivery_mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DB43F3900D2 for ; Thu, 2 Jun 2005 09:14:07 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by outbound_mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B58CC4F0002 for ; Thu, 2 Jun 2005 09:14:07 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 09:14:05 +0200 Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 09:14:05 +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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Jun 2005 09:14:05 +0200 Message-ID: Thread-Topic: Re: Packages extension (question 2) Thread-Index: AcVnQqmBC5qMEk9vSb6j69xCI4Nwcw== From: "Julio Martinez-Minguito (AL/EAB)" To: X-OriginalArrivalTime: 02 Jun 2005 07:14:05.0487 (UTC) FILETIME=[A93E6BF0:01C56742] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] Re: Packages extension (question 2) 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: Thanks for your mails that had help me a lot to understand the syntax of = the extended packages. But I still have another question: Signals syntax is: dg/pt {tl =3D [d0, d1]} But is it valid dg/d1=20 being d1 a signal in 'dg'? For the events and observed events descriptor we have: Events =3D 1 { dd/std {tl =3D [d2, d3, d4]}} ObservedEvents =3D 1 { dd/std {tid =3D d2} } If the events descriptor is: Events =3D 1 { dd/* } Is it valid=20 ObservedEvents =3D 1 { dd/d2 } or should be ObservedEvents =3D 1 { dd/std {tid =3D d2} } thanks for your help, Julio And for the observed events descriptor dd/std {tl =3D [d2, d3, d4]}, tonedet/std {tl =3D [d2, d3, d4]}} and it detects f.e. "d2" stat tone: ObservedEvents =3D 1 { dd/std {tid =3D d2} }, or ObservedEvents =3D 1 { tonedet/std {tid =3D d2} } ? Please see answers below inline. At 12:23 AM 9/4/2002, Fhuval Hittay wrote: Thanks for answer, but there is one more question. "tonedet" package = has "std" event with "tl" parameter, and that parameter has only one possible = value "*". Suppose such a situation: MG received following Events descriptor Events =3D 1 { tonedet/std {tl =3D *} } and it detects "d2" start tone. Which ObservedEvents descriptor MG has = to notify ObservedEvents =3D 1 { tonedet/std {tid =3D *} } or something different? Events descriptor above would match no events as tonedet itself has no = individual events ids. The only reason * is defined in tonedet is such that it does = not have to be defined in all the packages that extents it, since the meaning of * = is exactly the same no matter what package it is defined in. So you should really use = this: Events =3D 1 { dd/std {tl =3D *} } and then on d2 start detect MG will send ObservedEvents =3D 1 { dd/std {tid =3D d2} } But there is said "Extensions to this package would add additional possible values for tone id". Does it mean that instead of = "*" we could use "dd" package's tones? Not instead, but in addition to, and only in scope of dd package (see = above). And what about "tonegen" package? In section E.3.3 is said: "No tone ids are specified in this package. Packages that extend this = package can add possible values for tone id as well as adding individual tone = signals". Does it mean, that if "dd" package extends "tonegen" package, we can = use "tonegen/pt {tl =3D [d0, d1]}" form? No, other way around, that means that dd package can use tonegen's = signals and its params, that is: "dd/pt {tl =3D [d0, d1]}" Cheers. Aleks Thanks in advance. ----------------------------- From: Aleksandr Ryabin Subject: Re: [Megaco] Packages extension >Hi, > > Usage of signal/event IDs apply only in the scope of the = package >which defines them, or packages that extends that package. >Thus you can not use d0 in tonegen, it does not know what d0 is. > >To clarify, let say there is another packages dgx which also extends >tonegen and also defines d0, like dg package, but it means something >different. >If you were to use base package to access d0 then you would get the = same >tonegen/pt {tl =3D [d0, d1]} As you can see there is no way to = distinguish >which package is being used: dg or dgx. > >The answers to your questions below are: >dg/pt {tl =3D [d0, d1]} >dd/std {tl =3D [d2, d3, d4]} >Events =3D 1 { dd/std {tl =3D [d2, d3, d4]}} >ObservedEvents =3D 1 { dd/std {tid =3D d2} } > >Cheers. > Aleks > >At 01:19 AM 9/3/2002, Fhuval Hittay wrote: >> Hello all! >>In RFC there is said that "dg" package extends "tonegen" package, and = does >it >>mean that I can use: >> dg/pt {tl =3D [d0, d1]} >>instead of: >> tonegen/pt {tl =3D [d0, d1]} ? >> >>Also "dd" package extends "tonedet" package. And instead of: >> tonedet/std {tl =3D [d2, d3, d4]} >>I can use: >> dd/std {tl =3D [d2, d3, d4]} ? >> >>Question is: What is the difference between theese two forms of = usage? >Which >>ObservedEvents descriptor MG has to return if it has following >>EventsDescriptor: >> Events =3D 1 { dd/std {tl =3D [d2, d3, d4]}, tonedet/std {tl =3D = [d2, d3, >d4]}} >>and it detects f.e. "d2" stat tone: >> ObservedEvents =3D 1 { dd/std {tid =3D d2} }, >>or >> ObservedEvents =3D 1 { tonedet/std {tid =3D d2} } ? >> >>Please, answer ASAP. Thanks in advance. >>_______________________________________________ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 02 07:12:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdncY-0002tx-Ns; Thu, 02 Jun 2005 07:12:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdncX-0002tF-Kz for megaco@megatron.ietf.org; Thu, 02 Jun 2005 07:12:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00837 for ; Thu, 2 Jun 2005 07:12:14 -0400 (EDT) Received: from [202.144.91.188] (helo=axestechnologies.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddnva-0006CP-KU for megaco@ietf.org; Thu, 02 Jun 2005 07:32:59 -0400 Received: from axestechnologies.com ([192.168.5.3]) by axestechnologies.com (8.12.10+Sun/8.9.3) with ESMTP id j52BeiVE029233 for ; Thu, 2 Jun 2005 17:10:47 +0530 (IST) Message-ID: <429EEABE.4080104@axestechnologies.com> Date: Thu, 02 Jun 2005 16:47:18 +0530 From: jijo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Megaco Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Megaco] Ephimeral Termination Name 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 All, Im working on a trunking gateway.What's the convention normally follow while deciding the ephimeral termination name.? Please let me know what's the industry standard way of doing it? In the call flow document, its mentioned as "EphA". good if you can give some suggestion or example for endpoint names.. Jijo _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 02 07:58:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdoLS-0000ZE-RP; Thu, 02 Jun 2005 07:58:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdoLR-0000Z9-3c for megaco@megatron.ietf.org; Thu, 02 Jun 2005 07:58: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 HAA06224 for ; Thu, 2 Jun 2005 07:58:38 -0400 (EDT) Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdofP-0000OG-0W for megaco@ietf.org; Thu, 02 Jun 2005 08:19:21 -0400 Received: from spark.hss.co.in (localhost [127.0.0.1]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j52BrYff023738 for ; Thu, 2 Jun 2005 17:23:36 +0530 (IST) Received: from webmail.hss.hns.com (webmail.hss.hns.com [10.203.158.17]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j52BrIGO023656; Thu, 2 Jun 2005 17:23:33 +0530 (IST) In-Reply-To: <429EEABE.4080104@axestechnologies.com> Subject: Re: [Megaco] Ephimeral Termination Name To: jijo X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "B Venkat S.R Swamy" Date: Thu, 2 Jun 2005 17:34:56 +0530 X-MIMETrack: Serialize by Router on WebMail/HSS(Release 6.5.1|January 21, 2004) at 06/02/2005 05:23:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 3.1 (+++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Megaco X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hi Although its a implementation issue, but the Ephimeral name can be as simple as RTPxxxx or EPHxxx to a more exhaustive naming schema such as "ip/group/interface/" depending on the size of the gateway and number of network interface cards available on the system. Also mulitple naming schema's can be configured on MG depending on whether the ephimeral endpoint is IP or ATM. regards B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.hssworld.com jijo To Sent by: Megaco megaco-bounces@ie cc tf.org Subject [Megaco] Ephimeral Termination Name 06/02/2005 04:47 PM Hi All, Im working on a trunking gateway.What's the convention normally follow while deciding the ephimeral termination name.? Please let me know what's the industry standard way of doing it? In the call flow document, its mentioned as "EphA". good if you can give some suggestion or example for endpoint names.. Jijo _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco *********************** FSS-Restricted *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 02 08:16:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdocX-00021E-WB; Thu, 02 Jun 2005 08:16:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdocX-000219-5A for megaco@megatron.ietf.org; Thu, 02 Jun 2005 08:16:21 -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 IAA08331 for ; Thu, 2 Jun 2005 08:16:19 -0400 (EDT) Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdowX-0001SE-AU for megaco@ietf.org; Thu, 02 Jun 2005 08:37:02 -0400 Received: from spark.hss.co.in (localhost [127.0.0.1]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j52CBZff029903 for ; Thu, 2 Jun 2005 17:41:52 +0530 (IST) Received: from webmail.hss.hns.com (webmail.hss.hns.com [10.203.158.17]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j52CBHGP029772; Thu, 2 Jun 2005 17:41:34 +0530 (IST) In-Reply-To: Subject: Re: [Megaco] Re: Packages extension (question 2) To: "Julio Martinez-Minguito (AL/EAB)" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "B Venkat S.R Swamy" Date: Thu, 2 Jun 2005 17:53:00 +0530 X-MIMETrack: Serialize by Router on WebMail/HSS(Release 6.5.1|January 21, 2004) at 06/02/2005 05:41:06 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 3.1 (+++) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 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 IMPORTANT: HUGHES SOFTWARE SYSTEMS LTD. (HSS) IS NOW FLEXTRONICS SOFTWARE SYSTEMS LTD. (FSS) Hi For the signal, both the syntax have different role. dg/pt {tl = [d0, d1]}--- MG will play d0 and d1 in sequence, whereas dg/d1 will only play d1. However if the intention is to play only d1 then the later format is more compact. For the events, dd/* , since parameters has not been specified, wildcard cannot be resolved to std, etd and ltd events and thus "ObservedEvents = 1 { dd/d2 }" is the only valid syntax.. Also note that "dd/*" alone is not a valid combination since , dd/* also resolves to dd/ce event and thus a valid eventDM parameters should always be accompanied with the request. regards B Venkat S.R Swamy Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.hssworld.com "Julio Martinez-Minguito (AL/EAB)" To inguito@ericsson. cc com> Sent by: Subject megaco-bounces@ie [Megaco] Re: Packages extension tf.org (question 2) 06/02/2005 12:44 PM Hi: Thanks for your mails that had help me a lot to understand the syntax of the extended packages. But I still have another question: Signals syntax is: dg/pt {tl = [d0, d1]} But is it valid dg/d1 being d1 a signal in 'dg'? For the events and observed events descriptor we have: Events = 1 { dd/std {tl = [d2, d3, d4]}} ObservedEvents = 1 { dd/std {tid = d2} } If the events descriptor is: Events = 1 { dd/* } Is it valid ObservedEvents = 1 { dd/d2 } or should be ObservedEvents = 1 { dd/std {tid = d2} } thanks for your help, Julio And for the observed events descriptor dd/std {tl = [d2, d3, d4]}, tonedet/std {tl = [d2, d3, d4]}} and it detects f.e. "d2" stat tone: ObservedEvents = 1 { dd/std {tid = d2} }, or ObservedEvents = 1 { tonedet/std {tid = d2} } ? Please see answers below inline. At 12:23 AM 9/4/2002, Fhuval Hittay wrote: Thanks for answer, but there is one more question. "tonedet" package has "std" event with "tl" parameter, and that parameter has only one possible value "*". Suppose such a situation: MG received following Events descriptor Events = 1 { tonedet/std {tl = *} } and it detects "d2" start tone. Which ObservedEvents descriptor MG has to notify ObservedEvents = 1 { tonedet/std {tid = *} } or something different? Events descriptor above would match no events as tonedet itself has no individual events ids. The only reason * is defined in tonedet is such that it does not have to be defined in all the packages that extents it, since the meaning of * is exactly the same no matter what package it is defined in. So you should really use this: Events = 1 { dd/std {tl = *} } and then on d2 start detect MG will send ObservedEvents = 1 { dd/std {tid = d2} } But there is said "Extensions to this package would add additional possible values for tone id". Does it mean that instead of "*" we could use "dd" package's tones? Not instead, but in addition to, and only in scope of dd package (see above). And what about "tonegen" package? In section E.3.3 is said: "No tone ids are specified in this package. Packages that extend this package can add possible values for tone id as well as adding individual tone signals". Does it mean, that if "dd" package extends "tonegen" package, we can use "tonegen/pt {tl = [d0, d1]}" form? No, other way around, that means that dd package can use tonegen's signals and its params, that is: "dd/pt {tl = [d0, d1]}" Cheers. Aleks Thanks in advance. ----------------------------- From: Aleksandr Ryabin Subject: Re: [Megaco] Packages extension >Hi, > > Usage of signal/event IDs apply only in the scope of the package >which defines them, or packages that extends that package. >Thus you can not use d0 in tonegen, it does not know what d0 is. > >To clarify, let say there is another packages dgx which also extends >tonegen and also defines d0, like dg package, but it means something >different. >If you were to use base package to access d0 then you would get the same >tonegen/pt {tl = [d0, d1]} As you can see there is no way to distinguish >which package is being used: dg or dgx. > >The answers to your questions below are: >dg/pt {tl = [d0, d1]} >dd/std {tl = [d2, d3, d4]} >Events = 1 { dd/std {tl = [d2, d3, d4]}} >ObservedEvents = 1 { dd/std {tid = d2} } > >Cheers. > Aleks > >At 01:19 AM 9/3/2002, Fhuval Hittay wrote: >> Hello all! >>In RFC there is said that "dg" package extends "tonegen" package, and does >it >>mean that I can use: >> dg/pt {tl = [d0, d1]} >>instead of: >> tonegen/pt {tl = [d0, d1]} ? >> >>Also "dd" package extends "tonedet" package. And instead of: >> tonedet/std {tl = [d2, d3, d4]} >>I can use: >> dd/std {tl = [d2, d3, d4]} ? >> >>Question is: What is the difference between theese two forms of usage? >Which >>ObservedEvents descriptor MG has to return if it has following >>EventsDescriptor: >> Events = 1 { dd/std {tl = [d2, d3, d4]}, tonedet/std {tl = [d2, d3, >d4]}} >>and it detects f.e. "d2" stat tone: >> ObservedEvents = 1 { dd/std {tid = d2} }, >>or >> ObservedEvents = 1 { tonedet/std {tid = d2} } ? >> >>Please, answer ASAP. Thanks in advance. >>_______________________________________________ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco *********************** FSS-Restricted *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 02 09:37:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdptL-0006HX-9T; Thu, 02 Jun 2005 09:37:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdptJ-0006GW-Bs for megaco@megatron.ietf.org; Thu, 02 Jun 2005 09:37: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 JAA13929 for ; Thu, 2 Jun 2005 09:37:43 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdqDK-0005XL-J9 for Megaco@ietf.org; Thu, 02 Jun 2005 09:58:27 -0400 Received: from horh1.emsr.lucent.com (h135-112-138-211.lucent.com [135.112.138.211]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j52Dbd9U008166; Thu, 2 Jun 2005 08:37:40 -0500 (CDT) Received: from beavis.ho.lucent.com (beavis.ho.lucent.com [135.112.125.152]) by horh1.emsr.lucent.com (8.12.11/8.12.11) with ESMTP id j52Dba1r010493; Thu, 2 Jun 2005 08:37:36 -0500 (CDT) Received: from [135.112.125.177] (pinky.ho.lucent.com [135.112.125.177]) by beavis.ho.lucent.com (8.11.6+Sun/8.11.6) with ESMTP id j52DbaD02502; Thu, 2 Jun 2005 09:37:36 -0400 (EDT) Message-ID: <429F0B7E.5070003@bell-labs.com> Date: Thu, 02 Jun 2005 09:37:02 -0400 From: troy User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves , Megaco@ietf.org Subject: Re: [Megaco] querying termination state References: <429CC7C3.8020203@bell-labs.com> <429E3E2E.3040007@ericsson.com> In-Reply-To: <429E3E2E.3040007@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: 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 Thanks Christian, But I'm really looking for what I can do with the protocol today. I understand that I proably can't really ask "what terminations are disabled", but must ask "what is the state of all the terminations". What is the best current request/response form for that? -troy Christian Groves wrote: > Hello Troy, > > Lucent have put in a proposal for addition to H.248.1v3 to allow scoped > audits. Therefore you would be able to Audit Context=ALL, > Termination=ALL, ServiceState=OSS and get a response with the matching > terminations and their contexts. The functionality has been accepted but > not the actual changes to the syntax and procedures. > > Regards, Christian > > troy wrote: > >> Hi all, >> >> What Audit (?) form should be used to ask >> "what terminations are disabled"? >> >> If there's more than one, I'm most interested >> in forms with compact requests and responses. >> >> -troy >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 02 17:16:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddx3N-0007SA-HN; Thu, 02 Jun 2005 17:16:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddx3L-0007Rz-53 for megaco@megatron.ietf.org; Thu, 02 Jun 2005 17:16: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 RAA01996 for ; Thu, 2 Jun 2005 17:16:32 -0400 (EDT) Received: from web61320.mail.yahoo.com ([209.73.179.74]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DdxNQ-0001ej-Bd for megaco@ietf.org; Thu, 02 Jun 2005 17:37:21 -0400 Received: (qmail 50532 invoked by uid 60001); 2 Jun 2005 21:16:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zP0DKKWC/AcCbtXk2eA20S56xPVON9PRxqP420MsCNCyTal16EBgNmm9jOScRshHjoPRXxS6smZ6ZYvCsUjgkhei/AICQC69J0B+JoFAIz5e5WcCCV1OKlHpSg67wNWIlMBGr6/ak5tvZGM6nc9hoC7UCVTGtH+HBV+1qcbOFBc= ; Message-ID: <20050602211624.50527.qmail@web61320.mail.yahoo.com> Received: from [216.223.9.2] by web61320.mail.yahoo.com via HTTP; Thu, 02 Jun 2005 14:16:24 PDT Date: Thu, 2 Jun 2005 14:16:24 -0700 (PDT) From: Frank Reno To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 8bit Subject: [Megaco] Topology Questions X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello List, 1. Does a topology association with wildcarded termination IDs apply to terminations added to the context in the future or only to those currently in the context? Transaction = 1 { Context = 1 { Topology {a/*, b/*, oneway}, Add = a/1, Add = b/1 } } Transaction = 2 { Context = 1 { Add = a/2 } } What is the media flow between a/2 and b/1? 2. Does a topology association between two terminations apply to new streams created on the terminations? Transaction = 1 { Context = 1 { Topology {t1, t2, oneway}, Add = t1 {Media {Stream = 1{...}}}, Add = t2 {Media {Stream = 1{...}}} } } Transaction = 2 { Context = 1 { Modify = t1 {Media {Stream = 2{...}}}, Modify = t2 {Media {Stream = 2{...}}} } } What is the media flow between t1 and t2 for stream 2? Is the answer different between protocol version 1 and 2? 3. What does the reply to an audit of the topology descriptor look like? I assume it's valid to include an association for every pair of terminations (or streams) but this may lead to large message. Is it valid to only describe the links that are missing? Transaction = 1 { Context = 1 { Topology {t1, t2, oneway}, Add = t1, Add = t2, Add = t3, Add = t4 } } Transaction = 2 { Context = 1 { ContextAudit {Topology} } } Is this valid? Reply = 2 { Context = 1 { Topology { t1, t2, oneway } } } Or must all links be specified like one of these: Reply = 2 { Context = 1 { Topology { t1, t2, oneway, t1, t3, bothway, t1, t4, bothway, t2, t3, bothway, t2, t4, bothway, t3, t4, bothway } } } Reply = 2 { Context = 1 { Topology { t1, t2, oneway, t3, *, bothway, t4, *, bothway } } } cheers, frank __________________________________ Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 02 17:30:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdxGj-0004Vq-G5; Thu, 02 Jun 2005 17:30:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdxGh-0004Vb-Ck for megaco@megatron.ietf.org; Thu, 02 Jun 2005 17:30: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 RAA02890 for ; Thu, 2 Jun 2005 17:30:20 -0400 (EDT) Received: from web61313.mail.yahoo.com ([209.73.179.82]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ddxal-0001yR-SQ for megaco@ietf.org; Thu, 02 Jun 2005 17:51:10 -0400 Received: (qmail 15443 invoked by uid 60001); 2 Jun 2005 21:30:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HKIyjRmtDtnu0MYiCkPutJAFhzGGEk+1mxnijDDwmgxTBZj+J80uYB1OYuIh9vk38Rhq/OWVEwh4FpzxbvozDZ6C/KIni1EJDqqyXgWARCgybzBeWLWXZJD4WApilASVlvUpyi1ahmK8AfUv99NmYyOue/pI62ecyoT9PsJj97A= ; Message-ID: <20050602213011.15441.qmail@web61313.mail.yahoo.com> Received: from [216.223.9.2] by web61313.mail.yahoo.com via HTTP; Thu, 02 Jun 2005 14:30:11 PDT Date: Thu, 2 Jun 2005 14:30:11 -0700 (PDT) From: Frank Reno To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 8bit Subject: [Megaco] SDP in H.248 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 Has there been any work to clarify SDP usage in H.248? There was a discussion on this topic in March Of 2002, but it appears nothing came out of it. Specifically: 1. The current specs say: - the use of CHOOSE is allowed in place of a single parameter value; Yet there is no definition of what a "single parameter value" is in either H.248.1 or in RFC 2327. 2. The current specs also say: - the use of alternatives is allowed in place of a single parameter value. There is no definition of what the syntax is for "alternatives" in SDP. There is a definition of "alternatives" for H.248 ABNF, but it is unclear if this syntax is intended for SDP "alternatives". Also, it is not clear whether such a syntax would conflict with the SDP syntax, since again it is unclear what a "single parameter value" is. 3. It is clear from examples and current practice that hyphens should be used to indicate irrelevant but required parameters, but H.248 is silent on the subject. It appears that not every parameter that might be set to hyphen can accept hyphen according to RFC2327 and like CHOOSE the SDP syntax actually needs modification. thanks, frank __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 02 18:17:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddy0O-0005ZY-6U; Thu, 02 Jun 2005 18:17:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddy0M-0005YA-Mv for megaco@megatron.ietf.org; Thu, 02 Jun 2005 18:17: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 SAA06884 for ; Thu, 2 Jun 2005 18:17:31 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdyKS-00030J-AW for megaco@ietf.org; Thu, 02 Jun 2005 18:38:21 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j52MHHK04723 for ; Thu, 2 Jun 2005 18:17:17 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jun 2005 18:17:03 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402402E05@zrtphxm2> From: "Kevin Boyle" To: zhao bo Date: Thu, 2 Jun 2005 18:16:49 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: megaco@ietf.org Subject: [Megaco] RE: A question about andisp/dwa pattern 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 First, let me state that whether alerting (which is not necessarily limited to ringing) occurs before, after or concurrently with the delivery of the display data to the CPE is a function to be determined by the MG based upon its own local requirements. It could even be handled differently for different terminations on the same MG. I would not assume that ringing occurs prior to data delivery. The spec is written as intended. If the MGC intends there to be alerting associated with the data delivery, then it must indicate the alerting style to the MG via the pattern parameter. The description was not intended as an override, but rather as a concrete description of behaviour in the unlikely event that the MGC did not include the pattern parameter. Kevin -----Original Message----- From: zhao bo [mailto:zbo@huawei.com] Sent: Thursday, June 02, 2005 12:12 AM To: kboyle@nortelnetworks.com Cc: megaco@ietf.org Subject: A question about andisp/dwa pattern Hello Kevin: In H.248.23, the description of pattern of anidisp/dwa is: "The pattern is an abstract indication of the distinctive alerting pattern that will be applied to the line. The default is no pattern which indicates that the data transmission should not be associated with any signalling." Does this mean if no pattern parameter present, the MG should not make any ringing before sending the data block? While the description of andisp signal does say: "Therefore, this signal implies alerting, which will be appropriately applied to the CPE by the gateway, based upon the on-hook/off-hook status of the line." So it's overrided by the pattern description? Thanks and best regard Zhao Bo Huawei Technologies _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 02 18:22:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddy5F-00082u-B8; Thu, 02 Jun 2005 18:22:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddy5D-00082j-SP for megaco@megatron.ietf.org; Thu, 02 Jun 2005 18:22: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 SAA07513 for ; Thu, 2 Jun 2005 18:22:32 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdyPK-00039q-88 for megaco@ietf.org; Thu, 02 Jun 2005 18:43:22 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j52MLcl24530 for ; Thu, 2 Jun 2005 18:21:38 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jun 2005 18:22:26 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402402E0B@zrtphxm2> From: "Kevin Boyle" To: "Julio Martinez-Minguito (AL/EAB)" , megaco@ietf.org Subject: RE: [Megaco] Re: Packages extension (question 2) Date: Thu, 2 Jun 2005 18:22:19 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: 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 will note that the event 'dd/*' actually has problems that make it difficult, if not impossible, to use. In fact, any package with an event that requires a parameter will have problems with this syntax. Remember that dd/* means "all events in the dd package". This include the dd/ce event. This event requires a DigitMap descriptor or name as a parameter of the event. Because there is no way to indicate parameters that are unique to a single event amongst a wildcarded group like this, the specification of the dd/ce violates its definition. dd/* ought to be NACKed by a receiving MG as not containing required parameters. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Julio Martinez-Minguito (AL/EAB) Sent: Thursday, June 02, 2005 3:14 AM To: megaco@ietf.org Subject: [Megaco] Re: Packages extension (question 2) Hi: Thanks for your mails that had help me a lot to understand the syntax of the extended packages. But I still have another question: Signals syntax is: dg/pt {tl = [d0, d1]} But is it valid dg/d1 being d1 a signal in 'dg'? For the events and observed events descriptor we have: Events = 1 { dd/std {tl = [d2, d3, d4]}} ObservedEvents = 1 { dd/std {tid = d2} } If the events descriptor is: Events = 1 { dd/* } Is it valid ObservedEvents = 1 { dd/d2 } or should be ObservedEvents = 1 { dd/std {tid = d2} } thanks for your help, Julio And for the observed events descriptor dd/std {tl = [d2, d3, d4]}, tonedet/std {tl = [d2, d3, d4]}} and it detects f.e. "d2" stat tone: ObservedEvents = 1 { dd/std {tid = d2} }, or ObservedEvents = 1 { tonedet/std {tid = d2} } ? Please see answers below inline. At 12:23 AM 9/4/2002, Fhuval Hittay wrote: Thanks for answer, but there is one more question. "tonedet" package has "std" event with "tl" parameter, and that parameter has only one possible value "*". Suppose such a situation: MG received following Events descriptor Events = 1 { tonedet/std {tl = *} } and it detects "d2" start tone. Which ObservedEvents descriptor MG has to notify ObservedEvents = 1 { tonedet/std {tid = *} } or something different? Events descriptor above would match no events as tonedet itself has no individual events ids. The only reason * is defined in tonedet is such that it does not have to be defined in all the packages that extents it, since the meaning of * is exactly the same no matter what package it is defined in. So you should really use this: Events = 1 { dd/std {tl = *} } and then on d2 start detect MG will send ObservedEvents = 1 { dd/std {tid = d2} } But there is said "Extensions to this package would add additional possible values for tone id". Does it mean that instead of "*" we could use "dd" package's tones? Not instead, but in addition to, and only in scope of dd package (see above). And what about "tonegen" package? In section E.3.3 is said: "No tone ids are specified in this package. Packages that extend this package can add possible values for tone id as well as adding individual tone signals". Does it mean, that if "dd" package extends "tonegen" package, we can use "tonegen/pt {tl = [d0, d1]}" form? No, other way around, that means that dd package can use tonegen's signals and its params, that is: "dd/pt {tl = [d0, d1]}" Cheers. Aleks Thanks in advance. ----------------------------- From: Aleksandr Ryabin Subject: Re: [Megaco] Packages extension >Hi, > > Usage of signal/event IDs apply only in the scope of the package >which defines them, or packages that extends that package. >Thus you can not use d0 in tonegen, it does not know what d0 is. > >To clarify, let say there is another packages dgx which also extends >tonegen and also defines d0, like dg package, but it means something >different. >If you were to use base package to access d0 then you would get the same >tonegen/pt {tl = [d0, d1]} As you can see there is no way to distinguish >which package is being used: dg or dgx. > >The answers to your questions below are: >dg/pt {tl = [d0, d1]} >dd/std {tl = [d2, d3, d4]} >Events = 1 { dd/std {tl = [d2, d3, d4]}} >ObservedEvents = 1 { dd/std {tid = d2} } > >Cheers. > Aleks > >At 01:19 AM 9/3/2002, Fhuval Hittay wrote: >> Hello all! >>In RFC there is said that "dg" package extends "tonegen" package, and does >it >>mean that I can use: >> dg/pt {tl = [d0, d1]} >>instead of: >> tonegen/pt {tl = [d0, d1]} ? >> >>Also "dd" package extends "tonedet" package. And instead of: >> tonedet/std {tl = [d2, d3, d4]} >>I can use: >> dd/std {tl = [d2, d3, d4]} ? >> >>Question is: What is the difference between theese two forms of usage? >Which >>ObservedEvents descriptor MG has to return if it has following >>EventsDescriptor: >> Events = 1 { dd/std {tl = [d2, d3, d4]}, tonedet/std {tl = [d2, d3, >d4]}} >>and it detects f.e. "d2" stat tone: >> ObservedEvents = 1 { dd/std {tid = d2} }, >>or >> ObservedEvents = 1 { tonedet/std {tid = d2} } ? >> >>Please, answer ASAP. Thanks in advance. >>_______________________________________________ _______________________________________________ Megaco mailing 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 Jun 02 18:24:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddy6p-0000WM-LV; Thu, 02 Jun 2005 18:24:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddy6o-0000Sz-3i for megaco@megatron.ietf.org; Thu, 02 Jun 2005 18:24:14 -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 SAA07721 for ; Thu, 2 Jun 2005 18:24:11 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdyQv-0003Cw-0M for megaco@ietf.org; Thu, 02 Jun 2005 18:45:01 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j52MNGl24610 for ; Thu, 2 Jun 2005 18:23:16 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jun 2005 18:24:03 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402402E0D@zrtphxm2> From: "Kevin Boyle" To: jijo , Megaco Subject: RE: [Megaco] Ephimeral Termination Name Date: Thu, 2 Jun 2005 18:23:53 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 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 There is no industry-standard naming convention for ephemerals, and MGs are free to name ephemerals whatever they want within the syntax boundaries. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of jijo Sent: Thursday, June 02, 2005 7:17 AM To: Megaco Subject: [Megaco] Ephimeral Termination Name Hi All, Im working on a trunking gateway.What's the convention normally follow while deciding the ephimeral termination name.? Please let me know what's the industry standard way of doing it? In the call flow document, its mentioned as "EphA". good if you can give some suggestion or example for endpoint names.. Jijo _______________________________________________ Megaco mailing 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 Jun 02 18:30:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdyCw-0003ia-Tx; Thu, 02 Jun 2005 18:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdyCu-0003gY-Li for megaco@megatron.ietf.org; Thu, 02 Jun 2005 18:30: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 SAA08114 for ; Thu, 2 Jun 2005 18:30:29 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdyX1-0003Ly-Hi for Megaco@ietf.org; Thu, 02 Jun 2005 18:51:19 -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 j52MUG508666; Thu, 2 Jun 2005 18:30:17 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jun 2005 18:30:18 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402402E14@zrtphxm2> From: "Kevin Boyle" To: troy , Christian Groves , Megaco@ietf.org Subject: RE: [Megaco] querying termination state Date: Thu, 2 Jun 2005 18:30:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: 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="===============0814061580==" 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. --===============0814061580== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C567C2.A451489B" 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_01C567C2.A451489B Content-Type: text/plain How about: !/2 [12.34.56.78]:2944 T=12{C=*{W-O-AV=*{AT{M{TS{SI}}}}},C=-{W-AV=*{AT{M{TS{SI}}}}}} This would get you wildcarded lists of terminations that are IS, OS and TE. This is about as compact as I can make it, and the W- will ensure that the response is as small as possible, though the answer might still be pretty large. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of troy Sent: Thursday, June 02, 2005 9:37 AM To: Christian Groves; Megaco@ietf.org Subject: Re: [Megaco] querying termination state Thanks Christian, But I'm really looking for what I can do with the protocol today. I understand that I proably can't really ask "what terminations are disabled", but must ask "what is the state of all the terminations". What is the best current request/response form for that? -troy Christian Groves wrote: > Hello Troy, > > Lucent have put in a proposal for addition to H.248.1v3 to allow > scoped audits. Therefore you would be able to Audit Context=ALL, > Termination=ALL, ServiceState=OSS and get a response with the matching > terminations and their contexts. The functionality has been accepted > but not the actual changes to the syntax and procedures. > > Regards, Christian > > troy wrote: > >> Hi all, >> >> What Audit (?) form should be used to ask "what terminations are >> disabled"? >> >> If there's more than one, I'm most interested in forms with compact >> requests and responses. >> >> -troy >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C567C2.A451489B Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] querying termination state

How about:

!/2 [12.34.56.78]:2944 = T=3D12{C=3D*{W-O-AV=3D*{AT{M{TS{SI}}}}},C=3D-{W-AV=3D*{AT{M{TS{SI}}}}}}<= /FONT>

This would get you wildcarded lists of terminations = that are IS, OS and TE.  This is about as compact as I can make = it, and the W- will ensure that the response is as small as possible, = though the answer might still be pretty large.

Kevin

-----Original Message-----
From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of troy
Sent: Thursday, June 02, 2005 9:37 AM
To: Christian Groves; Megaco@ietf.org
Subject: Re: [Megaco] querying termination = state

Thanks Christian,

But I'm really looking for what I can do with the = protocol today.

I understand that I proably can't really ask = "what terminations are disabled", but must ask "what is = the state of all the terminations".

What is the best current request/response form for = that?

-troy


Christian Groves wrote:
> Hello Troy,
>
> Lucent have put in a proposal for addition to = H.248.1v3 to allow
> scoped audits. Therefore you would be able to = Audit Context=3DALL,
> Termination=3DALL, ServiceState=3DOSS and get a = response with the matching
> terminations and their contexts. The = functionality has been accepted
> but not the actual changes to the syntax and = procedures.
>
> Regards, Christian
>
> troy wrote:
>
>> Hi all,
>>
>> What Audit (?) form should be used to ask = "what terminations are
>> disabled"?
>>
>> If there's more than one, I'm most = interested in forms with compact
>> requests and responses.
>>
>> -troy
>>
>> = _______________________________________________
>> Megaco mailing list
>> Megaco@ietf.org
>> https://www1.ietf.org/mailman/listinfo/megaco
>>


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

------_=_NextPart_001_01C567C2.A451489B-- --===============0814061580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0814061580==-- From megaco-bounces@ietf.org Thu Jun 02 18:48:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdyUJ-0004kJ-3C; Thu, 02 Jun 2005 18:48:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdyUG-0004kD-Re for megaco@megatron.ietf.org; Thu, 02 Jun 2005 18:48: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 SAA09052 for ; Thu, 2 Jun 2005 18:48:25 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdyoN-0003hR-GY for megaco@ietf.org; Thu, 02 Jun 2005 19:09:15 -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 j52MmG510162 for ; Thu, 2 Jun 2005 18:48:17 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jun 2005 18:48:18 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402402E2A@zrtphxm2> From: "Kevin Boyle" To: Frank Reno , megaco@ietf.org Subject: RE: [Megaco] Topology Questions Date: Thu, 2 Jun 2005 18:48:09 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: 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 1. Only those currently in the context. In your example, flow is bothway between a/2 and b/1. 2. Only to existing streams. In your example, flow on stream 2 is bothway. The answer is the same in all version of the protocol. 3. The correct response is the one that lists all the associations, though I can see the utility of the one immediately below that which uses wildcards to reduce the message size. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Frank Reno Sent: Thursday, June 02, 2005 5:16 PM To: megaco@ietf.org Subject: [Megaco] Topology Questions Hello List, 1. Does a topology association with wildcarded termination IDs apply to terminations added to the context in the future or only to those currently in the context? Transaction = 1 { Context = 1 { Topology {a/*, b/*, oneway}, Add = a/1, Add = b/1 } } Transaction = 2 { Context = 1 { Add = a/2 } } What is the media flow between a/2 and b/1? 2. Does a topology association between two terminations apply to new streams created on the terminations? Transaction = 1 { Context = 1 { Topology {t1, t2, oneway}, Add = t1 {Media {Stream = 1{...}}}, Add = t2 {Media {Stream = 1{...}}} } } Transaction = 2 { Context = 1 { Modify = t1 {Media {Stream = 2{...}}}, Modify = t2 {Media {Stream = 2{...}}} } } What is the media flow between t1 and t2 for stream 2? Is the answer different between protocol version 1 and 2? 3. What does the reply to an audit of the topology descriptor look like? I assume it's valid to include an association for every pair of terminations (or streams) but this may lead to large message. Is it valid to only describe the links that are missing? Transaction = 1 { Context = 1 { Topology {t1, t2, oneway}, Add = t1, Add = t2, Add = t3, Add = t4 } } Transaction = 2 { Context = 1 { ContextAudit {Topology} } } Is this valid? Reply = 2 { Context = 1 { Topology { t1, t2, oneway } } } Or must all links be specified like one of these: Reply = 2 { Context = 1 { Topology { t1, t2, oneway, t1, t3, bothway, t1, t4, bothway, t2, t3, bothway, t2, t4, bothway, t3, t4, bothway } } } Reply = 2 { Context = 1 { Topology { t1, t2, oneway, t3, *, bothway, t4, *, bothway } } } cheers, frank __________________________________ Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 02 22:01:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De1Un-0006pv-NO; Thu, 02 Jun 2005 22:01:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De1Un-0006pq-50 for megaco@megatron.ietf.org; Thu, 02 Jun 2005 22:01: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 WAA19472 for ; Thu, 2 Jun 2005 22:01:10 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1De1ou-0007Ce-K7 for megaco@ietf.org; Thu, 02 Jun 2005 22:22:02 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by delivery_mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 27AA0F12; Fri, 3 Jun 2005 04:00:58 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by outbound_mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0EC39F09; Fri, 3 Jun 2005 04:00:58 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 04:00:57 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 04:00:56 +0200 Received: from [146.11.22.49] (EG2E500202DSEGL [146.11.22.49]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LSLSHGL1; Fri, 3 Jun 2005 12:00:53 +1000 Message-ID: <429FB300.9090703@ericsson.com> Date: Fri, 03 Jun 2005 11:31:44 +1000 X-Sybari-Trust: de4192ca 3280b041 518b7f4e 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: jijo Subject: Re: [Megaco] Ephimeral Termination Name References: <34B3EAA5B3066A42914D28C5ECF5FEA402402E0D@zrtphxm2> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA402402E0D@zrtphxm2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2005 02:00:56.0551 (UTC) FILETIME=[14940F70:01C567E0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Megaco X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello Jijo, As Kevin has indicated there are no industry wide naming convention however certain standards bodies have defined profiles which contain recommendations for termination naming conventions. For example in 3GPP TS29.232 it recommends a naming structure. Regards, Christian Kevin Boyle wrote: > There is no industry-standard naming convention for ephemerals, and MGs > are > free to name ephemerals whatever they want within the syntax boundaries. > > Kevin > > -----Original Message----- > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf > Of > jijo > Sent: Thursday, June 02, 2005 7:17 AM > To: Megaco > Subject: [Megaco] Ephimeral Termination Name > > Hi All, > > Im working on a trunking gateway.What's the convention normally follow > while deciding the ephimeral termination name.? Please let me know > what's > the industry standard way of doing it? > In the call flow document, its mentioned as "EphA". > good if you can give some suggestion or example for endpoint names.. > > Jijo > > > _______________________________________________ > Megaco mailing 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 Fri Jun 03 08:59:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBlm-00036i-8u; Fri, 03 Jun 2005 08:59:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBlj-00036Y-V9 for megaco@megatron.ietf.org; Fri, 03 Jun 2005 08:59:24 -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 IAA24383 for ; Fri, 3 Jun 2005 08:59:22 -0400 (EDT) Received: from smtpoutuk01.marconi.com ([128.87.251.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeC5x-0003Ns-7E for megaco@ietf.org; Fri, 03 Jun 2005 09:20:18 -0400 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk01.marconi.com (8.12.11/8.12.11) with ESMTP id j53Cx57R019581; Fri, 3 Jun 2005 13:59:06 +0100 (envelope-from Stephen.Mell@marconi.com) To: kboyle@nortel.com Subject: [Megaco] andisp/dwa and Hook State Change Race MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Stephen Mell" Date: Fri, 3 Jun 2005 13:58:53 +0100 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 03/06/2005 13:59:08, Serialize complete at 03/06/2005 13:59:08 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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="===============0735031982==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multipart message in MIME format. --===============0735031982== Content-Type: multipart/alternative; boundary="=_alternative 004753B680257015_=" This is a multipart message in MIME format. --=_alternative 004753B680257015_= Content-Type: text/plain; charset="us-ascii" Hello Kevin, We have experienced a situation which highlights a slight drawback with the current definition of andisp/dwa in H248.23, and thought it might be worth pointing it out now, should an "xandisp" ever materialise. With most signals that my MG needs to apply, the nature of the signal implies whether or not it is sensible or not to apply that signal in the face of a given hook state. This is good as it helps greatly to mitigate the effect of network crossover situations. For example I can choose to fail ringing if the line is now off-hook and send the required Notify to indicate failure if g/sc is armed. andisp/dwa is constructed in such an economical way that that the on and off hook signalling messages are syntactically the same, but are interpreted differently at the Gateway, dependant on the actual Hook state - However the MGC's anticipated hook state when it requested the signal is not conveyed to the Gateway. When there is a crossover between an OFF/ON-HOOK notification from the MG and a anddisp/dwa Signal from the MGC, the MG may end up inadvertantly applying inappropraite signalling to the line. Where there is packet loss this Crossover window is naturally opened further. Another optional signal parameter, identifying the MGC's anticipated hook state, which the MG is required to match before attempting to apply the signal, would help to shut this window. Regards, Steve --=_alternative 004753B680257015_= Content-Type: text/html; charset="us-ascii"
Hello Kevin,

We have experienced a situation which highlights a slight drawback with the current definition of andisp/dwa in H248.23, and thought it might be worth pointing it out now, should an "xandisp" ever materialise.

With most signals that my MG needs to apply, the nature of the signal implies whether or not it is sensible or not to apply that signal in the face of a given hook state. This is good as it helps greatly to mitigate the effect of network crossover situations. For example I can choose to fail ringing if the line is now off-hook and send the required Notify to indicate failure if g/sc is armed.

andisp/dwa is constructed in such an economical way that that the on and off hook signalling messages are syntactically the same, but are interpreted differently at the Gateway, dependant on the actual Hook state - However the MGC's anticipated hook state when it requested the signal is not conveyed to the Gateway.

When there is a crossover between an OFF/ON-HOOK notification from the MG and a anddisp/dwa Signal from the MGC, the MG may end up inadvertantly applying inappropraite signalling to the line. Where there is packet loss this Crossover window is naturally opened further.

Another optional signal parameter, identifying the MGC's anticipated hook state, which the MG is required to match before attempting to apply the signal, would help to shut this window.


Regards,

Steve --=_alternative 004753B680257015_=-- --===============0735031982== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0735031982==-- From megaco-bounces@ietf.org Fri Jun 03 11:17:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeDvl-0004MH-K7; Fri, 03 Jun 2005 11:17:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeDvk-0004MC-4W for megaco@megatron.ietf.org; Fri, 03 Jun 2005 11:17: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 LAA07001 for ; Fri, 3 Jun 2005 11:17:50 -0400 (EDT) Received: from web61316.mail.yahoo.com ([209.73.179.70]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DeEFy-0006fX-Ua for megaco@ietf.org; Fri, 03 Jun 2005 11:38:48 -0400 Received: (qmail 33070 invoked by uid 60001); 3 Jun 2005 15:17:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=04izDrkAnyrRcKrQwGY0ja4iEXrIBSyUBPpHLLqrRWuI/m/GOz6B2nwJSNQJCcvRYUZ938UrdvZItloQIZaE4tQFw2gNXGLPudrZbfIkSJ7vKXPGheGsZqNSfbNRj+nrROUbVG8uo6YMTW9TWPZsZ/OWAa6FAvG7bJMzk/xLT2g= ; Message-ID: <20050603151742.33068.qmail@web61316.mail.yahoo.com> Received: from [216.223.9.23] by web61316.mail.yahoo.com via HTTP; Fri, 03 Jun 2005 08:17:42 PDT Date: Fri, 3 Jun 2005 08:17:42 -0700 (PDT) From: Frank Reno Subject: RE: [Megaco] Topology Questions To: megaco@ietf.org In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA402402E2A@zrtphxm2> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 8bit 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 Thanks for the reply, Kevin. 2. Your rule seems to make good sense for version 2. Does this mean, however, that a version 1 MG should support per-stream topology even though the MGC cannot control it directly? For my example, I'm assuming that you mean that the topology regarding stream 1 is unchanged by the addition of stream 2, regardless of protocol version. This would leave stream 1 oneway and stream 2 bothways. A version 1 MG would have no way to describe this in a topology audit. Thanks --- Kevin Boyle wrote: > 1. Only those currently in the context. In your > example, flow is bothway > between a/2 and b/1. > 2. Only to existing streams. In your example, flow > on stream 2 is bothway. > The answer is the same in all version of the > protocol. > 3. The correct response is the one that lists all > the associations, though I > can see the utility of the one immediately below > that which uses wildcards > to reduce the message size. > > Kevin > > -----Original Message----- > From: megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org] On Behalf Of > Frank Reno > Sent: Thursday, June 02, 2005 5:16 PM > To: megaco@ietf.org > Subject: [Megaco] Topology Questions > > Hello List, > > 1. Does a topology association with wildcarded > termination IDs apply to > terminations added to the context in the future or > only to those currently > in the context? > > Transaction = 1 > { > Context = 1 > { > Topology {a/*, b/*, oneway}, > Add = a/1, Add = b/1 > } > } > Transaction = 2 > { > Context = 1 > { > Add = a/2 > } > } > > What is the media flow between a/2 and b/1? > > 2. Does a topology association between two > terminations apply to new streams > created on the terminations? > > Transaction = 1 > { > Context = 1 > { > Topology {t1, t2, oneway}, > Add = t1 {Media {Stream = 1{...}}}, > Add = t2 {Media {Stream = 1{...}}} > } > } > Transaction = 2 > { > Context = 1 > { > Modify = t1 {Media {Stream = 2{...}}}, > Modify = t2 {Media {Stream = 2{...}}} > } > } > > What is the media flow between t1 and t2 for stream > 2? > Is the answer different between protocol version 1 > and 2? > > > 3. What does the reply to an audit of the topology > descriptor look like? I > assume it's valid to include an association for > every pair of terminations > (or > streams) but this may lead to large message. Is it > valid to only describe > the links that are missing? > > > Transaction = 1 > { > Context = 1 > { > Topology {t1, t2, oneway}, > Add = t1, Add = t2, Add = t3, Add = t4 > } > } > Transaction = 2 > { > Context = 1 > { > ContextAudit {Topology} > } > } > > > Is this valid? > > Reply = 2 > { > Context = 1 > { > Topology { > t1, t2, oneway > } > } > } > > Or must all links be specified like one of these: > > > Reply = 2 > { > Context = 1 > { > Topology { > t1, t2, oneway, > t1, t3, bothway, > t1, t4, bothway, > t2, t3, bothway, > t2, t4, bothway, > t3, t4, bothway > } > } > } > > Reply = 2 > { > Context = 1 > { > Topology { > t1, t2, oneway, > t3, *, bothway, > t4, *, bothway > } > } > } > > > cheers, > frank > > > > __________________________________ > Discover Yahoo! > Use Yahoo! to plan a weekend, have fun online and > more. Check it out! > http://discover.yahoo.com/ > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 07 11:47:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfgIW-0006IX-5k; Tue, 07 Jun 2005 11:47:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfgIU-0006IM-0y for megaco@megatron.ietf.org; Tue, 07 Jun 2005 11:47:22 -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 LAA04396 for ; Tue, 7 Jun 2005 11:47:19 -0400 (EDT) Received: from smtp-out.hotpop.com ([38.113.3.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfgdT-00067q-K4 for megaco@ietf.org; Tue, 07 Jun 2005 12:09:09 -0400 Received: from bonbon.net (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id 4257612676F7 for ; Tue, 7 Jun 2005 15:47:04 +0000 (UTC) Received: from ABalyan32544 (unknown [203.196.196.114]) by smtp-1.hotpop.com (Postfix) with ESMTP id 428141A0224; Tue, 7 Jun 2005 14:51:56 +0000 (UTC) Message-ID: <002101c56b70$7adadc80$350019ac@ABalyan32544> From: "Ashish Kumar" To: Date: Tue, 7 Jun 2005 20:21:56 +0530 Organization: Continuous Computing MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-HotPOP: ----------------------------------------------- Sent By HotPOP.com FREE Email Get your FREE POP email at www.HotPOP.com ----------------------------------------------- X-Spam-Score: 0.2 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: uday@ccpu.com Subject: [Megaco] Handling failure of embedded events or signals 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="===============0481206646==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0481206646== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C56B9E.8CC2D230" This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C56B9E.8CC2D230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I hope this is the right forum for this question. I am trying to understand the possible error handling cases for the = scenario when application of an embedded event or signal fails. Following is what the specs says { In the case of an embedded EventsDescriptor being activated, the MG = continues event processing based on the newly activated EventsDescriptor. NOTE 1 ? For purposes of EventBuffer handling, activation of an embedded = EventsDescriptor is equivalent to receipt of a new EventsDescriptor. } Existing active events descriptor will be overwritten by the embedded = events descriptor because of this. Is there a way to report the failure to the MGC, or should there be a = rollback to events descriptor that was active before reporint of the = event. Considering following scenario. An active events descriptor has one of the event as "Off Hook". On reporting "Off Hook" event, the embedded events descriptor which has = "On Hook" in the event list gets activated. Now if application of "On Hook" fails, the termination will be in an = inconsistent state untill a new EventsDesriptor is received from MGC. Is there a way to get out of this. Regards Ashish ------=_NextPart_000_001E_01C56B9E.8CC2D230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I hope this is the right forum for this = question.
 
I am trying to understand the possible = error=20 handling cases for the scenario when=20 application of an embedded event or signal fails.
Following is what the specs = says
 
{
In the=20 case of an embedded EventsDescriptor being activated, the MG continues = event=20 processing
based=20 on the newly activated EventsDescriptor.
NOTE 1=20 − For purposes of EventBuffer = handling, activation=20 of an embedded EventsDescriptor is equivalent
to=20 receipt of a new EventsDescriptor.
}
 
Existing active events descriptor will be overwritten by = the=20 embedded events descriptor because of this.
Is=20 there a way to report the failure to the MGC, or should there be a = rollback to=20 events descriptor that was active before reporint of the = event.
 
 
Considering following scenario.
An=20 active events descriptor has one of the event as "Off = Hook".
On=20 reporting "Off Hook" event, the embedded events descriptor = which has=20 "On Hook" in the event list gets activated.
Now if=20 application of "On Hook" fails, the termination will be in an = inconsistent state=20 untill a new EventsDesriptor is received from MGC.
 
Is=20 there a way to get out of this.
 
Regards
Ashish
------=_NextPart_000_001E_01C56B9E.8CC2D230-- --===============0481206646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0481206646==-- From megaco-bounces@ietf.org Tue Jun 07 15:06:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjPG-0008Ij-F4; Tue, 07 Jun 2005 15:06:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjPE-0008Ie-I5 for megaco@megatron.ietf.org; Tue, 07 Jun 2005 15:06: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 PAA22629 for ; Tue, 7 Jun 2005 15:06:30 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfjkJ-0002Qw-Bt for megaco@ietf.org; Tue, 07 Jun 2005 15:28:20 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j57J5JN11965 for ; Tue, 7 Jun 2005 15:05:19 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jun 2005 15:06:10 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402579843@zrtphxm2> From: "Kevin Boyle" To: Ashish Kumar , megaco@ietf.org Subject: RE: [Megaco] Handling failure of embedded events or signals Date: Tue, 7 Jun 2005 15:05:56 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: uday@ccpu.com 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 If detection of onhook fails, you have bigger problems than the failure of the event to be detected -- like the inability to hang up! The MG can reject the command that includes the embedded Events Descriptor at the time of receipt. There is no way to send an autonomous error code. The only way to report the problem once the command was accepted is to send a ServiceChange Command for the termination. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Ashish Kumar Sent: Tuesday, June 07, 2005 10:52 AM To: megaco@ietf.org Cc: uday@ccpu.com Subject: [Megaco] Handling failure of embedded events or signals Hi, I hope this is the right forum for this question. I am trying to understand the possible error handling cases for the scenario when application of an embedded event or signal fails. Following is what the specs says { In the case of an embedded EventsDescriptor being activated, the MG continues event processing based on the newly activated EventsDescriptor. NOTE 1 − For purposes of EventBuffer handling, activation of an embedded EventsDescriptor is equivalent to receipt of a new EventsDescriptor. } Existing active events descriptor will be overwritten by the embedded events descriptor because of this. Is there a way to report the failure to the MGC, or should there be a rollback to events descriptor that was active before reporint of the event. Considering following scenario. An active events descriptor has one of the event as "Off Hook". On reporting "Off Hook" event, the embedded events descriptor which has "On Hook" in the event list gets activated. Now if application of "On Hook" fails, the termination will be in an inconsistent state untill a new EventsDesriptor is received from MGC. Is there a way to get out of this. Regards Ashish _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 07 16:16:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfkVL-00084Q-VG; Tue, 07 Jun 2005 16:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfkVK-000846-8E for megaco@megatron.ietf.org; Tue, 07 Jun 2005 16:16: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 QAA03195 for ; Tue, 7 Jun 2005 16:16:52 -0400 (EDT) Received: from web61312.mail.yahoo.com ([209.73.179.81]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfkqP-0005X7-U7 for megaco@ietf.org; Tue, 07 Jun 2005 16:38:43 -0400 Received: (qmail 4098 invoked by uid 60001); 7 Jun 2005 20:16:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=luOFXhr3Z9CMqQH4GOIoc72+JdZZCTYcvdHcBOt6OMQvgtlPwAKwiBOFzRb8j+o4+RFd0EAHHEo65vUQUE/EObM7RjF9boHoT6E2hD6/sLdee1wQOI7jqqIdFyunyvlRPr8tTx0BowOp6ZwgKqMUHlX1ESzqFLUrBUga6Z2lbOw= ; Message-ID: <20050607201641.4096.qmail@web61312.mail.yahoo.com> Received: from [216.223.9.2] by web61312.mail.yahoo.com via HTTP; Tue, 07 Jun 2005 13:16:41 PDT Date: Tue, 7 Jun 2005 13:16:41 -0700 (PDT) From: Frank Reno To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 8bit Subject: [Megaco] Repeated Descriptors 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 Section 7.2.6 states that a given descriptor may be repeated in an AuditCapabilities reply. Can other command replies repeat descriptors? For example: Transaction = 1 { Context = 1 { Modify=term1 { Media{TS{a/b = 1}} }, Modify=term1 { Audit{Media}, Media{TS{a/b = {2,3}}} } } } Can the second command reply contain two media descriptors? Since descriptors are to be processed in order, the media descriptor returned should contain the media properties before they were modified. You would need a second media descriptor to show the choice for the overspecified parameter. Thanks, Frank __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Jun 08 05:20:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfwk4-0007om-FF; Wed, 08 Jun 2005 05:20:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfwk2-0007oh-QE for megaco@megatron.ietf.org; Wed, 08 Jun 2005 05:20: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 FAA09740 for ; Wed, 8 Jun 2005 05:20:52 -0400 (EDT) Received: from [62.90.58.229] (helo=tparelay.telradnetworks.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfx5F-0006tu-Dh for megaco@ietf.org; Wed, 08 Jun 2005 05:42:51 -0400 Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j589H0ST010479 for ; Wed, 8 Jun 2005 12:17:00 +0300 (IDT) Received: from tpa-mail1.Telrad.co.il ([141.226.76.57]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j589H0ZR010476 for ; Wed, 8 Jun 2005 12:17:00 +0300 (IDT) Received: by tpa-mail1.telrad.co.il with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Jun 2005 12:21:59 +0300 Message-ID: From: Tamar Nemet To: "'megaco@ietf.org'" Date: Wed, 8 Jun 2005 12:21:56 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Megaco] Virtual Media Gateways and amount of Termination IDs 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="===============1415206790==" 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. --===============1415206790== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56C0A.D2924EE6" 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_01C56C0A.D2924EE6 Content-Type: text/plain; charset="windows-1255" Hello, I have some questions regarding Virtual media gateway: 1. I have one physical media gateway (with one IP address). We can define up to 4400 Termination IDs on this media gateway. Does we have to devide the termination IDs to some virtual media gateways or we can work with no virtual media gateway ? 2. Does SoftSwitches uses the Virtual Media Gatway object? for what ? Thanks, Tamar ------_=_NextPart_001_01C56C0A.D2924EE6 Content-Type: text/html; charset="windows-1255"
Hello,
 
I have some questions regarding Virtual media gateway:
 
1. I have one physical media gateway (with one IP address). We can define up to 4400 Termination IDs on this media gateway.
    Does we have to devide the termination IDs to some virtual media gateways or we can work with no virtual media gateway ?
 
2. Does SoftSwitches uses the Virtual Media Gatway object? for what ?
 
Thanks,
Tamar
 
------_=_NextPart_001_01C56C0A.D2924EE6-- --===============1415206790== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1415206790==-- From megaco-bounces@ietf.org Wed Jun 08 05:27:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfwqF-0000SR-MO; Wed, 08 Jun 2005 05:27:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfwqE-0000Pr-5U for megaco@megatron.ietf.org; Wed, 08 Jun 2005 05:27: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 FAA10194 for ; Wed, 8 Jun 2005 05:27:14 -0400 (EDT) Received: from [62.90.58.229] (helo=tparelay.telradnetworks.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfxBR-00071J-8h for megaco@ietf.org; Wed, 08 Jun 2005 05:49:13 -0400 Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j589NOn8012753 for ; Wed, 8 Jun 2005 12:23:24 +0300 (IDT) Received: from tpa-mail1.Telrad.co.il ([141.226.76.57]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j589NO1t012750 for ; Wed, 8 Jun 2005 12:23:24 +0300 (IDT) Received: by tpa-mail1.telrad.co.il with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Jun 2005 12:28:23 +0300 Message-ID: From: Tamar Nemet To: "'megaco@ietf.org'" Date: Wed, 8 Jun 2005 12:28:21 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Megaco] Dial Plan. 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="===============0387958386==" 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. --===============0387958386== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56C0C.380F47A0" 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_01C56C0C.380F47A0 Content-Type: text/plain; charset="windows-1255" Hello, Do you know how SoftSwitches activate the dial plan ? Does they do it per call or they send an activation on the ROOT termination ? Thanks, Tamar ------_=_NextPart_001_01C56C0C.380F47A0 Content-Type: text/html; charset="windows-1255"
Hello,
 
Do you know how SoftSwitches activate the dial plan ? Does they do it per call or they send an activation on the ROOT termination ?
 
Thanks,
Tamar
------_=_NextPart_001_01C56C0C.380F47A0-- --===============0387958386== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0387958386==-- From megaco-bounces@ietf.org Wed Jun 08 05:45:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfx7e-0002vJ-Ub; Wed, 08 Jun 2005 05:45:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfx7d-0002vE-5S for megaco@megatron.ietf.org; Wed, 08 Jun 2005 05:45:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11254 for ; Wed, 8 Jun 2005 05:45:14 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfxSr-0007LT-B8 for megaco@ietf.org; Wed, 08 Jun 2005 06:07:14 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1118070183; Wed Jun 08 12:45:15 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Jun 2005 12:48:13 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D30EF@MAILSERVER> From: Raphael Tryster To: "'Tamar Nemet'" , "'megaco@ietf.org'" Subject: RE: [Megaco] Dial Plan. Date: Wed, 8 Jun 2005 12:48:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: 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="===============1571206378==" 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. --===============1571206378== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56C17.8CE6A2E0" 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_01C56C17.8CE6A2E0 Content-Type: text/plain; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable =20 The soft switch has freedom to do whatever works. If the dial plan is simple and fixed, then using the Root termination is an efficient method. However, some special services require a context-sensitive digit map. Fo= r example, the regular digit map may include =93Exx=94 (* followed by 2 dig= its) to active a service. When MGC has received the digit string, it may issue a new digit map because this special service requires entry of more digits, e.g. a number to which to forward calls. This new digit map will typical= ly be more restrictive, as, for example, it would not include a repetition o= f =93Exx=94. So, the more functionality the soft switch offers, the less l= ikely that it can make do with a global digit map. =20 Raphael Tryster =20 =20 -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 11:28 AM To: 'megaco@ietf.org' Subject: [Megaco] Dial Plan. =20 Hello, =20 Do you know how SoftSwitches activate the dial plan ? Does they do it per call or they send an activation on the ROOT termination ? =20 Thanks, Tamar ------_=_NextPart_001_01C56C17.8CE6A2E0 Content-Type: text/html; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable Default Normal Template

Th= e soft switch has freedom to do whatever works.  If the dial plan is simple and fixed, then using the Root terminat= ion is an efficient method.  Howev= er, some special services require a context-sensitive digit map.  For example, the regular digit = map may include =93Exx=94 (* followed by 2 digits) to active a service.  When MGC has received the digit= string, it may issue a new digit map because this special service requires entry = of more digits, e.g. a number to which to forward calls.  This new digit map will typically be more restrictive,= as, for example, it would not include a repetition of  =93Exx=94.  So, the more functionality the soft switch offers, the less likely that it can ma= ke do with a global digit map.

 <= /p>

Raphael Tryster

 

 

-----Original Message-----
From: Tamar Nemet [mailto:tamar.nemet@commatch.com]
Sent: Wednesday, June 08, = 2005 11:28 AM
To: 'megaco@ietf.org'
Subject: [Megaco] Dial Pla= n.

 

Hello,=

 

Do you know how SoftSwitches activate the dial plan ? Does they do it per call o= r they send an activation on the ROOT termination ?

 

Thanks,=

Tamar=

------_=_NextPart_001_01C56C17.8CE6A2E0-- --===============1571206378== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1571206378==-- From megaco-bounces@ietf.org Wed Jun 08 05:50:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfxD9-0003aK-9N; Wed, 08 Jun 2005 05:50:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfxD7-0003aF-DH for megaco@megatron.ietf.org; Wed, 08 Jun 2005 05:50:57 -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 FAA11574 for ; Wed, 8 Jun 2005 05:50:55 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfxYL-0007RA-LY for megaco@ietf.org; Wed, 08 Jun 2005 06:12:54 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1118070183; Wed Jun 08 12:50:45 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Jun 2005 12:53:43 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D30F0@MAILSERVER> From: Raphael Tryster To: "'Tamar Nemet'" , "'megaco@ietf.org'" Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Date: Wed, 8 Jun 2005 12:53:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: 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="===============1968045962==" 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. --===============1968045962== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56C18.5062BBF0" 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_01C56C18.5062BBF0 Content-Type: text/plain; charset="WINDOWS-1255" There is no requirement to artificially split a large gateway into multiple virtual MGs. You might have other reasons for wanting to split it. For example, there might be different sets of global characteristics that you want to set differently for subsets of your terminations, so you would like to have multiple ROOTs. Or, you might want different sets of terminations to be controlled by different soft switches. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 11:22 AM To: 'megaco@ietf.org' Subject: [Megaco] Virtual Media Gateways and amount of Termination IDs Hello, I have some questions regarding Virtual media gateway: 1. I have one physical media gateway (with one IP address). We can define up to 4400 Termination IDs on this media gateway. Does we have to devide the termination IDs to some virtual media gateways or we can work with no virtual media gateway ? 2. Does SoftSwitches uses the Virtual Media Gatway object? for what ? Thanks, Tamar ------_=_NextPart_001_01C56C18.5062BBF0 Content-Type: text/html; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable Default Normal Template

Th= ere is no requirement to artificially split a large gateway into multiple virtua= l MGs.  You might have other reasons fo= r wanting to split it.  For e= xample, there might be different sets of global characteristics that you want to = set differently for subsets of your terminations, so you would like to have m= ultiple ROOTs.  Or, you might want different sets of terminations to be controlled by different soft switche= s.

 <= /p>

Raphael Tryster

 

 

-----Original Message-----
From: Tamar Nemet [mailto:= tamar.nemet@commatch.com]
Sent: Wednesday, June 08, = 2005 11:22 AM
To: 'megaco@ietf.org'
Subject: [Megaco] Virtual = Media Gateways and amount of Termination IDs

 

Hello,=

 

I have some questions regarding Virtual media gateway:

 

1. I have one physical media gateway (with one IP address). We can define up t= o 4400 Termination IDs on this media gateway.

    Does we have to devide the termination IDs to some virtual media gateways= or we can work with no virtual media gateway ?

 

2. Does SoftSwitches uses the Virtual Media Gatway object? for what ?=

 

Thanks,=

Tamar=

 

------_=_NextPart_001_01C56C18.5062BBF0-- --===============1968045962== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1968045962==-- From megaco-bounces@ietf.org Wed Jun 08 06:30:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfxpB-0000ZA-Do; Wed, 08 Jun 2005 06:30:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfxp7-0000Yw-NJ for megaco@megatron.ietf.org; Wed, 08 Jun 2005 06:30:15 -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 GAA13464 for ; Wed, 8 Jun 2005 06:30:10 -0400 (EDT) Received: from [62.90.58.229] (helo=tparelay.telradnetworks.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfyAL-00086k-KG for megaco@ietf.org; Wed, 08 Jun 2005 06:52:10 -0400 Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j58AQIJ0002852 for ; Wed, 8 Jun 2005 13:26:18 +0300 (IDT) Received: from tpa-mail1.Telrad.co.il ([141.226.76.57]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j58AQHJ3002841; Wed, 8 Jun 2005 13:26:17 +0300 (IDT) Received: by tpa-mail1.telrad.co.il with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Jun 2005 13:31:16 +0300 Message-ID: From: Tamar Nemet To: "'Raphael Tryster'" , Tamar Nemet , "'megaco@ietf.org'" Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Date: Wed, 8 Jun 2005 13:31:07 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.3 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Cc: 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="===============0164120834==" 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. --===============0164120834== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56C14.D4BE0B9C" 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_01C56C14.D4BE0B9C Content-Type: text/plain; charset="windows-1255" Hello raphael, Thanks for your answer. But I can't understand how the SoftSwitch can use multiple ROOTs if the all the Virtual Media Gateways has the same IP address ? Did you see any SoftSwitch that uses the Virtual MediaGateways ? Thanks, Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 1:54 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs There is no requirement to artificially split a large gateway into multiple virtual MGs. You might have other reasons for wanting to split it. For example, there might be different sets of global characteristics that you want to set differently for subsets of your terminations, so you would like to have multiple ROOTs. Or, you might want different sets of terminations to be controlled by different soft switches. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 11:22 AM To: 'megaco@ietf.org' Subject: [Megaco] Virtual Media Gateways and amount of Termination IDs Hello, I have some questions regarding Virtual media gateway: 1. I have one physical media gateway (with one IP address). We can define up to 4400 Termination IDs on this media gateway. Does we have to devide the termination IDs to some virtual media gateways or we can work with no virtual media gateway ? 2. Does SoftSwitches uses the Virtual Media Gatway object? for what ? Thanks, Tamar ------_=_NextPart_001_01C56C14.D4BE0B9C Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Default Normal Template =

 Hello raphael,
 
 Thanks for your answer. But I can't understand = how the=20 SoftSwitch can use multiple ROOTs if the all the Virtual Media = Gateways has=20 the same IP address ?
 
Did=20 you see any SoftSwitch that uses the Virtual MediaGateways = ?
 
Thanks,
Tamar 
 
-----Original Message-----
From: Raphael Tryster=20 [mailto:raphael@tdsoft.com]
Sent: Wednesday, June 08, 2005 = 1:54=20 PM
To: 'Tamar Nemet'; 'megaco@ietf.org'
Subject: = RE:=20 [Megaco] Virtual Media Gateways and amount of Termination=20 IDs

There=20 is no requirement to artificially split a large gateway into multiple = virtual=20 MGs.  You might have = other reasons=20 for wanting to split it.  = For=20 example, there might be different sets of global characteristics that = you want=20 to set differently for subsets of your terminations, so you would = like to have=20 multiple ROOTs.  Or, = you might=20 want different sets of terminations to be controlled by different = soft=20 switches.

 

Raphael=20 Tryster

 

 

-----Original=20 Message-----
From: = Tamar=20 Nemet [mailto:tamar.nemet@commatch.com]
Sent: Wednesday, June 08, 2005 = 11:22=20 AM
To:=20 'megaco@ietf.org'
Subject:=20 [Megaco] Virtual Media Gateways and amount of Termination=20 IDs

 

Hello,

 

I have=20 some questions regarding Virtual media gateway:

 

1. I=20 have one physical media gateway (with one IP address). We can define = up to=20 4400 Termination IDs on this media gateway.

   =20 Does we have to devide the termination IDs to some virtual media = gateways or=20 we can work with no virtual media gateway ?

 

2. Does=20 SoftSwitches uses the Virtual Media Gatway object? for what=20 ?

 

Thanks,

Tamar

 

------_=_NextPart_001_01C56C14.D4BE0B9C-- --===============0164120834== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0164120834==-- From megaco-bounces@ietf.org Wed Jun 08 07:14:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfyVv-0007U7-W0; Wed, 08 Jun 2005 07:14:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfyVs-0007TS-Ff for megaco@megatron.ietf.org; Wed, 08 Jun 2005 07:14: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 HAA16742 for ; Wed, 8 Jun 2005 07:14:21 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dfyr6-0000gL-9U for megaco@ietf.org; Wed, 08 Jun 2005 07:36:21 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1118070183; Wed Jun 08 14:14:22 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Jun 2005 14:17:17 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D30F2@MAILSERVER> From: Raphael Tryster To: "'Tamar Nemet'" , "'megaco@ietf.org'" Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Date: Wed, 8 Jun 2005 14:17:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.3 (/) X-Scan-Signature: f2a5dc784731617f446f668f2c529db6 Cc: 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="===============2140034423==" 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. --===============2140034423== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56C23.FD9D5950" 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_01C56C23.FD9D5950 Content-Type: text/plain; charset="WINDOWS-1255" They can use different UDP ports. The answer to your second question is No, but I would also be interested to hear different answers from others. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 12:31 PM To: Raphael Tryster; Tamar Nemet; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Hello raphael, Thanks for your answer. But I can't understand how the SoftSwitch can use multiple ROOTs if the all the Virtual Media Gateways has the same IP address ? Did you see any SoftSwitch that uses the Virtual MediaGateways ? Thanks, Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 1:54 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs There is no requirement to artificially split a large gateway into multiple virtual MGs. You might have other reasons for wanting to split it. For example, there might be different sets of global characteristics that you want to set differently for subsets of your terminations, so you would like to have multiple ROOTs. Or, you might want different sets of terminations to be controlled by different soft switches. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 11:22 AM To: 'megaco@ietf.org' Subject: [Megaco] Virtual Media Gateways and amount of Termination IDs Hello, I have some questions regarding Virtual media gateway: 1. I have one physical media gateway (with one IP address). We can define up to 4400 Termination IDs on this media gateway. Does we have to devide the termination IDs to some virtual media gateways or we can work with no virtual media gateway ? 2. Does SoftSwitches uses the Virtual Media Gatway object? for what ? Thanks, Tamar ------_=_NextPart_001_01C56C23.FD9D5950 Content-Type: text/html; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable Default Normal Template

They can use different UDP ports.  The answer to your second question is No, but I would also be inte= rested to hear different answers from others.

 

Raphael Tryster=

 <= ![endif]>

 <= /p>

-----Original Message-----
From: Tamar Nemet [mailto:tamar.nemet@commatch.com]
Sent: Wednesday, June 08, = 2005 12:31 PM
To: Raphael Tryster; Tamar= Nemet; 'megaco@ietf.org'
Subject: RE: [Megaco] Virt= ual Media Gateways and amount of Termination IDs

 

<= /p>

 Hello rapha= el,<= /o:p>

&nb= sp;<= /o:p>

 Thanks for your answer. But I can't understand how the SoftSwitch can = use multiple ROOTs if the all the Virtual Media Gateways has the same IP address ?

&nb= sp;<= /o:p>

Did you see any SoftSwitch that uses the Virtual MediaGateways ?<= /o:p>

&nb= sp;<= /o:p>

Thanks,<= /o:p>

Tamar <= /p>

 

-----Original Message-----
From: Raphael Tryster [mailto:raphael@tdsoft.com]
Sent: Wednesday, June 08, = 2005 1:54 PM
To: 'Tamar Nemet'; 'megaco@ietf.org'
Subject: RE: [Megaco] Virt= ual Media Gateways and amount of Termination IDs<= /p>

There is no requirement to artificially split a large gateway into multip= le virtual MGs.  You might hav= e other reasons for wanting to split it.  For example, there might be different sets of global characteristi= cs that you want to set differently for subsets of your terminations, so you= would like to have multiple ROOTs.  Or, you might want different sets of terminations to be controlled by differe= nt soft switches.

 

Raph= ael Tryster

 = ;

 

-----Original Message-----
From: Tamar Nemet [mailto:tamar.nemet@commatch.com]
Sent: Wednesday, June 08, = 2005 11:22 AM
To: 'megaco@ietf.org'
Subject: [Megaco] Virtual = Media Gateways and amount of Termination IDs<= span style=3D'color:black;mso-color-alt:windowtext'><= /p>

&nb= sp;<= /o:p>

Hello,=

 

I have some questions regarding Virtual media gateway:

 

1. I have one physical media gateway (with one IP address). We can define up t= o 4400 Termination IDs on this media gateway.

    Does we have to devide the termination IDs to some virtual media gateways= or we can work with no virtual media gateway ?

 

2. Does SoftSwitches uses the Virtual Media Gatway object? for what ?=

 

Thanks,=

Tamar=

 

------_=_NextPart_001_01C56C23.FD9D5950-- --===============2140034423== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============2140034423==-- From megaco-bounces@ietf.org Wed Jun 08 08:05:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfzIv-00060w-PW; Wed, 08 Jun 2005 08:05:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfzIu-00060j-Og for megaco@megatron.ietf.org; Wed, 08 Jun 2005 08:05: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 IAA20008 for ; Wed, 8 Jun 2005 08:05:02 -0400 (EDT) Received: from [62.90.58.229] (helo=tparelay.telradnetworks.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfze0-0001tL-OX for megaco@ietf.org; Wed, 08 Jun 2005 08:27:01 -0400 Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j58C0qgc005123 for ; Wed, 8 Jun 2005 15:00:52 +0300 (IDT) Received: from tpa-mail1.Telrad.co.il ([141.226.76.57]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j58C0pU8005118; Wed, 8 Jun 2005 15:00:51 +0300 (IDT) Received: by tpa-mail1.telrad.co.il with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Jun 2005 15:05:50 +0300 Message-ID: From: Tamar Nemet To: "'Raphael Tryster'" , Tamar Nemet , "'megaco@ietf.org'" Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Date: Wed, 8 Jun 2005 15:05:43 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.4 (/) X-Scan-Signature: 0e831a3b581a967a651997b2cbc2bae7 Cc: 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="===============1322298681==" 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. --===============1322298681== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56C22.22EC9EAC" 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_01C56C22.22EC9EAC Content-Type: text/plain; charset="windows-1255" Can the SoftSwitch use different FQDNs for virtual media gateways and not the ip address and port of the physical Media gateway ? Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 3:17 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs They can use different UDP ports. The answer to your second question is No, but I would also be interested to hear different answers from others. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 12:31 PM To: Raphael Tryster; Tamar Nemet; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Hello raphael, Thanks for your answer. But I can't understand how the SoftSwitch can use multiple ROOTs if the all the Virtual Media Gateways has the same IP address ? Did you see any SoftSwitch that uses the Virtual MediaGateways ? Thanks, Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 1:54 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs There is no requirement to artificially split a large gateway into multiple virtual MGs. You might have other reasons for wanting to split it. For example, there might be different sets of global characteristics that you want to set differently for subsets of your terminations, so you would like to have multiple ROOTs. Or, you might want different sets of terminations to be controlled by different soft switches. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 11:22 AM To: 'megaco@ietf.org' Subject: [Megaco] Virtual Media Gateways and amount of Termination IDs Hello, I have some questions regarding Virtual media gateway: 1. I have one physical media gateway (with one IP address). We can define up to 4400 Termination IDs on this media gateway. Does we have to devide the termination IDs to some virtual media gateways or we can work with no virtual media gateway ? 2. Does SoftSwitches uses the Virtual Media Gatway object? for what ? Thanks, Tamar ------_=_NextPart_001_01C56C22.22EC9EAC Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Default Normal Template =

 Can the SoftSwitch use different FQDNs for virtual = media=20 gateways and not the ip address and port of the physical Media gateway=20 ?
 
Tamar

 
-----Original Message-----
From: Raphael Tryster=20 [mailto:raphael@tdsoft.com]
Sent: Wednesday, June 08, 2005 = 3:17=20 PM
To: 'Tamar Nemet'; 'megaco@ietf.org'
Subject: = RE:=20 [Megaco] Virtual Media Gateways and amount of Termination=20 IDs

They=20 can use different UDP ports.  = The=20 answer to your second question is No, but I would also be interested = to hear=20 different answers from others.

 

Raphael=20 Tryster

 

 

-----Original=20 Message-----
From: = Tamar=20 Nemet [mailto:tamar.nemet@commatch.com]
Sent: Wednesday, June 08, 2005 = 12:31=20 PM
To: Raphael = Tryster; Tamar=20 Nemet; 'megaco@ietf.org'
Subject: RE: [Megaco] Virtual = Media=20 Gateways and amount of Termination IDs

 


 Hello=20 raphael,=20

 

 Thanks for your=20 answer. But I can't understand how the SoftSwitch can use = multiple=20 ROOTs if the all the Virtual Media Gateways has the same IP = address=20 ?

 

Did you=20 see any SoftSwitch that uses the Virtual MediaGateways = ?

 

Thanks,

Tamar 

 

-----Original=20 Message-----
From: = Raphael=20 Tryster [mailto:raphael@tdsoft.com]
Sent: Wednesday, June 08, 2005 = 1:54=20 PM
To: 'Tamar = Nemet';=20 'megaco@ietf.org'
Subject:=20 RE: [Megaco] Virtual Media Gateways and amount of Termination=20 IDs

There is no = requirement to=20 artificially split a large gateway into multiple virtual MGs.  You might have other = reasons for=20 wanting to split it.  = For example,=20 there might be different sets of global characteristics that you want = to set=20 differently for subsets of your terminations, so you would like to = have=20 multiple ROOTs.  Or, = you might=20 want different sets of terminations to be controlled by different = soft=20 switches.

 

Raphael=20 Tryster

 

 

-----Original=20 Message-----
From: = Tamar=20 Nemet [mailto:tamar.nemet@commatch.com]
Sent: Wednesday, June 08, 2005 = 11:22=20 AM
To:=20 'megaco@ietf.org'
Subject:=20 [Megaco] Virtual Media Gateways and amount of Termination=20 IDs

 

Hello,

 

I have=20 some questions regarding Virtual media gateway:

 

1. I=20 have one physical media gateway (with one IP address). We can define = up to=20 4400 Termination IDs on this media gateway.

   =20 Does we have to devide the termination IDs to some virtual media = gateways or=20 we can work with no virtual media gateway ?

 

2. Does=20 SoftSwitches uses the Virtual Media Gatway object? for what=20 ?

 

Thanks,

Tamar

 

------_=_NextPart_001_01C56C22.22EC9EAC-- --===============1322298681== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1322298681==-- From megaco-bounces@ietf.org Wed Jun 08 13:41:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg4Yj-0006Yb-IQ; Wed, 08 Jun 2005 13:41:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg4Yh-0006YU-Uc for megaco@megatron.ietf.org; Wed, 08 Jun 2005 13:41: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 NAA20303 for ; Wed, 8 Jun 2005 13:41:42 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg4u0-0001va-HA for megaco@ietf.org; Wed, 08 Jun 2005 14:03:45 -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/ICT TSC MAIL 2005) with ESMTP id j58HfNVa004600; Wed, 8 Jun 2005 19:41:23 +0200 In-Reply-To: Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs To: Tamar Nemet X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Wed, 8 Jun 2005 19:41:22 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF141 | May 13, 2005) at 06/08/2005 19:41:22 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable Cc: "'megaco@ietf.org'" , 'Raphael Tryster' 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 Addressing IP interfaces of a H.248 MG is NO rationale for the introduc= tion of VMGs. There are typically other requirements driving for VMG approaches. Even= so, the VMGs may share address space, or use disjoint IP addresses for the diversity of IP applications served by a VoIP MG. This depends on the specific use case and underlying network architecture. So, please not misread =A7 11.1/H.248.1. Rgds, Albrecht ALCATEL = =20 Tamar Nemet = =20 , Tamar Nemet =20 match.com> , "'megaco@ietf.org'" =20 Sent by: cc: = =20 megaco-bounces@i Subject: RE: [Megaco] Vi= rtual Media Gateways and amount of Termination IDs =20 etf.org = =20 = =20 = =20 08.06.2005 14:05 = =20 = =20 Can the SoftSwitch use different FQDNs for virtual media gateways and = not the ip address and port of the physical Media gateway ? Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 3:17 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs They can use different UDP ports. The answer to your second ques= tion is No, but I would also be interested to hear different answers f= rom others. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 12:31 PM To: Raphael Tryster; Tamar Nemet; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Hello raphael, Thanks for your answer. But I can't understand how the SoftSwitch can use multiple ROOTs if the all the Virtual Me= dia Gateways has the same IP address ? Did you see any SoftSwitch that uses the Virtual MediaGatew= ays ? Thanks, Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 1:54 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amou= nt of Termination IDs There is no requirement to artificially split a large= gateway into multiple virtual MGs. You might have ot= her reasons for wanting to split it. For example, there might be different sets of global characteristics tha= t you want to set differently for subsets of your terminations, so you would like to have multiple ROOT= s. Or, you might want different sets of terminations to = be controlled by different soft switches. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.= com] Sent: Wednesday, June 08, 2005 11:22 AM To: 'megaco@ietf.org' Subject: [Megaco] Virtual Media Gateways and am= ount of Termination IDs Hello, I have some questions regarding Virtual media gateway: 1. I have one physical media gateway (with one = IP address). We can define up to 4400 Termination = IDs on this media gateway. Does we have to devide the termination IDs = to some virtual media gateways or we can work with= no virtual media gateway ? 2. Does SoftSwitches uses the Virtual Media Gat= way object? for what ? Thanks, Tamar ______________________________________________= _ Megaco mailing 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 Jun 08 17:02:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg7hI-00041X-Iy; Wed, 08 Jun 2005 17:02:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg7hF-00040j-Kv for megaco@megatron.ietf.org; Wed, 08 Jun 2005 17:02:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17538 for ; Wed, 8 Jun 2005 17:02:39 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg821-0001tZ-GY for megaco@ietf.org; Wed, 08 Jun 2005 17:24: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 j58L1j416989 for ; Wed, 8 Jun 2005 17:01:45 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jun 2005 17:01:45 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4025DB978@zrtphxm2> From: "Kevin Boyle" To: Tamar Nemet , "'megaco@ietf.org'" Subject: RE: [Megaco] Dial Plan. Date: Wed, 8 Jun 2005 17:01:32 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 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 MGs don't generally know about "dial plans". They are told to collect digits, through any of a number of means, and they report them. The MGC is responsible for translating the reported digits by applying the local dial plan. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Tamar Nemet Sent: Wednesday, June 08, 2005 5:28 AM To: 'megaco@ietf.org' Subject: [Megaco] Dial Plan. Hello, Do you know how SoftSwitches activate the dial plan ? Does they do it per call or they send an activation on the ROOT termination ? Thanks, Tamar _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Jun 08 17:17:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg7vM-0007L6-Gk; Wed, 08 Jun 2005 17:17:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg7vK-0007Id-KT for megaco@megatron.ietf.org; Wed, 08 Jun 2005 17:17: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 RAA18551 for ; Wed, 8 Jun 2005 17:17:16 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg8GB-0002J0-2k for megaco@ietf.org; Wed, 08 Jun 2005 17:38:51 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j58L0Ik01659 for ; Wed, 8 Jun 2005 17:00:18 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jun 2005 16:59:58 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4025DB96D@zrtphxm2> From: "Kevin Boyle" To: Tamar Nemet , "'Raphael Tryster'" , "'megaco@ietf.org'" Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Date: Wed, 8 Jun 2005 16:59:48 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Some way of addressing the VMGs independently of each other is necessary. FQDNs is one possible way. I know of several MGCs that make use of VMGs. The main point of VMGs is to either allow partitioned control by different MGCs, or to allow resource pooling that is not visible to the MGC. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Tamar Nemet Sent: Wednesday, June 08, 2005 8:06 AM To: 'Raphael Tryster'; Tamar Nemet; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Can the SoftSwitch use different FQDNs for virtual media gateways and not the ip address and port of the physical Media gateway ? Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 3:17 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs They can use different UDP ports. The answer to your second question is No, but I would also be interested to hear different answers from others. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 12:31 PM To: Raphael Tryster; Tamar Nemet; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Hello raphael, Thanks for your answer. But I can't understand how the SoftSwitch can use multiple ROOTs if the all the Virtual Media Gateways has the same IP address ? Did you see any SoftSwitch that uses the Virtual MediaGateways ? Thanks, Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 1:54 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs There is no requirement to artificially split a large gateway into multiple virtual MGs. You might have other reasons for wanting to split it. For example, there might be different sets of global characteristics that you want to set differently for subsets of your terminations, so you would like to have multiple ROOTs. Or, you might want different sets of terminations to be controlled by different soft switches. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 11:22 AM To: 'megaco@ietf.org' Subject: [Megaco] Virtual Media Gateways and amount of Termination IDs Hello, I have some questions regarding Virtual media gateway: 1. I have one physical media gateway (with one IP address). We can define up to 4400 Termination IDs on this media gateway. Does we have to devide the termination IDs to some virtual media gateways or we can work with no virtual media gateway ? 2. Does SoftSwitches uses the Virtual Media Gatway object? for what ? Thanks, Tamar _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 09 00:52:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgF20-0005ny-Jr; Thu, 09 Jun 2005 00:52:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgF1t-0005nt-4f for megaco@megatron.ietf.org; Thu, 09 Jun 2005 00:52:33 -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 AAA29276 for ; Thu, 9 Jun 2005 00:52:29 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DgFMm-0007mI-SP for megaco@ietf.org; Thu, 09 Jun 2005 01:14:10 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1118070183; Thu Jun 09 07:51:52 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Jun 2005 07:54:45 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D30F8@MAILSERVER> From: Raphael Tryster To: "'Albrecht.Schwarz@alcatel.de'" , Tamar Nemet Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Date: Thu, 9 Jun 2005 07:54:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b83962958e2d910ed948e2f9e138d171 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="===============1487962543==" 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. --===============1487962543== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56CB7.BC3C4A90" 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_01C56CB7.BC3C4A90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do you mean that a physical MG might have several different signaling IP addresses but NOT be divided into multiple virtual MGs? Raphael Tryster -----Original Message----- From: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] Sent: Wednesday, June 08, 2005 7:41 PM To: Tamar Nemet Cc: 'megaco@ietf.org'; Raphael Tryster Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination ID= s Addressing IP interfaces of a H.248 MG is NO rationale for the introducti= on of VMGs. There are typically other requirements driving for VMG approaches. Even s= o, the VMGs may share address space, or use disjoint IP addresses for the diversity of IP applications served by a VoIP MG. This depends on the specific use case and underlying network architecture. So, please not misread =A7 11.1/H.248.1. Rgds, Albrecht ALCATEL =20 Tamar Nemet =20 Sent by: cc: megaco-bounces@i Subject: RE: [Megaco] Virt= ual Media Gateways and amount of Termination IDs =20 etf.org =20 =20 08.06.2005 14:05 =20 Can the SoftSwitch use different FQDNs for virtual media gateways and no= t the ip address and port of the physical Media gateway ? Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 3:17 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs They can use different UDP ports. The answer to your second questi= on is No, but I would also be interested to hear different answers fro= m others. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 12:31 PM To: Raphael Tryster; Tamar Nemet; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Hello raphael, Thanks for your answer. But I can't understand how the SoftSwitch can use multiple ROOTs if the all the Virtual Medi= a Gateways has the same IP address ? Did you see any SoftSwitch that uses the Virtual MediaGateway= s ? Thanks, Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 1:54 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs There is no requirement to artificially split a large gateway into multiple virtual MGs. You might have othe= r reasons for wanting to split it. For example, there might be different sets of global characteristics that you want to set differently for subsets of your terminations, so you would like to have multiple ROOTs. Or, you might want different sets of terminations to be controlled by different soft switches. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.co= m] Sent: Wednesday, June 08, 2005 11:22 AM To: 'megaco@ietf.org' Subject: [Megaco] Virtual Media Gateways and amou= nt of Termination IDs Hello, I have some questions regarding Virtual media gateway: 1. I have one physical media gateway (with one IP address). We can define up to 4400 Termination ID= s on this media gateway. Does we have to devide the termination IDs to some virtual media gateways or we can work with n= o virtual media gateway ? 2. Does SoftSwitches uses the Virtual Media Gatwa= y object? for what ? Thanks, Tamar _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C56CB7.BC3C4A90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Virtual Media Gateways and amount of Termination IDs<= /TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Do you mean that a physical MG might have several diffe= rent signaling IP addresses but NOT be divided into multiple virtual MGs?= </FONT></P> <P><FONT SIZE=3D2>Raphael Tryster</FONT> </P> <BR> <P><FONT SIZE=3D2>-----Original Message-----</FONT> <BR><FONT SIZE=3D2>From: Albrecht.Schwarz@alcatel.de [<A HREF=3D"mailto:A= lbrecht.Schwarz@alcatel.de">mailto:Albrecht.Schwarz@alcatel.de</A>]</FONT= > <BR><FONT SIZE=3D2>Sent: Wednesday, June 08, 2005 7:41 PM</FONT> <BR><FONT SIZE=3D2>To: Tamar Nemet</FONT> <BR><FONT SIZE=3D2>Cc: 'megaco@ietf.org'; Raphael Tryster</FONT> <BR><FONT SIZE=3D2>Subject: RE: [Megaco] Virtual Media Gateways and amoun= t of Termination IDs</FONT> </P> <BR> <P><FONT SIZE=3D2>Addressing IP interfaces of a H.248 MG is NO rationale = for the introduction</FONT> <BR><FONT SIZE=3D2>of VMGs.</FONT> <BR><FONT SIZE=3D2>There are typically other requirements driving for VMG= approaches. Even so,</FONT> <BR><FONT SIZE=3D2>the VMGs may share address space, or use disjoint IP a= ddresses for the</FONT> <BR><FONT SIZE=3D2>diversity of IP applications served by a VoIP MG. This= depends on the</FONT> <BR><FONT SIZE=3D2>specific use case and underlying network architecture.= </FONT> </P> <P><FONT SIZE=3D2>So, please not misread =A7 11.1/H.248.1.</FONT> </P> <P><FONT SIZE=3D2>Rgds,</FONT> <BR><FONT SIZE=3D2>Albrecht</FONT> <BR><FONT SIZE=3D2>ALCATEL</FONT> </P> <BR> <BR> <BR> <P><FONT SIZE=3D2>         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;              </FONT></P> <P><FONT SIZE=3D2>         &= nbsp;            T= amar Nemet          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;    </FONT></P> <P><FONT SIZE=3D2>         &= nbsp;            &= lt;tamar.nemet@com         To:&nb= sp;     "'Raphael Tryster'" <raphael@tds= oft.com>, Tamar Nemet        &= nbsp;           &n= bsp;   </FONT></P> <P><FONT SIZE=3D2>         &= nbsp;            m= atch.com>          &= nbsp;    <tamar.nemet@commatch.com>, "'megaco@i= etf.org'" <megaco@ietf.org>      = ;            =    </FONT></P> <P><FONT SIZE=3D2>         &= nbsp;            S= ent by:           =       cc:      &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   </FONT></P> <P><FONT SIZE=3D2>         &= nbsp;            m= egaco-bounces@i         Subject: = RE: [Megaco] Virtual Media Gateways and amount of Termination IDs &n= bsp;          </FONT></P> <P><FONT SIZE=3D2>         &= nbsp;            e= tf.org           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;       </FONT></P> <P><FONT SIZE=3D2>         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;              </FONT></P> <P><FONT SIZE=3D2>         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;              </FONT></P> <P><FONT SIZE=3D2>         &= nbsp;            0= 8.06.2005 14:05         &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            </FO= NT></P> <P><FONT SIZE=3D2>         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;              </FONT></P> <BR> <BR> <BR> <BR> <P><FONT SIZE=3D2> Can the SoftSwitch use different FQDNs for virtua= l media gateways and not</FONT> <BR><FONT SIZE=3D2>the ip address and port of the physical Media gateway = ?</FONT> </P> <P><FONT SIZE=3D2>Tamar</FONT> </P> <BR> <P><FONT SIZE=3D2>      -----Original Message---= --</FONT> <BR><FONT SIZE=3D2>      From: Raphael Tryster [= <A HREF=3D"mailto:raphael@tdsoft.com">mailto:raphael@tdsoft.com</A>]</FON= T> <BR><FONT SIZE=3D2>      Sent: Wednesday, June 0= 8, 2005 3:17 PM</FONT> <BR><FONT SIZE=3D2>      To: 'Tamar Nemet'; 'meg= aco@ietf.org'</FONT> <BR><FONT SIZE=3D2>      Subject: RE: [Megaco] V= irtual Media Gateways and amount of</FONT> <BR><FONT SIZE=3D2>      Termination IDs</FONT> </P> <P><FONT SIZE=3D2>      They can use different U= DP ports.  The answer to your second question</FONT> <BR><FONT SIZE=3D2>      is No, but I would also= be interested to hear different answers from</FONT> <BR><FONT SIZE=3D2>      others.</FONT> </P> <P><FONT SIZE=3D2>      Raphael Tryster</FONT> </P> <BR> <P><FONT SIZE=3D2>         &= nbsp;  -----Original Message-----</FONT> <BR><FONT SIZE=3D2>         =    From: Tamar Nemet [<A HREF=3D"mailto:tamar.nemet@commatch.co= m">mailto:tamar.nemet@commatch.com</A>]</FONT> <BR><FONT SIZE=3D2>         =    Sent: Wednesday, June 08, 2005 12:31 PM</FONT> <BR><FONT SIZE=3D2>         =    To: Raphael Tryster; Tamar Nemet; 'megaco@ietf.org'</FONT> <BR><FONT SIZE=3D2>         =    Subject: RE: [Megaco] Virtual Media Gateways and amount of</= FONT> <BR><FONT SIZE=3D2>         =    Termination IDs</FONT> </P> <BR> <P><FONT SIZE=3D2>         &= nbsp;   Hello raphael,</FONT> </P> <P><FONT SIZE=3D2>         &= nbsp;   Thanks for your answer. But I can't understand how the<= /FONT> <BR><FONT SIZE=3D2>         =    SoftSwitch can use multiple ROOTs if the all the Virtual Med= ia</FONT> <BR><FONT SIZE=3D2>         =    Gateways has the same IP address ?</FONT> </P> <P><FONT SIZE=3D2>         &= nbsp;  Did you see any SoftSwitch that uses the Virtual MediaGateway= s</FONT> <BR><FONT SIZE=3D2>         =    ?</FONT> </P> <P><FONT SIZE=3D2>         &= nbsp;  Thanks,</FONT> <BR><FONT SIZE=3D2>         =    Tamar</FONT> </P> <P><FONT SIZE=3D2>         &= nbsp;        -----Original Message----= -</FONT> <BR><FONT SIZE=3D2>         =          From: Raphael Tryster [<= A HREF=3D"mailto:raphael@tdsoft.com">mailto:raphael@tdsoft.com</A>]</FONT= > <BR><FONT SIZE=3D2>         =          Sent: Wednesday, June 08= , 2005 1:54 PM</FONT> <BR><FONT SIZE=3D2>         =          To: 'Tamar Nemet'; 'mega= co@ietf.org'</FONT> <BR><FONT SIZE=3D2>         =          Subject: RE: [Megaco] Vi= rtual Media Gateways and amount</FONT> <BR><FONT SIZE=3D2>         =          of Termination IDs</FONT= > <BR><FONT SIZE=3D2>         =          There is no requirement = to artificially split a large</FONT> <BR><FONT SIZE=3D2>         =          gateway into multiple vi= rtual MGs.  You might have other</FONT> <BR><FONT SIZE=3D2>         =          reasons for wanting to s= plit it.  For example, there</FONT> <BR><FONT SIZE=3D2>         =          might be different sets = of global characteristics that</FONT> <BR><FONT SIZE=3D2>         =          you want to set differen= tly for subsets of your</FONT> <BR><FONT SIZE=3D2>         =          terminations, so you wou= ld like to have multiple ROOTs.</FONT> <BR><FONT SIZE=3D2>         =          Or, you might want diffe= rent sets of terminations to be</FONT> <BR><FONT SIZE=3D2>         =          controlled by different = soft switches.</FONT> </P> <P><FONT SIZE=3D2>         &= nbsp;        Raphael Tryster</FONT> </P> <BR> <P><FONT SIZE=3D2>         &= nbsp;           &n= bsp;  -----Original Message-----</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  From: Tamar Nemet [<A HREF=3D"mailto:tamar.nemet@commatch.com= ">mailto:tamar.nemet@commatch.com</A>]</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  Sent: Wednesday, June 08, 2005 11:22 AM</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  To: 'megaco@ietf.org'</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  Subject: [Megaco] Virtual Media Gateways and amount</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  of Termination IDs</FONT> </P> <P><FONT SIZE=3D2>         &= nbsp;           &n= bsp;  Hello,</FONT> </P> <P><FONT SIZE=3D2>         &= nbsp;           &n= bsp;  I have some questions regarding Virtual media</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  gateway:</FONT> </P> <P><FONT SIZE=3D2>         &= nbsp;           &n= bsp;  1. I have one physical media gateway (with one IP</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  address). We can define up to 4400 Termination IDs</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  on this media gateway.</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;      Does we have to devide the terminatio= n IDs to</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  some virtual media gateways or we can work with no</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  virtual media gateway ?</FONT> </P> <P><FONT SIZE=3D2>         &= nbsp;           &n= bsp;  2. Does SoftSwitches uses the Virtual Media Gatway</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  object? for what ?</FONT> </P> <P><FONT SIZE=3D2>         &= nbsp;           &n= bsp;  Thanks,</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  Tamar</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;   _______________________________________________</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  Megaco mailing list</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  Megaco@ietf.org</FONT> <BR><FONT SIZE=3D2>         =             &= nbsp;  <A HREF=3D"https://www1.ietf.org/mailman/listinfo/megaco" TAR= GET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C56CB7.BC3C4A90-- --===============1487962543== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1487962543==-- From megaco-bounces@ietf.org Thu Jun 09 05:08:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgJ1F-0003yk-KJ; Thu, 09 Jun 2005 05:08:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgJ1E-0003yf-T4 for megaco@megatron.ietf.org; Thu, 09 Jun 2005 05:08:08 -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 FAA05350 for <megaco@ietf.org>; Thu, 9 Jun 2005 05:08:06 -0400 (EDT) Received: from [62.90.58.229] (helo=tparelay.telradnetworks.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgJM3-0000X6-08 for megaco@ietf.org; Thu, 09 Jun 2005 05:29:47 -0400 Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j5993XhH024174 for <megaco@ietf.org>; Thu, 9 Jun 2005 12:03:33 +0300 (IDT) Received: from tpa-mail1.Telrad.co.il ([141.226.76.57]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j5993XOW024169 for <megaco@ietf.org>; Thu, 9 Jun 2005 12:03:33 +0300 (IDT) Received: by tpa-mail1.telrad.co.il with Internet Mail Service (5.5.2657.72) id <J5NK782S>; Thu, 9 Jun 2005 12:08:32 +0300 Message-ID: <C0F328F4B564A544ADBA98DA8BBE86F1265ED3@tpa-mail1.telrad.co.il> From: Tamar Nemet <tamar.nemet@commatch.com> To: "'megaco@ietf.org'" <megaco@ietf.org> Date: Thu, 9 Jun 2005 12:08:31 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Megaco] Nortel SoftSwitch and others X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control <megaco.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe> List-Post: <mailto:megaco@ietf.org> List-Help: <mailto:megaco-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1089082198==" 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. --===============1089082198== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56CD2.CEBA8C52" 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_01C56CD2.CEBA8C52 Content-Type: text/plain; charset="windows-1255" Hello, I know that Nortel SoftSwitch allow provisioning of up to 1000 Termination IDs on the same MG. Does anybody knows how much Termination IDs other SoftSwitch allows ? (for example: Alcatel Soft Switch) Thanks, Tamar ------_=_NextPart_001_01C56CD2.CEBA8C52 Content-Type: text/html; charset="windows-1255" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1255"> <META content="MSHTML 6.00.2800.1498" name=GENERATOR></HEAD> <BODY style="COLOR: #000000; FONT-FAMILY: Arial"><LABEL id=HbSession SessionId="2809500161"></LABEL> <DIV><SPAN class=364450309-09062005><FONT size=2>Hello,</FONT></SPAN></DIV> <DIV><SPAN class=364450309-09062005><FONT size=2></FONT></SPAN> </DIV> <DIV><SPAN class=364450309-09062005><FONT size=2>I know that Nortel SoftSwitch allow provisioning of up to 1000 Termination IDs on the same MG. </FONT></SPAN></DIV> <DIV><SPAN class=364450309-09062005><FONT size=2></FONT></SPAN> </DIV> <DIV><SPAN class=364450309-09062005><FONT size=2>Does anybody knows how much Termination IDs other SoftSwitch allows ? (for example: Alcatel Soft Switch)</FONT></SPAN></DIV> <DIV><SPAN class=364450309-09062005><FONT size=2></FONT></SPAN> </DIV> <DIV><SPAN class=364450309-09062005><FONT size=2>Thanks,</FONT></SPAN></DIV> <DIV><SPAN class=364450309-09062005><FONT size=2>Tamar</FONT></SPAN></DIV></BODY></HTML> ------_=_NextPart_001_01C56CD2.CEBA8C52-- --===============1089082198== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1089082198==-- From megaco-bounces@ietf.org Thu Jun 09 06:04:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgJtx-0004fE-Of; Thu, 09 Jun 2005 06:04:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgJtw-0004ev-8V for megaco@megatron.ietf.org; Thu, 09 Jun 2005 06:04: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 GAA08555 for <megaco@ietf.org>; Thu, 9 Jun 2005 06:04:37 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgKEq-0001xK-9b for megaco@ietf.org; Thu, 09 Jun 2005 06:26:19 -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/ICT TSC MAIL 2005) with ESMTP id j59A3oVa014561; Thu, 9 Jun 2005 12:03:50 +0200 In-Reply-To: <9A64A99CD3F2BD4582BE4FB63FC1F381010D30F8@MAILSERVER> Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs To: Raphael Tryster <raphael@tdsoft.com> X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: <OF2B24150B.3D9763BD-ONC125701B.0035E1E2-C125701B.0037471F@netfr.alcatel.fr> Date: Thu, 9 Jun 2005 12:03:46 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF141 | May 13, 2005) at 06/09/2005 12:03:50 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Content-Transfer-Encoding: quoted-printable Cc: "'megaco@ietf.org'" <megaco@ietf.org> X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control <megaco.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe> List-Post: <mailto:megaco@ietf.org> List-Help: <mailto:megaco-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe> Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org If you mean with "signaling IP@" the IP@ used for H.248 transport then = NO. 1) A H.248 MG (=3D VMG or non-VMG) is denoted by a single H.248 Control= Association (see =A7 F.2/H.248.1). The Control Association is mapped on a "transport connection", in case = of IP dependent on UDP, TCP or SCTP transport. In case of SCTP, you MAY(theoretically) use different IP@s for the "SCT= P multihoming" capability. But there are other realization possibilities = as well. 2) The H.248 Message ID may be IP@-based as well. Both IP@s are firstly= decoupled, but there are concepts (see certain H.248 Profiles), which correlating both. Regards Albrecht ALCATEL = =20 Raphael Tryster = =20 <raphael@tdsoft. To: Albrecht SCHWAR= Z/DE/ALCATEL@ALCATEL, Tamar Nemet =20 com> <tamar.nemet@commatch.co= m> =20 cc: "'megaco@ietf.o= rg'" <megaco@ietf.org> =20 09.06.2005 07:54 Subject: RE: [Megaco] Vi= rtual Media Gateways and amount of Termination IDs =20 = =20 Do you mean that a physical MG might have several different signaling I= P addresses but NOT be divided into multiple virtual MGs? Raphael Tryster -----Original Message----- From: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] Sent: Wednesday, June 08, 2005 7:41 PM To: Tamar Nemet Cc: 'megaco@ietf.org'; Raphael Tryster Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination = IDs Addressing IP interfaces of a H.248 MG is NO rationale for the introduc= tion of VMGs. There are typically other requirements driving for VMG approaches. Even= so, the VMGs may share address space, or use disjoint IP addresses for the diversity of IP applications served by a VoIP MG. This depends on the specific use case and underlying network architecture. So, please not misread =A7 11.1/H.248.1. Rgds, Albrecht ALCATEL Tamar Nemet <tamar.nemet@com To: "'Raphael Tryst= er'" <raphael@tdsoft.com>, Tamar Nemet match.com> <tamar.nemet@commatch.co= m>, "'megaco@ietf.org'" <megaco@ietf.org> Sent by: cc: megaco-bounces@i Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs etf.org 08.06.2005 14:05 Can the SoftSwitch use different FQDNs for virtual media gateways and = not the ip address and port of the physical Media gateway ? Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 3:17 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs They can use different UDP ports. The answer to your second ques= tion is No, but I would also be interested to hear different answers f= rom others. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 12:31 PM To: Raphael Tryster; Tamar Nemet; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Hello raphael, Thanks for your answer. But I can't understand how the SoftSwitch can use multiple ROOTs if the all the Virtual Me= dia Gateways has the same IP address ? Did you see any SoftSwitch that uses the Virtual MediaGatew= ays ? Thanks, Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 1:54 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amou= nt of Termination IDs There is no requirement to artificially split a large= gateway into multiple virtual MGs. You might have ot= her reasons for wanting to split it. For example, there might be different sets of global characteristics tha= t you want to set differently for subsets of your terminations, so you would like to have multiple ROOT= s. Or, you might want different sets of terminations to = be controlled by different soft switches. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.= com] Sent: Wednesday, June 08, 2005 11:22 AM To: 'megaco@ietf.org' Subject: [Megaco] Virtual Media Gateways and am= ount of Termination IDs Hello, I have some questions regarding Virtual media gateway: 1. I have one physical media gateway (with one = IP address). We can define up to 4400 Termination = IDs on this media gateway. Does we have to devide the termination IDs = to some virtual media gateways or we can work with= no virtual media gateway ? 2. Does SoftSwitches uses the Virtual Media Gat= way object? for what ? Thanks, Tamar ______________________________________________= _ Megaco mailing 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 Jun 09 06:47:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgKZP-0004HT-M3; Thu, 09 Jun 2005 06:47:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgKZN-0004HO-GJ for megaco@megatron.ietf.org; Thu, 09 Jun 2005 06:47: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 GAA12164 for <megaco@ietf.org>; Thu, 9 Jun 2005 06:47:26 -0400 (EDT) Received: from [62.90.58.229] (helo=tparelay.telradnetworks.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgKuJ-0003fo-Vq for megaco@ietf.org; Thu, 09 Jun 2005 07:09:09 -0400 Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j59AgjZp025994 for <megaco@ietf.org>; Thu, 9 Jun 2005 13:42:46 +0300 (IDT) Received: from tpa-mail1.Telrad.co.il ([141.226.76.57]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j59Agijq025988; Thu, 9 Jun 2005 13:42:44 +0300 (IDT) Received: by tpa-mail1.telrad.co.il with Internet Mail Service (5.5.2657.72) id <J5NK796C>; Thu, 9 Jun 2005 13:47:44 +0300 Message-ID: <C0F328F4B564A544ADBA98DA8BBE86F1265ED6@tpa-mail1.telrad.co.il> From: Tamar Nemet <tamar.nemet@commatch.com> To: "'Albrecht.Schwarz@alcatel.de'" <Albrecht.Schwarz@alcatel.de>, Raphael Tryster <raphael@tdsoft.com> Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Date: Thu, 9 Jun 2005 13:47:42 +0300 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-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Content-Transfer-Encoding: quoted-printable Cc: "'megaco@ietf.org'" <megaco@ietf.org> X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control <megaco.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe> List-Post: <mailto:megaco@ietf.org> List-Help: <mailto:megaco-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe> Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello Albrecht, Thanks for your answers, BUT I need some more information: If my MG IP address is 10.10.10.8, how many Termination IDs can be = defined on it without using the Virtual MG object ? Thanks, Tamar -----Original Message----- From: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] Sent: Thursday, June 09, 2005 1:04 PM To: Raphael Tryster Cc: 'megaco@ietf.org'; Tamar Nemet Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination = IDs If you mean with "signaling IP@" the IP@ used for H.248 transport then = NO. 1) A H.248 MG (=3D VMG or non-VMG) is denoted by a single H.248 Control Association (see =A7 F.2/H.248.1). The Control Association is mapped on a "transport connection", in case = of IP dependent on UDP, TCP or SCTP transport. In case of SCTP, you MAY(theoretically) use different IP@s for the = "SCTP multihoming" capability. But there are other realization possibilities = as well. 2) The H.248 Message ID may be IP@-based as well. Both IP@s are firstly decoupled, but there are concepts (see certain H.248 Profiles), which correlating both. Regards Albrecht ALCATEL =20 Raphael Tryster <raphael@tdsoft. To: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, Tamar Nemet =20 com> = <tamar.nemet@commatch.com> cc: = "'megaco@ietf.org'" <megaco@ietf.org> =20 09.06.2005 07:54 Subject: RE: [Megaco] = Virtual Media Gateways and amount of Termination IDs =20 =20 Do you mean that a physical MG might have several different signaling = IP addresses but NOT be divided into multiple virtual MGs? Raphael Tryster -----Original Message----- From: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] Sent: Wednesday, June 08, 2005 7:41 PM To: Tamar Nemet Cc: 'megaco@ietf.org'; Raphael Tryster Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination = IDs Addressing IP interfaces of a H.248 MG is NO rationale for the = introduction of VMGs. There are typically other requirements driving for VMG approaches. Even = so, the VMGs may share address space, or use disjoint IP addresses for the diversity of IP applications served by a VoIP MG. This depends on the specific use case and underlying network architecture. So, please not misread =A7 11.1/H.248.1. Rgds, Albrecht ALCATEL Tamar Nemet <tamar.nemet@com To: "'Raphael = Tryster'" <raphael@tdsoft.com>, Tamar Nemet match.com> = <tamar.nemet@commatch.com>, "'megaco@ietf.org'" <megaco@ietf.org> Sent by: cc: megaco-bounces@i Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs etf.org 08.06.2005 14:05 Can the SoftSwitch use different FQDNs for virtual media gateways and = not the ip address and port of the physical Media gateway ? Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 3:17 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs They can use different UDP ports. The answer to your second = question is No, but I would also be interested to hear different answers = from others. Raphael Tryster -----Original Message----- From: Tamar Nemet [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 12:31 PM To: Raphael Tryster; Tamar Nemet; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Hello raphael, Thanks for your answer. But I can't understand how the SoftSwitch can use multiple ROOTs if the all the Virtual = Media Gateways has the same IP address ? Did you see any SoftSwitch that uses the Virtual = MediaGateways ? Thanks, Tamar -----Original Message----- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Wednesday, June 08, 2005 1:54 PM To: 'Tamar Nemet'; 'megaco@ietf.org' Subject: RE: [Megaco] Virtual Media Gateways and = amount of Termination IDs There is no requirement to artificially split a large gateway into multiple virtual MGs. You might have = other reasons for wanting to split it. For example, there might be different sets of global characteristics = that you want to set differently for subsets of your terminations, so you would like to have multiple = ROOTs. Or, you might want different sets of terminations to = be controlled by different soft switches. Raphael Tryster -----Original Message----- From: Tamar Nemet = [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 11:22 AM To: 'megaco@ietf.org' Subject: [Megaco] Virtual Media Gateways and = amount of Termination IDs Hello, I have some questions regarding Virtual media gateway: 1. I have one physical media gateway (with one = IP address). We can define up to 4400 Termination = IDs on this media gateway. Does we have to devide the termination IDs = to some virtual media gateways or we can work with = no virtual media gateway ? 2. Does SoftSwitches uses the Virtual Media = Gatway object? for what ? Thanks, Tamar = _______________________________________________ Megaco mailing 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 Jun 09 09:13:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgMqg-0003D8-Mo; Thu, 09 Jun 2005 09:13:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgMqa-0003Ce-W3 for megaco@megatron.ietf.org; Thu, 09 Jun 2005 09:13:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27215 for <megaco@ietf.org>; Thu, 9 Jun 2005 09:13:23 -0400 (EDT) Received: from mercurio.italtel.it ([138.132.53.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgNC3-0001hM-1e for megaco@ietf.org; Thu, 09 Jun 2005 09:35:36 -0400 Received: from mercurio.italtel.it (localhost [127.0.0.1]) by mercurio.italtel.it (8.12.11/8.12.11) with ESMTP id j59DD5sH012752 for <megaco@ietf.org>; Thu, 9 Jun 2005 15:13:05 +0200 (MEST) Received: from IMADS2.milano.italtel.it (imads2.milano.italtel.it [138.132.90.31]) by mercurio.italtel.it (8.12.11/8.12.11) with ESMTP id j59DD59k012749 for <megaco@ietf.org>; Thu, 9 Jun 2005 15:13:05 +0200 (MEST) X-Spam-Filter: made by mercurio.italtel.it Received: by IMADS2.milano.italtel.it with Internet Mail Service (5.5.2657.72) id <J7BDZAKA>; Thu, 9 Jun 2005 15:13:04 +0200 Message-ID: <8E6DA0ECC9F8EE4483CBF31602B1537E81D316@BESONE.corp.dom> From: Contardi Angelo <Angelo.Contardi@italtel.it> To: "Megaco IETF - Mail List (E-mail)" <megaco@ietf.org> Date: Thu, 9 Jun 2005 15:12:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.7 (++) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a Subject: [Megaco] Ambiguities, Errors and forgotten things in Packages Description X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control <megaco.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe> List-Post: <mailto:megaco@ietf.org> List-Help: <mailto:megaco-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1997373009==" 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. --===============1997373009== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56CF4.E9DF7600" 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_01C56CF4.E9DF7600 Content-Type: text/plain; charset="iso-8859-1" Hello, During the reading of H.248.1 packages description i have encountered many difficulties i try to explain in this mail. I hope someone can clarify my doubts. Furthermore, if any of my considerations is valid, i hope will be taken in count in the new "incoming" H.248.1 V3 ITU specification. The V2 specification probably is "too stable" to be modified :-) REFERENCE SPECIFICATION: ------------------------ ITU H.248.1 V2 Corrigendum 1 (i think the last one approved by ITU). PREFACE: -------- The Textual (ABNF) coding of VALUEs allows ONE of the following forms: * A sequence of ONE or MORE SafeChar (let me say SafeChar form). * A quotedString form that is a DOUBLE QUOTED string of ZERO or MORE ASCII chars, with some exceptions (DOUBLE QUOTES, non printable chars, C language string terminator '\0' (0x00), etc.). Of the two forms, the quotedString form is the more general one. Errors (?): ----------- 1) In the textual coding i think it's impossible to code ANY UTF-8 char (RFC 3629) because of the FIRST byte of an UTF-8 char may be ANY ASCII char in the range 0x00-0x7E and, for instance, the ASCII 0x01-0x07, that are not allowed in ABNF form of VALUE. Furthermore, UTF-8 chars "greater than 0x7E", need ASCII chars in the range 0x80-0xFF (not ALL), not allowed in the ABNF form of VALUE. If my assertion is true, in the packages description (paragraphs 12.x.x of H.248.1 V2 Corrigendum 1), the TYPEs of VALUEs (i suppose they should be valid for BOTH ASN.1 and ABNF coding): - String: can't be ANY UTF-8 string but JUST an ASCII string with the limitation of the quotedString !!! So it can't include '"', '\0', etc. - Character: can't be ANY UTF-8 for the same above reasons and with the same limitation. In other words, String and Character types may be JUST quotedString. Otherwise, to code UTF-8 chars with an ASCII string it's necessary to extend the quotedString definition allowing ANY ASCII, except '\0' and '"'. 2) Due probably to a "copy & paste" operation of the "Octet String" references, the references o Sub-List type in paragraphs 12.1.2, 12.1.5 and 12.2 are probably wrong and should be: "The encoding of Sub-lists is specified in Annex A and B.2 (alternativeValue description)." 3) The Integer and Double types of Properties and Parameters are BOTH SIGNED (paragraphs 12.x.x of Corrigendum), while in ABNF description of VALUEs ("top" ANNEX B.2 comment) there is the possibility of Unsigned Integer TOO. Why ? Note that from the "implementor" point of view, Integer and Unsigned Integer (on 32 Bits) aren't the same thing (different range: the sign "eat" on bit). Ambiguities: ------------ 1) About the Sub-List type of a package Property/Parameter: - Sub-List is not "strictly speaking" a type but a Sub-set of Items, ALL of a specified Type (Integer, Double, etc.). - The term Sub-List appears just in the descriptive paragraphs of Packages (12.x.x) but NOT in packages definitions (ANNEX E) in witch appears JUST List (see tonedet ad tonegen base packages). - Paragraph 12.3 is titled "Lists", but describe how to register enumerated types to IANA. - A Sub-List may assume 3 forms (in BOTH ASN.1 and ABNF implementations): * An OR sublist of elements * An AND sublist of elements * A RANGE sublist of elements (AND or OR ?) So, to specify COMPLETELY a VALUE of a Parameter/Property of "type" Sub-list, somewhere in the package one should write which relation, AND or OR, "ties" the Sub-list VALUEs. Furthermore, if it is reasonable to allow packages that MAY admit BOTH AND or OR relations, the syntax of the "RANGE" is not suited to carry the AND or OR "relation attribute". I think in some applications the AND or OR attribute may have, in different times, sense. For instance, a modem tone detector (when i was jung i work with modems :-), can be programmed as a DTMF tone detector (so it detects a COUPLE of SINGLE tones at the same time (relation AND)) or as a "multy" (single) tone detector, capable to detect toneA OR toneB ...(relation OR)). My proposal: * In a package description, specify the type of the values as usual and do not include Sub-List as a type but ADD a the new descriptive "item": Sub-Set: None/AND/OR or BOTH * Reference the Sub-Set with the string "Sub-Set" everywhere in the specification, both in the Packages definitions and in the syntax description (ASN.1 and ABNF notation comments, to indicate how the Sub-Set is implemented). 2) About Octet String ABNF representation: - The octet string ABNF representation is described in ANNEX B.3 in a way i think is not so clear: "...This octet encoding SHOULD be used when encoding octet strings in the text version of the protocol..." I think it means, more explicitly: "The ASCII character string corresponding to this octet encoding SHOULD be used when encoding octet strings in the text version of the protocol." So, for instance, the Hex Coding "0x90" correspond to the string "90". - Furthermore i think ANNEX B.4 may be deleted because it just contribute to confuse ideas. It seems it says "text coding of octet string must be terminated with a CARRIAGE RETURN", not allowed in the ABNF form of VALUE. Things left out (forgotten): ---------------------------- 1) The ASN.1 implementation of VALUE allow a NULL list of VALUEs that means CHOOSE: the VALUE may be choosen by MG. How CHOOSE is implemented in ABNF syntax ? My Proposal: * Non conservative: Change the syntax of alternativeValue: VALUE *(COMMA VALUE) become [VALUE *(COMMA VALUE)] It may introduce "parser ambiguities". * Conservative (as i have already implemented :-): If parmValue is EQUAL to an EMPTY QUOTED STRING, the parameter VALUE may be choose by MG. Note that THIS is done at PARSER level so the TYPE of the VALE (semantic level) doesn't affect the way an EMPTY VALUE of ANY TYPE is represented (""). I think the "semantic" distinction made in paragraph 7.2.6: "For property and parameter values of type string, character or octet string, the MG shall return an empty value. For the text encoding, strings and characters return an empty quotedString construct, while octet strings return NUL (0x00)." is NOT necessary at ALL and NOT applicable to ALL allowed values types. Furthermore i don't understand what it means with: "... while octet strings return NUL (0x00)" Does it means the text Octect Coding of 0x00, thus the string "00" (not quoted)? The ASCII '\0' (0x00) is NOT allowed in ABNF VALUEs forms. 2) When describing the fact that a package may be an extension of an other it should be stated that the "added Items Ids can't assume ANY of the (already existing) base package Items Ids values". This to ensure the the fact that any Item of "extended package" (UNION of the base and added ones), must be identified in an unambiguous mode. Best Regards o o o o o o o . . . ___________________________________ o _____ || Angelo Contardi | .][__n_n_|DD[ ====_____ | angelo.contardi@italtel.it | >(________|__|_[_________]_|________________________________| _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o` ------_=_NextPart_001_01C56CF4.E9DF7600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+QW1iaWd1 aXRpZXMsIEVycm9ycyBhbmQgZm9yZ290dGVuIHRoaW5ncyBpbiBQYWNrYWdlcyBEZXNjcmlwdGlv bjwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPkhlbGxvLDwvRk9O VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkR1cmluZyB0aGUgcmVhZGluZyBvZiBILjI0OC4x IHBhY2thZ2VzIGRlc2NyaXB0aW9uIGkgaGF2ZSBlbmNvdW50ZXJlZCA8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPm1hbnkgZGlmZmljdWx0aWVzIGkgdHJ5IHRvIGV4cGxhaW4gaW4gdGhpcyBtYWls LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkkgaG9wZSBzb21lb25lIGNhbiBjbGFy aWZ5IG15IGRvdWJ0cy4gRnVydGhlcm1vcmUsIGlmIGFueSBvZiBteSBjb25zaWRlcmF0aW9uczwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+aXMgdmFsaWQsIGkgaG9wZSB3aWxsIGJlIHRha2VuIGlu IGNvdW50IGluIHRoZSBuZXcgJnF1b3Q7aW5jb21pbmcmcXVvdDsgSC4yNDguMSBWMyBJVFU8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPnNwZWNpZmljYXRpb24uIFRoZSBWMiBzcGVjaWZpY2F0aW9u IHByb2JhYmx5IGlzICZxdW90O3RvbyBzdGFibGUmcXVvdDsgdG8gYmUgbW9kaWZpZWQgOi0pPC9G T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+UkVGRVJFTkNFIFNQRUNJRklDQVRJT046PC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0ZPTlQ+DQo8 L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JVFUgSC4yNDguMSBWMiBDb3JyaWdlbmR1bSAxIChpIHRo aW5rIHRoZSBsYXN0IG9uZSBhcHByb3ZlZCBieSBJVFUpLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPlBSRUZBQ0U6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4tLS0tLS0tLTwvRk9O VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlRoZSBUZXh0dWFsIChBQk5GKSBjb2Rpbmcgb2Yg VkFMVUVzIGFsbG93cyBPTkUgb2YgdGhlIGZvbGxvd2luZyBmb3Jtczo8L0ZPTlQ+DQo8L1A+DQoN CjxQPjxGT05UIFNJWkU9Mj4qIEEgc2VxdWVuY2Ugb2YgT05FIG9yIE1PUkUgU2FmZUNoYXIgKGxl dCBtZSBzYXkgU2FmZUNoYXIgZm9ybSkuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+ KiBBIHF1b3RlZFN0cmluZyBmb3JtIHRoYXQgaXMgYSBET1VCTEUgUVVPVEVEIHN0cmluZyBvZiBa RVJPIG9yIE1PUkUgQVNDSUkgY2hhcnMsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsg d2l0aCBzb21lIGV4Y2VwdGlvbnMgKERPVUJMRSBRVU9URVMsIG5vbiBwcmludGFibGUgY2hhcnMs IEMgbGFuZ3VhZ2Ugc3RyaW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsgdGVybWlu YXRvciAnXDAnICgweDAwKSwgZXRjLikuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+ T2YgdGhlIHR3byBmb3JtcywgdGhlIHF1b3RlZFN0cmluZyBmb3JtIGlzIHRoZSBtb3JlIGdlbmVy YWwgb25lLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkVycm9ycyAoPyk6PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4tLS0tLS0tLS0tLTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yPjEpIEluIHRoZSB0ZXh0dWFsIGNvZGluZyBpIHRoaW5rIGl0J3MgaW1wb3NzaWJsZSB0 byBjb2RlIEFOWSBVVEYtOCBjaGFyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJz cDsgKFJGQyAzNjI5KSBiZWNhdXNlIG9mIHRoZSBGSVJTVCBieXRlIG9mIGFuIFVURi04IGNoYXIg bWF5IGJlIEFOWSBBU0NJSTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IGNo YXIgaW4gdGhlIHJhbmdlIDB4MDAtMHg3RSBhbmQsIGZvciBpbnN0YW5jZSwgdGhlIEFTQ0lJIDB4 MDEtMHgwNywgdGhhdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IGFyZSBu b3QgYWxsb3dlZCBpbiBBQk5GIGZvcm0gb2YgVkFMVUUuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mbmJzcDsmbmJzcDsgRnVydGhlcm1vcmUsIFVURi04IGNoYXJzICZxdW90O2dyZWF0ZXIgdGhh biAweDdFJnF1b3Q7LCBuZWVkIEFTQ0lJIGNoYXJzIGluIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jm5ic3A7Jm5ic3A7IHJhbmdlIDB4ODAtMHhGRiAobm90IEFMTCksIG5vdCBhbGxvd2Vk IGluIHRoZSBBQk5GIGZvcm0gb2YgVkFMVUUuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJz cDsmbmJzcDsgSWYgbXkgYXNzZXJ0aW9uIGlzIHRydWUsIGluIHRoZSBwYWNrYWdlcyBkZXNjcmlw dGlvbiAocGFyYWdyYXBocyAxMi54Lnggb2Y8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNw OyZuYnNwOyBILjI0OC4xIFYyIENvcnJpZ2VuZHVtIDEpLCB0aGUgVFlQRXMgb2YgVkFMVUVzIChp IHN1cHBvc2UgdGhleSBzaG91bGQgYmUgdmFsaWQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZu YnNwOyZuYnNwOyBmb3IgQk9USCBBU04uMSBhbmQgQUJORiBjb2RpbmcpOjwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7 Jm5ic3A7IC0gU3RyaW5nOiZuYnNwOyZuYnNwOyZuYnNwOyBjYW4ndCBiZSBBTlkgVVRGLTggc3Ry aW5nIGJ1dCBKVVNUIGFuIEFTQ0lJIHN0cmluZyB3aXRoIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpbWl0YXRpb24gb2YgdGhl IHF1b3RlZFN0cmluZyAhISEgU28gaXQgY2FuJ3QgaW5jbHVkZSAnJnF1b3Q7Jyw8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAnXDAnLCBl dGMuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IC0gQ2hhcmFj dGVyOiBjYW4ndCBiZSBBTlkgVVRGLTggZm9yIHRoZSBzYW1lIGFib3ZlIHJlYXNvbnMgYW5kIHdp dGggdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgc2FtZSBsaW1pdGF0aW9uLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5i c3A7Jm5ic3A7IEluIG90aGVyIHdvcmRzLCBTdHJpbmcgYW5kIENoYXJhY3RlciB0eXBlcyBtYXkg YmUgSlVTVCBxdW90ZWRTdHJpbmcuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJz cDsgT3RoZXJ3aXNlLCB0byBjb2RlIFVURi04IGNoYXJzIHdpdGggYW4gQVNDSUkgc3RyaW5nIGl0 J3MgbmVjZXNzYXJ5IHRvIGV4dGVuZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5i c3A7IHRoZSBxdW90ZWRTdHJpbmcgZGVmaW5pdGlvbiBhbGxvd2luZyBBTlkgQVNDSUksIGV4Y2Vw dCAnXDAnIGFuZCAnJnF1b3Q7Jy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4yKSBE dWUgcHJvYmFibHkgdG8gYSAmcXVvdDtjb3B5ICZhbXA7IHBhc3RlJnF1b3Q7IG9wZXJhdGlvbiBv ZiB0aGUgJnF1b3Q7T2N0ZXQgU3RyaW5nJnF1b3Q7IHJlZmVyZW5jZXMsPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsgdGhlIHJlZmVyZW5jZXMgbyBTdWItTGlzdCB0eXBlIGlu IHBhcmFncmFwaHMgMTIuMS4yLCAxMi4xLjUgYW5kIDEyLjIgYXJlPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mbmJzcDsmbmJzcDsgcHJvYmFibHkgd3JvbmcgYW5kIHNob3VsZCBiZTo8L0ZPTlQ+ DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VGhlIGVu Y29kaW5nIG9mIFN1Yi1saXN0cyBpcyBzcGVjaWZpZWQgaW4gQW5uZXggQSBhbmQgQi4yIChhbHRl cm5hdGl2ZVZhbHVlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZGVzY3JpcHRpb24pLiZxdW90OzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y PjMpIFRoZSBJbnRlZ2VyIGFuZCBEb3VibGUgdHlwZXMgb2YgUHJvcGVydGllcyBhbmQgUGFyYW1l dGVycyBhcmUgQk9USDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IFNJR05F RCAocGFyYWdyYXBocyAxMi54Lnggb2YgQ29ycmlnZW5kdW0pLCB3aGlsZSBpbiBBQk5GIGRlc2Ny aXB0aW9uIG9mPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsgVkFMVUVzICgm cXVvdDt0b3AmcXVvdDsgQU5ORVggQi4yIGNvbW1lbnQpIHRoZXJlIGlzIHRoZSBwb3NzaWJpbGl0 eSBvZiBVbnNpZ25lZCBJbnRlZ2VyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJz cDsgVE9PLiBXaHkgPyBOb3RlIHRoYXQgZnJvbSB0aGUgJnF1b3Q7aW1wbGVtZW50b3ImcXVvdDsg cG9pbnQgb2YgdmlldywgSW50ZWdlciBhbmQgVW5zaWduZWQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZuYnNwOyZuYnNwOyBJbnRlZ2VyIChvbiAzMiBCaXRzKSBhcmVuJ3QgdGhlIHNhbWUgdGhp bmcgKGRpZmZlcmVudCByYW5nZTogdGhlIHNpZ24gJnF1b3Q7ZWF0JnF1b3Q7PC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsgb24gYml0KS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj5BbWJpZ3VpdGllczo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPi0tLS0tLS0t LS0tLTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPjEpIEFib3V0IHRoZSBTdWItTGlz dCB0eXBlIG9mIGEgcGFja2FnZSBQcm9wZXJ0eS9QYXJhbWV0ZXI6PC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IC0gU3ViLUxpc3QgaXMgbm90ICZxdW90O3N0cmlj dGx5IHNwZWFraW5nJnF1b3Q7IGEgdHlwZSBidXQgYSBTdWItc2V0IG9mIEl0ZW1zLCBBTEw8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZiBhIHNwZWNp ZmllZCBUeXBlIChJbnRlZ2VyLCBEb3VibGUsIGV0Yy4pLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPiZuYnNwOyZuYnNwOyAtIFRoZSB0ZXJtIFN1Yi1MaXN0IGFwcGVhcnMganVzdCBp biB0aGUgZGVzY3JpcHRpdmUgcGFyYWdyYXBocyBvZiBQYWNrYWdlczwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICgxMi54LngpIGJ1dCBOT1QgaW4gcGFj a2FnZXMgZGVmaW5pdGlvbnMgKEFOTkVYIEUpIGluIHdpdGNoIGFwcGVhcnMgSlVTVDwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExpc3QgKHNlZSB0b25l ZGV0IGFkIHRvbmVnZW4gYmFzZSBwYWNrYWdlcykuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m bmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsgLSBQYXJh Z3JhcGggMTIuMyBpcyB0aXRsZWQgJnF1b3Q7TGlzdHMmcXVvdDssIGJ1dCBkZXNjcmliZSBob3cg dG8gcmVnaXN0ZXIgZW51bWVyYXRlZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHR5cGVzIHRvIElBTkEuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m bmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsgLSBBIFN1 Yi1MaXN0IG1heSBhc3N1bWUgMyBmb3JtcyAoaW4gQk9USCBBU04uMSBhbmQgQUJORiBpbXBsZW1l bnRhdGlvbnMpOjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAqIEFuIE9SJm5ic3A7Jm5ic3A7Jm5ic3A7IHN1Ymxpc3Qgb2YgZWxlbWVudHM8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqIEFuIEFO RCZuYnNwOyZuYnNwOyBzdWJsaXN0IG9mIGVsZW1lbnRzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiBBJm5ic3A7IFJBTkdFIHN1Ymxpc3Qgb2YgZWxl bWVudHMgKEFORCBvciBPUiA/KTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFNvLCB0byBzcGVjaWZ5IENPTVBMRVRFTFkgYSBWQUxVRSBvZiBhIFBhcmFtZXRlci9Q cm9wZXJ0eSBvZiAmcXVvdDt0eXBlJnF1b3Q7IFN1Yi1saXN0LDwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNvbWV3aGVyZSBpbiB0aGUgcGFja2FnZSBv bmUgc2hvdWxkIHdyaXRlIHdoaWNoIHJlbGF0aW9uLCBBTkQgb3IgT1IsICZxdW90O3RpZXMmcXVv dDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUg U3ViLWxpc3QgVkFMVUVzLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEZ1cnRoZXJtb3JlLCBpZiBpdCBpcyByZWFzb25hYmxlIHRvIGFsbG93IHBhY2thZ2VzIHRo YXQgTUFZIGFkbWl0IEJPVEg8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBBTkQgb3IgT1IgcmVsYXRpb25zLCB0aGUgc3ludGF4IG9mIHRoZSAmcXVvdDtS QU5HRSZxdW90OyBpcyBub3Qgc3VpdGVkIHRvIGNhcnJ5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIEFORCBvciBPUiAmcXVvdDtyZWxhdGlvbiBh dHRyaWJ1dGUmcXVvdDsuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSSB0aGluayBpbiBzb21lIGFwcGxpY2F0aW9ucyB0aGUgQU5EIG9yIE9SIGF0dHJp YnV0ZSBtYXkgaGF2ZSwgaW4gZGlmZmVyZW50PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdGltZXMsIHNlbnNlLiBGb3IgaW5zdGFuY2UsIGEgbW9kZW0g dG9uZSBkZXRlY3RvciAod2hlbiBpIHdhcyBqdW5nIGkgd29yazwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpdGggbW9kZW1zIDotKSwgY2FuIGJlIHBy b2dyYW1tZWQgYXMgYSBEVE1GIHRvbmUgZGV0ZWN0b3IgKHNvIGl0IGRldGVjdHM8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhIENPVVBMRSBvZiBTSU5H TEUgdG9uZXMgYXQgdGhlIHNhbWUgdGltZSAocmVsYXRpb24gQU5EKSkgb3IgYXMgYSAmcXVvdDtt dWx0eSZxdW90OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IChzaW5nbGUpIHRvbmUgZGV0ZWN0b3IsIGNhcGFibGUgdG8gZGV0ZWN0IHRvbmVBIE9SIHRv bmVCIC4uLihyZWxhdGlvbiBPUikpLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZu YnNwOyZuYnNwOyBNeSBwcm9wb3NhbDo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZu YnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyAqIEluIGEgcGFja2Fn ZSBkZXNjcmlwdGlvbiwgc3BlY2lmeSB0aGUgdHlwZSBvZiB0aGUgdmFsdWVzIGFzIHVzdWFsIGFu ZCBkbzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5v dCBpbmNsdWRlIFN1Yi1MaXN0IGFzIGEgdHlwZSBidXQgQUREIGEgdGhlIG5ldyBkZXNjcmlwdGl2 ZSAmcXVvdDtpdGVtJnF1b3Q7OjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7 IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN1Yi1TZXQ6IE5vbmUvQU5EL09S IG9yIEJPVEg8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyAqIFJlZmVyZW5j ZSB0aGUgU3ViLVNldCB3aXRoIHRoZSBzdHJpbmcgJnF1b3Q7U3ViLVNldCZxdW90OyBldmVyeXdo ZXJlIGluIHRoZSBzcGVjaWZpY2F0aW9uLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvdGggaW4gdGhlIFBhY2thZ2VzIGRlZmluaXRpb25zIGFuZCBp biB0aGUgc3ludGF4IGRlc2NyaXB0aW9uIChBU04uMSBhbmQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBQk5GIG5vdGF0aW9uIGNvbW1lbnRzLCB0byBp bmRpY2F0ZSBob3cgdGhlIFN1Yi1TZXQgaXMgaW1wbGVtZW50ZWQpLjwvRk9OVD4NCjwvUD4NCg0K PFA+PEZPTlQgU0laRT0yPjIpIEFib3V0IE9jdGV0IFN0cmluZyBBQk5GIHJlcHJlc2VudGF0aW9u OjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyAtIFRoZSBvY3Rl dCBzdHJpbmcgQUJORiByZXByZXNlbnRhdGlvbiBpcyBkZXNjcmliZWQgaW4gQU5ORVggQi4zIGlu IGEgd2F5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg aSB0aGluayBpcyBub3Qgc28gY2xlYXI6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJnF1b3Q7Li4uVGhpcyBvY3RldCBlbmNvZGluZyBTSE9VTEQgYmUgdXNlZCB3 aGVuIGVuY29kaW5nIG9jdGV0IHN0cmluZ3MgaW4gdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGV4dCB2ZXJzaW9uIG9mIHRoZSBwcm90 b2NvbC4uLiZxdW90OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEkgdGhpbmsgaXQgbWVhbnMsIG1vcmUgZXhwbGljaXRseTogPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VGhlIEFTQ0lJIGNoYXJhY3RlciBz dHJpbmcgY29ycmVzcG9uZGluZyB0byB0aGlzIG9jdGV0IGVuY29kaW5nIFNIT1VMRDwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIHVzZWQg d2hlbiBlbmNvZGluZyBvY3RldCBzdHJpbmdzIGluIHRoZSB0ZXh0IHZlcnNpb24gb2YgdGhlIHBy b3RvY29sLiZxdW90OzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBTbywgZm9yIGluc3RhbmNlLCB0aGUgSGV4IENvZGluZyAmcXVvdDsweDkw JnF1b3Q7IGNvcnJlc3BvbmQgdG8gdGhlIHN0cmluZyAmcXVvdDs5MCZxdW90Oy4mbmJzcDsmbmJz cDsgPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IC0gRnVydGhl cm1vcmUgaSB0aGluayBBTk5FWCBCLjQgbWF5IGJlIGRlbGV0ZWQgYmVjYXVzZSBpdCBqdXN0IGNv bnRyaWJ1dGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB0byBjb25mdXNlIGlkZWFzLiBJdCBzZWVtcyBpdCBzYXlzICZxdW90O3RleHQgY29kaW5nIG9m IG9jdGV0IHN0cmluZyBtdXN0IGJlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdGVybWluYXRlZCB3aXRoIGEgQ0FSUklBR0UgUkVUVVJOJnF1b3Q7LCBu b3QgYWxsb3dlZCBpbiB0aGUgQUJORiBmb3JtIG9mIFZBTFVFLjwvRk9OVD4NCjwvUD4NCg0KPFA+ PEZPTlQgU0laRT0yPlRoaW5ncyBsZWZ0IG91dCAoZm9yZ290dGVuKTo8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0ZPTlQ+DQo8L1A+DQoNCjxQ PjxGT05UIFNJWkU9Mj4xKSBUaGUgQVNOLjEgaW1wbGVtZW50YXRpb24gb2YgVkFMVUUgYWxsb3cg YSBOVUxMIGxpc3Qgb2YgVkFMVUVzIHRoYXQgbWVhbnM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZuYnNwOyZuYnNwOyBDSE9PU0U6IHRoZSBWQUxVRSBtYXkgYmUgY2hvb3NlbiBieSBNRy4gSG93 IENIT09TRSBpcyBpbXBsZW1lbnRlZCBpbiBBQk5GIHN5bnRheCA/PC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJz cDsgTXkgUHJvcG9zYWw6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsgPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsgKiBOb24gY29uc2VydmF0aXZlOiBD aGFuZ2UgdGhlIHN5bnRheCBvZiBhbHRlcm5hdGl2ZVZhbHVlOjwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFZBTFVFICooQ09NTUEg VkFMVUUpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlY29tZSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBbVkFMVUUgKihDT01NQSBWQUxVRSldIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEl0IG1heSBpbnRyb2R1Y2UgJnF1b3Q7cGFyc2VyIGFtYmlndWl0aWVzJnF1b3Q7 LiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZuYnNwOyZuYnNwOyAqIENvbnNlcnZhdGl2ZSAoYXMgaSBoYXZlIGFscmVhZHkg aW1wbGVtZW50ZWQgOi0pOjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHBhcm1W YWx1ZSBpcyBFUVVBTCB0byBhbiBFTVBUWSBRVU9URUQgU1RSSU5HLCB0aGUgcGFyYW1ldGVyIFZB TFVFIG1heTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGJlIGNob29zZSBieSBNRy4gTm90ZSB0aGF0IFRISVMgaXMgZG9uZSBhdCBQQVJTRVIgbGV2ZWwg c28gdGhlIFRZUEUgb2Y8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB0aGUgVkFMRSAoc2VtYW50aWMgbGV2ZWwpIGRvZXNuJ3QgYWZmZWN0IHRoZSB3YXkg YW4gRU1QVFkgVkFMVUUgb2YgQU5ZIFRZUEU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBpcyByZXByZXNlbnRlZCAoJnF1b3Q7JnF1b3Q7KS48L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIHRoaW5rIHRoZSAm cXVvdDtzZW1hbnRpYyZxdW90OyBkaXN0aW5jdGlvbiBtYWRlIGluIHBhcmFncmFwaCA3LjIuNjo8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtGb3IgcHJv cGVydHkgYW5kIHBhcmFtZXRlciB2YWx1ZXMgb2YgdHlwZSBzdHJpbmcsIGNoYXJhY3RlciBvciBv Y3RldCBzdHJpbmcsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgdGhlIE1HIHNoYWxsIHJldHVybiBhbiBlbXB0eSB2YWx1ZS48L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGb3IgdGhlIHRl eHQgZW5jb2RpbmcsIHN0cmluZ3MgYW5kIGNoYXJhY3RlcnMgcmV0dXJuIGFuIGVtcHR5IHF1b3Rl ZFN0cmluZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGNvbnN0cnVjdCwgd2hpbGUgb2N0ZXQgc3RyaW5ncyByZXR1cm4gTlVMICgweDAwKS4m cXVvdDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpcyBOT1QgbmVjZXNzYXJ5IGF0 IEFMTCBhbmQgTk9UIGFwcGxpY2FibGUgdG8gQUxMIGFsbG93ZWQgdmFsdWVzIHR5cGVzLjwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZ1cnRoZXJtb3Jl IGkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IGl0IG1lYW5zIHdpdGg6PC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 Li4uIHdoaWxlIG9jdGV0IHN0cmluZ3MgcmV0dXJuIE5VTCAoMHgwMCkmcXVvdDs8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBEb2VzIGl0IG1lYW5zIHRoZSB0ZXh0IE9jdGVjdCBDb2Rpbmcgb2YgMHgwMCwgdGh1cyB0aGUg c3RyaW5nICZxdW90OzAwJnF1b3Q7IChub3QgcXVvdGVkKT88L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgQVNDSUkgJ1wwJyAoMHgwMCkgaXMgTk9U IGFsbG93ZWQgaW4gQUJORiBWQUxVRXMgZm9ybXMuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBT SVpFPTI+MikgV2hlbiBkZXNjcmliaW5nIHRoZSBmYWN0IHRoYXQgYSBwYWNrYWdlIG1heSBiZSBh biBleHRlbnNpb24gb2YgYW4gb3RoZXIgaXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNw OyZuYnNwOyBzaG91bGQgYmUgc3RhdGVkIHRoYXQgdGhlICZxdW90O2FkZGVkIEl0ZW1zIElkcyBj YW4ndCBhc3N1bWUgQU5ZIG9mIHRoZSAoYWxyZWFkeTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jm5ic3A7Jm5ic3A7IGV4aXN0aW5nKSBiYXNlIHBhY2thZ2UgSXRlbXMgSWRzIHZhbHVlcyZxdW90 Oy4gVGhpcyB0byBlbnN1cmUgdGhlIHRoZSBmYWN0IHRoYXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZuYnNwOyZuYnNwOyBhbnkgSXRlbSBvZiAmcXVvdDtleHRlbmRlZCBwYWNrYWdlJnF1b3Q7 IChVTklPTiBvZiB0aGUgYmFzZSBhbmQgYWRkZWQgb25lcyksIG11c3QgYmU8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyBpZGVudGlmaWVkIGluIGFuIHVuYW1iaWd1b3VzIG1v ZGUuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QmVzdCBSZWdhcmRzPC9GT05UPg0K PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG8gbyBvIG8gbyBvIG8gLiAuIC4mbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IF9fX19fJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHx8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEFuZ2VsbyBDb250YXJkaSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLl1bX19uX25ffEREWyZuYnNwOyA9PT09X19fX18mbmJzcDsgfCZuYnNwOyZu YnNwOyBhbmdlbG8uY29udGFyZGlAaXRhbHRlbC5pdCZuYnNwOyZuYnNwOyB8PC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyhfX19fX19fX3xfX3xf W19fX19fX19fX11ffF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19ffDwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF8vb28gT09PT08gb29gJm5i c3A7IG9vbyZuYnNwOyZuYnNwOyBvb28mbmJzcDsgJ28hbyFvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8hbyFvYDwv Rk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C56CF4.E9DF7600-- --===============1997373009== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1997373009==-- From megaco-bounces@ietf.org Thu Jun 09 09:32:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgN90-0006S3-1v; Thu, 09 Jun 2005 09:32:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgN8x-0006Rv-PM for megaco@megatron.ietf.org; Thu, 09 Jun 2005 09:32:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29477 for <megaco@ietf.org>; Thu, 9 Jun 2005 09:32:21 -0400 (EDT) Received: from [62.90.58.229] (helo=tparelay.telradnetworks.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgNUP-0003NJ-Bd for megaco@ietf.org; Thu, 09 Jun 2005 09:54:34 -0400 Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j59DS8Kx018485 for <megaco@ietf.org>; Thu, 9 Jun 2005 16:28:09 +0300 (IDT) Received: from mail3.telradnetworks.co.il ([141.226.76.66]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j59DS7RZ018461; Thu, 9 Jun 2005 16:28:07 +0300 (IDT) Received: by mail3.telrad.co.il with Internet Mail Service (5.5.2657.72) id <LWK2C3B3>; Thu, 9 Jun 2005 16:34:12 +0300 Message-ID: <7388365BE5E4D411A3810002A509155804866959@mail3.telrad.co.il> From: Michael Putter <michael.putter@telrad.co.il> To: "'Kevin Boyle'" <kboyle@nortel.com>, Tamar Nemet <tamar.nemet@commatch.com>, "'megaco@ietf.org'" <megaco@ietf.org> Subject: RE: [Megaco] Dial Plan. Date: Thu, 9 Jun 2005 16:34:12 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control <megaco.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe> List-Post: <mailto:megaco@ietf.org> List-Help: <mailto:megaco-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe> Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello, In continue to the question. Can DigitMap be activated for the ROOT termination like other events by Event descriptor with digit map completion event and then the digit map will be active for a future call unless new Event descriptor with digit map completion event will be applied for the call? I have not found restriction in the standard for that scenario, but is it real? Do somebody use this way of digit map activation? Thanks, Michael. -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On Behalf Of Kevin Boyle Sent: Thursday, June 09, 2005 12:02 AM To: Tamar Nemet; 'megaco@ietf.org' Subject: RE: [Megaco] Dial Plan. MGs don't generally know about "dial plans". They are told to collect digits, through any of a number of means, and they report them. The MGC is responsible for translating the reported digits by applying the local dial plan. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Tamar Nemet Sent: Wednesday, June 08, 2005 5:28 AM To: 'megaco@ietf.org' Subject: [Megaco] Dial Plan. Hello, Do you know how SoftSwitches activate the dial plan ? Does they do it per call or they send an activation on the ROOT termination ? Thanks, Tamar _______________________________________________ Megaco mailing 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 Jun 09 10:42:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgOF2-00009a-Sb; Thu, 09 Jun 2005 10:42:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgNuC-0002uP-HS for megaco@megatron.ietf.org; Thu, 09 Jun 2005 10:21:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05778 for <megaco@ietf.org>; Thu, 9 Jun 2005 10:21:10 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgOFg-0005xj-35 for megaco@ietf.org; Thu, 09 Jun 2005 10:43:24 -0400 Received: from ma8117exch002u.wins.lucent.com (h152-148-89-177.lucent.com [152.148.89.177]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j59EKx3Q028637; Thu, 9 Jun 2005 09:21:00 -0500 (CDT) Received: by ma8117exch002u.inse.lucent.com with Internet Mail Service (5.5.2657.72) id <KMXVQMWP>; Thu, 9 Jun 2005 10:20:59 -0400 Message-ID: <4F9DBE266768DC46A1F17E875D3716410ED596AE@ma8117exch002u.inse.lucent.com> From: "Rutter, Carlton (Carlton)" <crutter@lucent.com> To: "'Tamar Nemet'" <tamar.nemet@commatch.com>, "'Albrecht.Schwarz@alcatel.de'" <Albrecht.Schwarz@alcatel.de>, Raphael Tryster <raphael@tdsoft.com> Subject: RE: [Megaco] Virtual Media Gateways and amount of Termination IDs Date: Thu, 9 Jun 2005 10:20:58 -0400 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-Spam-Score: 2.2 (++) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 09 Jun 2005 10:42:43 -0400 Cc: "'megaco@ietf.org'" <megaco@ietf.org> X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control <megaco.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe> List-Post: <mailto:megaco@ietf.org> List-Help: <mailto:megaco-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe> Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Tamar, There is no real limit on the MG. A high-density MG can have 40,000+ terminations. As Kevin stated you could partitioned the control=20 of the high-density MG via VMGs(if supported on the MG) by different = MGCs. =20 ie) One MGC can't effectively utilize all the terminations on the MG = etc=20 Carl > -----Original Message----- > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org]On Behalf > Of Tamar Nemet > Sent: Thursday, June 09, 2005 6:48 AM > To: 'Albrecht.Schwarz@alcatel.de'; Raphael Tryster > Cc: 'megaco@ietf.org' > Subject: RE: [Megaco] Virtual Media Gateways and amount of = Termination > IDs >=20 >=20 >=20 > Hello Albrecht, >=20 > Thanks for your answers, BUT I need some more information: >=20 > If my MG IP address is 10.10.10.8, how many Termination IDs=20 > can be defined > on it without using the Virtual MG object ? >=20 > Thanks, > Tamar >=20 > -----Original Message----- > From: Albrecht.Schwarz@alcatel.de = [mailto:Albrecht.Schwarz@alcatel.de] > Sent: Thursday, June 09, 2005 1:04 PM > To: Raphael Tryster > Cc: 'megaco@ietf.org'; Tamar Nemet > Subject: RE: [Megaco] Virtual Media Gateways and amount of=20 > Termination IDs >=20 >=20 >=20 > If you mean with "signaling IP@" the IP@ used for H.248=20 > transport then NO. >=20 > 1) A H.248 MG (=3D VMG or non-VMG) is denoted by a single H.248 = Control > Association (see =A7 F.2/H.248.1). > The Control Association is mapped on a "transport=20 > connection", in case of > IP dependent on UDP, TCP or SCTP transport. > In case of SCTP, you MAY(theoretically) use different IP@s=20 > for the "SCTP > multihoming" capability. But there are other realization=20 > possibilities as > well. >=20 > 2) The H.248 Message ID may be IP@-based as well. Both IP@s=20 > are firstly > decoupled, but there are concepts (see certain H.248 Profiles), which > correlating both. >=20 > Regards > Albrecht > ALCATEL >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 >=20 > Raphael Tryster >=20 > <raphael@tdsoft. To: Albrecht > SCHWARZ/DE/ALCATEL@ALCATEL, Tamar Nemet =20 > com> =20 > <tamar.nemet@commatch.com> >=20 > cc: =20 > "'megaco@ietf.org'" > <megaco@ietf.org> =20 > 09.06.2005 07:54 Subject: RE:=20 > [Megaco] Virtual > Media Gateways and amount of Termination IDs =20 > =20 >=20 >=20 >=20 >=20 >=20 > Do you mean that a physical MG might have several different=20 > signaling IP > addresses but NOT be divided into multiple virtual MGs? >=20 >=20 > Raphael Tryster >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Albrecht.Schwarz@alcatel.de = [mailto:Albrecht.Schwarz@alcatel.de] > Sent: Wednesday, June 08, 2005 7:41 PM > To: Tamar Nemet > Cc: 'megaco@ietf.org'; Raphael Tryster > Subject: RE: [Megaco] Virtual Media Gateways and amount of=20 > Termination IDs >=20 >=20 >=20 >=20 >=20 > Addressing IP interfaces of a H.248 MG is NO rationale for=20 > the introduction >=20 > of VMGs. > There are typically other requirements driving for VMG=20 > approaches. Even so, >=20 > the VMGs may share address space, or use disjoint IP addresses for = the > diversity of IP applications served by a VoIP MG. This depends on the > specific use case and underlying network architecture. >=20 >=20 > So, please not misread =A7 11.1/H.248.1. >=20 >=20 > Rgds, > Albrecht > ALCATEL >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Tamar Nemet >=20 >=20 > <tamar.nemet@com To: =20 > "'Raphael Tryster'" > <raphael@tdsoft.com>, Tamar Nemet >=20 >=20 > match.com> =20 > <tamar.nemet@commatch.com>, > "'megaco@ietf.org'" <megaco@ietf.org> >=20 >=20 > Sent by: cc: >=20 >=20 > megaco-bounces@i Subject: RE: [Megaco] > Virtual Media Gateways and amount of Termination IDs >=20 >=20 > etf.org >=20 >=20 >=20 >=20 >=20 >=20 > 08.06.2005 14:05 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Can the SoftSwitch use different FQDNs for virtual media=20 > gateways and not > the ip address and port of the physical Media gateway ? >=20 >=20 > Tamar >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Raphael Tryster [mailto:raphael@tdsoft.com] > Sent: Wednesday, June 08, 2005 3:17 PM > To: 'Tamar Nemet'; 'megaco@ietf.org' > Subject: RE: [Megaco] Virtual Media Gateways and amount of > Termination IDs >=20 >=20 > They can use different UDP ports. The answer to your=20 > second question >=20 > is No, but I would also be interested to hear different=20 > answers from > others. >=20 >=20 > Raphael Tryster >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Tamar Nemet [mailto:tamar.nemet@commatch.com] > Sent: Wednesday, June 08, 2005 12:31 PM > To: Raphael Tryster; Tamar Nemet; 'megaco@ietf.org' > Subject: RE: [Megaco] Virtual Media Gateways and amount = of > Termination IDs >=20 >=20 >=20 >=20 >=20 > Hello raphael, >=20 >=20 > Thanks for your answer. But I can't understand how the > SoftSwitch can use multiple ROOTs if the all the=20 > Virtual Media > Gateways has the same IP address ? >=20 >=20 > Did you see any SoftSwitch that uses the Virtual=20 > MediaGateways > ? >=20 >=20 > Thanks, > Tamar >=20 >=20 > -----Original Message----- > From: Raphael Tryster [mailto:raphael@tdsoft.com] > Sent: Wednesday, June 08, 2005 1:54 PM > To: 'Tamar Nemet'; 'megaco@ietf.org' > Subject: RE: [Megaco] Virtual Media=20 > Gateways and amount > of Termination IDs > There is no requirement to artificially=20 > split a large > gateway into multiple virtual MGs. You=20 > might have other > reasons for wanting to split it. For example, = there > might be different sets of global=20 > characteristics that > you want to set differently for subsets of your > terminations, so you would like to have=20 > multiple ROOTs. > Or, you might want different sets of=20 > terminations to be > controlled by different soft switches. >=20 >=20 > Raphael Tryster >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Tamar Nemet=20 [mailto:tamar.nemet@commatch.com] Sent: Wednesday, June 08, 2005 11:22 AM To: 'megaco@ietf.org' Subject: [Megaco] Virtual Media Gateways and = amount of Termination IDs Hello, I have some questions regarding Virtual media gateway: 1. I have one physical media gateway (with one = IP address). We can define up to 4400 Termination = IDs on this media gateway. Does we have to devide the termination IDs = to some virtual media gateways or we can work with = no virtual media gateway ? 2. Does SoftSwitches uses the Virtual Media = Gatway object? for what ? Thanks, Tamar = _______________________________________________ Megaco mailing 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 Thu Jun 09 11:21:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgOqX-00082T-SD; Thu, 09 Jun 2005 11:21:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgOqW-00082G-1k for megaco@megatron.ietf.org; Thu, 09 Jun 2005 11:21:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11427 for <Megaco@ietf.org>; Thu, 9 Jun 2005 11:21:25 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgPBy-00085E-9u for Megaco@ietf.org; Thu, 09 Jun 2005 11:43:40 -0400 Received: from horh1.emsr.lucent.com (h135-112-138-211.lucent.com [135.112.138.211]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j59FLK2i000300 for <Megaco@ietf.org>; Thu, 9 Jun 2005 10:21:20 -0500 (CDT) Received: from beavis.ho.lucent.com (beavis.ho.lucent.com [135.112.125.152]) by horh1.emsr.lucent.com (8.12.11/8.12.11) with ESMTP id j59FLJB9026753 for <Megaco@ietf.org>; Thu, 9 Jun 2005 10:21:19 -0500 (CDT) Received: from [135.112.125.177] (pinky.ho.lucent.com [135.112.125.177]) by beavis.ho.lucent.com (8.11.6+Sun/8.11.6) with ESMTP id j59FLJD29402 for <Megaco@ietf.org>; Thu, 9 Jun 2005 11:21:19 -0400 (EDT) Message-ID: <42A85E45.8020108@bell-labs.com> Date: Thu, 09 Jun 2005 11:20:37 -0400 From: Troy Cauble <troy@bell-labs.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Megaco@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Cc: Subject: [Megaco] held party released tone ? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control <megaco.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe> List-Post: <mailto:megaco@ietf.org> List-Help: <mailto:megaco-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe> Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Is there a package definition for a tone played to the holder when a held party (e.g. call waiting) hangs up? -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 09 12:17:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgPcg-0002xp-Kg; Thu, 09 Jun 2005 12:11:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgPce-0002xU-HR for megaco@megatron.ietf.org; Thu, 09 Jun 2005 12:11:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17300 for <megaco@ietf.org>; Thu, 9 Jun 2005 12:11:09 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DgPy9-00028C-1b for megaco@ietf.org; Thu, 09 Jun 2005 12:33:25 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1118316508; Thu Jun 09 19:11:17 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id <CN1G5WP0>; Thu, 9 Jun 2005 19:14:13 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D30FC@MAILSERVER> From: Raphael Tryster <raphael@tdsoft.com> To: "'megaco@ietf.org'" <megaco@ietf.org> Date: Thu, 9 Jun 2005 19:14:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Megaco] No context in wildcard X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control <megaco.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe> List-Post: <mailto:megaco@ietf.org> List-Help: <mailto:megaco-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1653141255==" 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. --===============1653141255== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56D16.A7E9C270" 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_01C56D16.A7E9C270 Content-Type: text/plain; charset="iso-8859-1" Many variations of this question have been discussed in the list, but I can't find this one exactly: If the MGC requests that an action be performed on ALL contexts, and no contexts exist, how should the MG reply? Note that this is not the same as no matching terms in a particular context, or in all contexts, in which case it returns error 431. An example where this might be used is if the MGC wants to clean up from suspected mismatches, and sends a transaction consisting of two actions, where the first subtracts all terminations from all contexts, and the second requests all terminations in the null context to report when they see off-hook. If at least one termination exists in one context, the first action will succeed and the second action will be performed. If no contexts exist, then what happens next depends on the answer to my question. If the MG has to return an action-level error (431?), then the second action will not be performed. Otherwise, it will. Raphael Tryster ------_=_NextPart_001_01C56D16.A7E9C270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885= 9-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 5.5.2654.4= 5"> <TITLE>No context in wildcard

Many variations of this question have been discussed in= the list, but I can't find this one exactly:

If the MGC requests that an action be performed on ALL = contexts, and no contexts exist, how should the MG reply?

Note that this is not the same as no matching terms in = a particular context, or in all contexts, in which case it returns error = 431.

An example where this might be used is if the MGC wants= to clean up from suspected mismatches, and sends a transaction consistin= g of two actions, where the first subtracts all terminations from all con= texts, and the second requests all terminations in the null context to re= port when they see off-hook.  If at least one termination exists in = one context, the first action will succeed and the second action will be = performed.  If no contexts exist, then what happens next depends on = the answer to my question.  If the MG has to return an action-level = error (431?), then the second action will not be performed.  Otherwi= se, it will.

Raphael Tryster



------_=_NextPart_001_01C56D16.A7E9C270-- --===============1653141255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1653141255==-- From megaco-bounces@ietf.org Thu Jun 09 12:35:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQ07-0000kQ-Rp; Thu, 09 Jun 2005 12:35:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQ06-0000kH-Np for megaco@megatron.ietf.org; Thu, 09 Jun 2005 12:35:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19280 for ; Thu, 9 Jun 2005 12:35:23 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgQLZ-0006Cn-JX for megaco@ietf.org; Thu, 09 Jun 2005 12:57:39 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j59GZ4921636 for ; Thu, 9 Jun 2005 12:35:04 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jun 2005 12:34:49 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40263A8B0@zrtphxm2> From: "Kevin Boyle" To: Tamar Nemet , "'megaco@ietf.org'" Subject: RE: [Megaco] Nortel SoftSwitch and others Date: Thu, 9 Jun 2005 12:34:42 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 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 Well, I hate to break this to you, but your statement about "Nortel SoftSwitch" is incorrect. I believe most information of this kind is protected by NDAs and such... Are you sure you should be making pronouncements like this in a public forum? Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Tamar Nemet Sent: Thursday, June 09, 2005 5:09 AM To: 'megaco@ietf.org' Subject: [Megaco] Nortel SoftSwitch and others Hello, I know that Nortel SoftSwitch allow provisioning of up to 1000 Termination IDs on the same MG. Does anybody knows how much Termination IDs other SoftSwitch allows ? (for example: Alcatel Soft Switch) Thanks, Tamar _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 09 12:44:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQ95-0002jQ-MH; Thu, 09 Jun 2005 12:44:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQ94-0002jL-8Z for megaco@megatron.ietf.org; Thu, 09 Jun 2005 12:44:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19850 for ; Thu, 9 Jun 2005 12:44:39 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgQUX-0006Qw-2D for megaco@ietf.org; Thu, 09 Jun 2005 13:06:55 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j59Gha705142 for ; Thu, 9 Jun 2005 12:43:36 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jun 2005 12:44:28 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40263A8D0@zrtphxm2> From: "Kevin Boyle" To: Raphael Tryster , "'megaco@ietf.org'" Subject: RE: [Megaco] No context in wildcard Date: Thu, 9 Jun 2005 12:44:15 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 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 believe you are looking for error 411 at the action level. Note that the MG will never get to the second action if there is an error in the first action. What you can do is send these as two different transactions in the same message, if you are worried about messaging overhead. If not, I see no real reason to force these to be in the same message. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Raphael Tryster Sent: Thursday, June 09, 2005 1:14 PM To: 'megaco@ietf.org' Subject: [Megaco] No context in wildcard Many variations of this question have been discussed in the list, but I can't find this one exactly: If the MGC requests that an action be performed on ALL contexts, and no contexts exist, how should the MG reply? Note that this is not the same as no matching terms in a particular context, or in all contexts, in which case it returns error 431. An example where this might be used is if the MGC wants to clean up from suspected mismatches, and sends a transaction consisting of two actions, where the first subtracts all terminations from all contexts, and the second requests all terminations in the null context to report when they see off-hook. If at least one termination exists in one context, the first action will succeed and the second action will be performed. If no contexts exist, then what happens next depends on the answer to my question. If the MG has to return an action-level error (431?), then the second action will not be performed. Otherwise, it will. Raphael Tryster _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 09 12:46:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQAk-00037T-1M; Thu, 09 Jun 2005 12:46:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQAi-00036F-CU for megaco@megatron.ietf.org; Thu, 09 Jun 2005 12:46:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20057 for ; Thu, 9 Jun 2005 12:46:21 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgQWA-0006aH-Td for Megaco@ietf.org; Thu, 09 Jun 2005 13:08:37 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j59Gk6W00369 for ; Thu, 9 Jun 2005 12:46:06 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jun 2005 12:46:05 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40263A8D2@zrtphxm2> From: "Kevin Boyle" To: Troy Cauble , Megaco@ietf.org Subject: RE: [Megaco] held party released tone ? Date: Thu, 9 Jun 2005 12:45:53 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 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 Currently, there is not to my knowledge. In fact, this is the first I've heard of a tone for this situation! If there is need, we could version one of the tones packages to include it. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Troy Cauble Sent: Thursday, June 09, 2005 11:21 AM To: Megaco@ietf.org Subject: [Megaco] held party released tone ? Is there a package definition for a tone played to the holder when a held party (e.g. call waiting) hangs up? -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 09 12:51:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQFs-0004Sf-Ru; Thu, 09 Jun 2005 12:51:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQFr-0004Sa-DY for megaco@megatron.ietf.org; Thu, 09 Jun 2005 12:51:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20570 for ; Thu, 9 Jun 2005 12:51:40 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgQbM-0006oG-Ec for megaco@ietf.org; Thu, 09 Jun 2005 13:13:56 -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 j59GpXs19392 for ; Thu, 9 Jun 2005 12:51:33 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jun 2005 12:51:32 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40263A8E4@zrtphxm2> From: "Kevin Boyle" To: "Putter, Michael [Business:EXTRNL:3L40]" , Tamar Nemet , "'megaco@ietf.org'" Subject: RE: [Megaco] Dial Plan. Date: Thu, 9 Jun 2005 12:51:23 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org A DigitMap can be named on Root and referenced by other terminations in their completion events, yes. When any completion event completes, the DigitMap is deactivated *for that event*. This means that no further digit reporting can occur using that completion event until a new Events Descriptor is provided. Digit buffering WILL occur per the spec and any parameters contained in the completion event. This does NOT mean that other terminations are not able to use the DigitMap. A completion event on Root is nonsensical, since the MG function does not collect digits -- a digit receiver connected to the termination is what collects the digits. Digit collection, therefore, is clearly tied to individual terminations and not the MG as a whole. Kevin -----Original Message----- From: Putter, Michael [Business:EXTRNL:3L40] Sent: Thursday, June 09, 2005 9:34 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Tamar Nemet; 'megaco@ietf.org' Subject: RE: [Megaco] Dial Plan. Hello, In continue to the question. Can DigitMap be activated for the ROOT termination like other events by Event descriptor with digit map completion event and then the digit map will be active for a future call unless new Event descriptor with digit map completion event will be applied for the call? I have not found restriction in the standard for that scenario, but is it real? Do somebody use this way of digit map activation? Thanks, Michael. -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On Behalf Of Kevin Boyle Sent: Thursday, June 09, 2005 12:02 AM To: Tamar Nemet; 'megaco@ietf.org' Subject: RE: [Megaco] Dial Plan. MGs don't generally know about "dial plans". They are told to collect digits, through any of a number of means, and they report them. The MGC is responsible for translating the reported digits by applying the local dial plan. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Tamar Nemet Sent: Wednesday, June 08, 2005 5:28 AM To: 'megaco@ietf.org' Subject: [Megaco] Dial Plan. Hello, Do you know how SoftSwitches activate the dial plan ? Does they do it per call or they send an activation on the ROOT termination ? Thanks, Tamar _______________________________________________ Megaco mailing 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 Jun 09 17:48:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgUtG-0007CC-4g; Thu, 09 Jun 2005 17:48:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgUtE-0007C4-CL for megaco@megatron.ietf.org; Thu, 09 Jun 2005 17:48:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22706 for ; Thu, 9 Jun 2005 17:48:37 -0400 (EDT) Received: from web61315.mail.yahoo.com ([209.73.179.84]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DgVEl-0000fz-0O for megaco@ietf.org; Thu, 09 Jun 2005 18:10:56 -0400 Received: (qmail 83808 invoked by uid 60001); 9 Jun 2005 21:48:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yPwS3pBI3FlJngSqWlvIQPTxPb2pK299kq2rxpqM9DNbK2IuZRexNJgZfRRy7jFG/FZOfin9LSF/GrPCWvAkeroD9J93lnY1MqTcaUPlVdgXfYKNLFhIu4j+P8HRhZ8q9nV6MBKXedmsQ5kNqZBVsu2TQ2FbbZWlpekdhiEkvx8= ; Message-ID: <20050609214826.83806.qmail@web61315.mail.yahoo.com> Received: from [216.223.9.2] by web61315.mail.yahoo.com via HTTP; Thu, 09 Jun 2005 14:48:25 PDT Date: Thu, 9 Jun 2005 14:48:25 -0700 (PDT) From: Frank Reno To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 8bit Subject: [Megaco] Emergency flag 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 there any way to remove the emergency status of a context in text mode? Binary mode supports three states: either the emergency flag is absent, true or false. In text mode it can only be absent or true. Frank __________________________________ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 10 15:49:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgpVO-0008Oy-OT; Fri, 10 Jun 2005 15:49:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgpVN-0008Om-Qb for megaco@megatron.ietf.org; Fri, 10 Jun 2005 15:49:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27668 for ; Fri, 10 Jun 2005 15:49:23 -0400 (EDT) Received: from web61318.mail.yahoo.com ([209.73.179.72]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dgpr3-0003o6-Ub for megaco@ietf.org; Fri, 10 Jun 2005 16:11:53 -0400 Received: (qmail 80105 invoked by uid 60001); 10 Jun 2005 19:49:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LRrmlxZVf2XlFp1eWn9ve3jGx3duwZmMrthzQbLSe/tOfEuD4xCq2k9PkQ8GoltcgohHtLv0M2nfkEVRDGjd+xiqPiWV3LMfRfAFTVO8zjfYfx2X2NaTXZ5N9Lkl5qFoQhGYX2OTGz/1VBAf6Lj9AVc5IjQr/JGXEkRWgaKfepo= ; Message-ID: <20050610194913.80103.qmail@web61318.mail.yahoo.com> Received: from [216.223.9.2] by web61318.mail.yahoo.com via HTTP; Fri, 10 Jun 2005 12:49:13 PDT Date: Fri, 10 Jun 2005 12:49:13 -0700 (PDT) From: Frank Reno Subject: RE: [Megaco] Conformance tests question To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Content-Transfer-Encoding: 8bit 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 If an action fails with a context ID of CHOOSE and it is not the first action in the transaction, then the error can't be placed at the action level, since the grammar does not permit action replies and an action level error descriptor in the same transaction reply. So it looks like CHOOSE should be allowed in the reply. Given T = 1 { C = 1 { Add = t1 }, C = $ { Add = t2 } } This is not legal: Reply = 1 { C = 1 { Add = t1 }, Error = 412 {} } So it would have to be: Reply = 1 { C = 1 { Add = t1 }, C = $ { Error = 412 {}} } Frank --- Kevin Boyle wrote: In most cases, the MG knows it cannot allocate a context at the time the request is detected -- that is, once the action is parsed. If the MG detects a problem, why would it continue to parse? The error descriptor ought to be placed at the action level, so there would not be a context indicated of any kind, let alone a CHOOSE wildcard. Remember, error detection occurs at the earliest possible time with the error descriptor occurring at the level of detection. If the MG was not able to detect that it was unable to allocate a context until the command or descriptor level, then the error descriptor would go at the lower level. Kevin -----Original Message----- From: megaco-bounces at ietf.org [mailto:megaco-bounces at ietf.org] On Behalf Of B Venkat S.R Swamy Sent: Thursday, May 26, 2005 8:25 AM To: Seraya.Miletzki at ecitele.com Cc: megaco at ietf.org Subject: Re: [Megaco] Conformance tests question Hi IMO it is perfectly valid to specify CHOOSE for contextID in response to the test cases you have mentioned below. As far as the protocol text you have mentioned it applies mostly to those scenario where you a valid context Id(includes wildcard also) or Null context. Where MG has never been able to create a context why should it return any other value. Even the ABNF and ASN grammar in Appendix does not put any limitation on the set of values that can be used in the Reply messages. I however do agree that the relevant text should be modified to clarify these scenario and request authors to take this in IG or upcoming V3 document. regards B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.hssworld.com Seraya.Miletzki at e citele.com Sent by: To megaco-bounces at ie megaco at ietf.org tf.org cc Subject 05/26/2005 05:17 [Megaco] Conformance tests question PM Hello all I was performing conformance tests for the MEGACO according ETSI TS 101 889-2 v1.1.1 (2002-08). I have a question regarding some of the expected results appeared on this tests: On error tests (BI type) there are several tests that send request with ContextID set to CHOOSE ($). The expected results on the tests contain action reply with ContextID set to CHOOSE. Here is an example for this tests : TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1 [3] clause 7.2.1 Selection criteria: ROOT termination implemented Initial condition: any Ensure that the IUT, on receipt of a Transaction Request containing * Action request with o CID set to CHOOSE o ADD Command request wi sends a Transaction Reply containing * Action reply with o CID set to CHOOSE o ADD Command reply wi RO The H.248.1 v1 spec mandate that transaction reply may only contain a specific ContextID, ALL (*), or NULL (-). Here's the relevant text from the H.248.1 v1 spec: 8.2.2 TransactionReply ... The ContextID parameter must specify a value to pertain to all Responses for the action. The ContextID may be specific, all or null. The following 19 items are the test cases with this requirement. 1. TP/MG/AD/BI-01 2. TP/MG/AC/BI-01 3. TP/MG/AC/BI-02 4. TP/MG/AC/BI-03 5. TP/MG/AC/BI-04 6. TP/MG/AV/BI-01 7. TP/MG/AV/BI-02 8. TP/MG/AV/BI-03 9. TP/MG/AV/BI-04 10. TP/MG/MD/BI-01 11. TP/MG/MD/BI-02 12. TP/MG/MD/BI-03 13. TP/MG/MD/BI-09 14. TP/MG/SU/BI-01 15. TP/MG/SU/BI-02 16. TP/MG/SU/BI-03 17. TP/MG/SU/BI-04 18. TP/MG/MV/BI-01 19. TP/MG/MV/BI-02 Please help me to clear this issue. Thanks Seraya_______________________________________________ Megaco mailing list Megaco at ietf.org https://www1.ietf.org/mailman/listinfo/megaco __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Jun 13 09:32:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhp3K-0006wD-DO; Mon, 13 Jun 2005 09:32:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhi6x-0003Ap-P6 for megaco@megatron.ietf.org; Mon, 13 Jun 2005 02:07:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25624 for ; Mon, 13 Jun 2005 02:07:50 -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 1DhiTB-0002LH-HL for megaco@ietf.org; Mon, 13 Jun 2005 02:30:50 -0400 Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203]) by smtp.ccpu.com (Postfix) with ESMTP id 9D69E346905 for ; Sun, 12 Jun 2005 23:07:35 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 12 Jun 2005 23:05:38 -0700 Message-ID: Thread-Topic: encode/decode al event parameter Thread-Index: AcVv3evTtq+gtgOmRiCYc5X/6ccjPQ== From: "Pankaj Kumar" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 X-Mailman-Approved-At: Mon, 13 Jun 2005 09:32:33 -0400 Cc: Dalbir Singh Subject: [Megaco] encode/decode al event parameter 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="===============1460630768==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1460630768== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56FDE.31392254" This is a multi-part message in MIME format. ------_=_NextPart_001_01C56FDE.31392254 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi RFC 3525 section E.9 where the "al" package is described, it tells you that init should have Boolean values of true or false. Initial State ParameterID: init (0x0002) Type: Boolean Possible values: "True" means that the event was reported because the line was already on-hook when the events descriptor containing this event was activated; "False" means that the event represents an actual state transition to on-hook. =20 Section B.2 of RFC 3015 says the following - ; Boolean values, indicated in the text as True and False, are ; encoded as "On" and "Off", respectively, in the ABNF. =20 This is somewhat confusing between E.9 (RFC 3525) and B.2 (RFC 3015) whether we have to encode init as true/false or on/off. =20 =20 Thanks & Regards Pankaj Kumar =20 ------_=_NextPart_001_01C56FDE.31392254 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi

RFC 3525 section E.9 where the "al" package = is described, it tells you that init should have Boolean values of true or = false.

Initial State

         ParameterID: init (0x0002)

         =    Type: Boolean

         = Possible values:

         =     "True" means that the event was reported because the line was = already on-hook when the events descriptor containing this event was = activated;

         =     "False" means that the event represents an actual state = transition to on-hook.

 

Section B.2 of RFC 3015 says the following = -

   ; Boolean values, indicated in the text = as True and False, are

   ; encoded as "On" and "Off", respectively, in the ABNF.

 

This is somewhat confusing between E.9 (RFC 3525) and = B.2 (RFC 3015) whether we have to encode init as true/false or = on/off.

 

 

Thanks & Regards

Pankaj = Kumar

 

------_=_NextPart_001_01C56FDE.31392254-- --===============1460630768== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1460630768==-- From megaco-bounces@ietf.org Tue Jun 14 08:18:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiAND-0004N7-Bc; Tue, 14 Jun 2005 08:18:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiANB-0004N2-Qn for megaco@megatron.ietf.org; Tue, 14 Jun 2005 08:18:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08522 for ; Tue, 14 Jun 2005 08:18:28 -0400 (EDT) Received: from smtp-out.hotpop.com ([38.113.3.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiAjX-0004pj-Gx for megaco@ietf.org; Tue, 14 Jun 2005 08:41:44 -0400 Received: from bonbon.net (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id D8D0D16225F9 for ; Tue, 14 Jun 2005 12:18:11 +0000 (UTC) Received: from ABalyan32544 (unknown [203.196.196.114]) by smtp-1.hotpop.com (Postfix) with ESMTP id 3A1221A0164; Tue, 14 Jun 2005 12:18:03 +0000 (UTC) Message-ID: <000901c570db$20e3dcc0$350019ac@ABalyan32544> From: "Ashish Kumar" To: References: <34B3EAA5B3066A42914D28C5ECF5FEA40263A8E4@zrtphxm2> Date: Tue, 14 Jun 2005 17:48:03 +0530 Organization: Continuous Computing MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-HotPOP: ----------------------------------------------- Sent By HotPOP.com FREE Email Get your FREE POP email at www.HotPOP.com ----------------------------------------------- X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: uday@ccpu.com Subject: [Megaco] EventBuffering and Events Descriptor X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hi, I have a query about handling of Events Descriptor when Events Buffering is on. Considering the following scenarios Scenario 1 ----------- EventsBufferedDescriptor has following events E1, E2, E3 Buffered Events E1, E3 A new events descriptor is received with following events: E1, E2 In this case E1 will be reported. Scenario 2 ----------- EventsBufferedDescriptor has following events E1, E2, E3 Buffered Events E1, E3 A new events descriptor is received with following events: E2 (At this point active event list would have E2). After this when, E2 occurs, should it be reported or buffered ? If E2 is buffered then, wouldn't it be wrong since Event E2 was requested. Basically in this case the behaviour is going to depend on the time when E2 occurs. If E2 occurs before Requested Event was received, then it will be reported. And if it occurs after that, it will not be reported. Is this behaviour correct ? Regards Ashish _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 14 08:26:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiAV5-0005ig-QE; Tue, 14 Jun 2005 08:26:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di4Sj-00058w-0g for megaco@megatron.ietf.org; Tue, 14 Jun 2005 01:59:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21050 for ; Tue, 14 Jun 2005 01:59:48 -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 1Di4p9-0004sb-J0 for megaco@ietf.org; Tue, 14 Jun 2005 02:23:00 -0400 Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203]) by smtp.ccpu.com (Postfix) with ESMTP id 29C193468C5 for ; Mon, 13 Jun 2005 22:59:35 -0700 (PDT) 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: Mon, 13 Jun 2005 22:57:37 -0700 Message-ID: Thread-Topic: Megaco Digest, Vol 14, Issue 15 Thread-Index: AcVwMnF3KO4OUwnVRvWg8FZWPWejWQAcQ9Bw From: "Pankaj Kumar" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 14 Jun 2005 08:26:37 -0400 Subject: [Megaco] RE: Megaco Digest, Vol 14, Issue 15 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=20 Please ignore my previous mail since it was referencing to some other RFC. I am reframing the mail with reference to Megaco V2 Draft.=20 Megaco V2 section E.9 where the "al" package is described, it tells that init should have Boolean values of true or false. It says the following -=20 ObservedEventsDescriptor parameters=20 Initial State=20 ParameterID: init (0x0002)=20 Type: Boolean=20 Possible values:=20 "True" means that the event was reported because the line=20 was already on-hook when the events descriptor containing=20 this event was activated;=20 "False" means that the event represents an actual state=20 transition to on-hook. Whereas in section B.2 it says the following - Boolean: Boolean values are encoded as "on" and "off" and are=20 case insensitive. The SafeChar form of VALUE MUST be used. This is somewhat confusing between section E.9 and B.2 in Megaco V2 draft whether we have to encode init as true/false or on/off. So I have confusion out of below two Notify messages which one is correct. 1) MEGACO/1 [125.125.125.111]:55555 Transaction =3D 50008 { Context =3D 5000 { Notify =3D A5555 {ObservedEvents =3D1235 { 19990729T24020002:al/on{init=3Dfalse}} } } } 2) MEGACO/1 [125.125.125.111]:55555 Transaction =3D 50008 { Context =3D 5000 { Notify =3D A5555 {ObservedEvents =3D1235 { 19990729T24020002:al/on{init=3Doff}} } } } Thanks very much. Regards Pankaj -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of megaco-request@ietf.org Sent: Monday, June 13, 2005 9:41 PM To: megaco@ietf.org Subject: Megaco Digest, Vol 14, Issue 15 Send Megaco mailing list submissions to megaco@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/megaco or, via email, send a message with subject or body 'help' to megaco-request@ietf.org You can reach the person managing the list at megaco-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Megaco digest..." Today's Topics: 1. encode/decode al event parameter (Pankaj Kumar) ---------------------------------------------------------------------- Message: 1 Date: Sun, 12 Jun 2005 23:05:38 -0700 From: "Pankaj Kumar" Subject: [Megaco] encode/decode al event parameter To: Cc: Dalbir Singh Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi RFC 3525 section E.9 where the "al" package is described, it tells you that init should have Boolean values of true or false. Initial State ParameterID: init (0x0002) Type: Boolean Possible values: "True" means that the event was reported because the line was already on-hook when the events descriptor containing this event was activated; "False" means that the event represents an actual state transition to on-hook. =20 Section B.2 of RFC 3015 says the following - ; Boolean values, indicated in the text as True and False, are ; encoded as "On" and "Off", respectively, in the ABNF. =20 This is somewhat confusing between E.9 (RFC 3525) and B.2 (RFC 3015) whether we have to encode init as true/false or on/off. =20 =20 Thanks & Regards Pankaj Kumar =20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/megaco/attachments/20050612/a9fedc52/atta chment.htm ------------------------------ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco End of Megaco Digest, Vol 14, Issue 15 ************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 14 09:32:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiBWq-0008Rh-2e; Tue, 14 Jun 2005 09:32:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiBWo-0008RZ-Fi for megaco@megatron.ietf.org; Tue, 14 Jun 2005 09:32:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17805 for ; Tue, 14 Jun 2005 09:32:28 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DiBtG-0000vh-Eu for megaco@ietf.org; Tue, 14 Jun 2005 09:55:45 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1118747508; Tue Jun 14 16:32:34 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Tue, 14 Jun 2005 16:35:24 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D3108@MAILSERVER> From: Raphael Tryster To: megaco@ietf.org Date: Tue, 14 Jun 2005 16:35:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Megaco] order of descriptors in remote ringback scenario 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="===============1580362102==" 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. --===============1580362102== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C570EE.48760A70" 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_01C570EE.48760A70 Content-Type: text/plain; charset="WINDOWS-1255" "Descriptors may appear as parameters to commands in any order. The descriptors SHALL be processed in the order in which they appear". When remote ringback is required, the MGC adds an ephemeral termination to the context containing the called party, with signal descriptor cg/rt, and remote descriptor giving the address of the calling party who should hear the ringback tone. If the called party's MG processes the signal descriptor before the remote descriptor, it will not know where to send the ringback signal. Therefore, the MGC must place the ephemeral termination's media descriptor before the signal descriptor. Is this correct? Raphael Tryster ------_=_NextPart_001_01C570EE.48760A70 Content-Type: text/html; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable order of descriptors in remote ringback scenario

"Descriptors may appear as parameters to commands = in any order.  The descriptors SHALL be processed in the order in wh= ich they appear".

When remote ringback is required, the MGC adds an ephem= eral termination to the context containing the called party, with signal = descriptor cg/rt, and remote descriptor giving the address of the calling= party who should hear the ringback tone.  If the called party's MG = processes the signal descriptor before the remote descriptor, it will not= know where to send the ringback signal.  Therefore, the MGC must pl= ace the ephemeral termination's media descriptor before the signal descri= ptor.  Is this correct?

Raphael Tryster



------_=_NextPart_001_01C570EE.48760A70-- --===============1580362102== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1580362102==-- From megaco-bounces@ietf.org Tue Jun 14 11:12:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiD5k-0008IR-Dj; Tue, 14 Jun 2005 11:12:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiD5i-0008IJ-Sv for megaco@megatron.ietf.org; Tue, 14 Jun 2005 11:12:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25035 for ; Tue, 14 Jun 2005 11:12:36 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DiDSB-00073R-Ta for megaco@ietf.org; Tue, 14 Jun 2005 11:35:54 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1118747508; Tue Jun 14 18:12:36 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Tue, 14 Jun 2005 18:14:56 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D3109@MAILSERVER> From: Raphael Tryster To: megaco@ietf.org Date: Tue, 14 Jun 2005 18:14:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Subject: [Megaco] Who is responsible for stopping remote ringback? 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="===============1151670401==" 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. --===============1151670401== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C570FC.341ECB30" 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_01C570FC.341ECB30 Content-Type: text/plain; charset="WINDOWS-1255" When A calls B, the MGC applies a ringing signal to physical termination B, ringback tone on the ephemeral created in the same context as B, and requests off-hook on *physical* termination B. When B goes off-hook, signals *on that termination* are stopped. That means the ringing stops, but who is supposed to stop the ringback tone on the ephemeral, where no event occurred? Should the MG continue playing ringback tone on the ephemeral until it gets an explicit command from the MGC to stop? Raphael Tryster ------_=_NextPart_001_01C570FC.341ECB30 Content-Type: text/html; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable order of descriptors in remote ringback scenario

Wh= en A calls B, the MGC applies a ringing signal to physical termination B, ring= back tone on the ephemeral created in the same context as B, and requests off-= hook on *physical* termination = B.  When B goes off-hook, signals *= on that termination* are stopped.  That means the ringing stops, b= ut who is supposed to stop the ringback tone on the ephemeral, where no event occurred?  Should the MG co= ntinue playing ringback tone on the ephemeral until it gets an explicit command = from the MGC to stop?

 <= /p>

Raphael Tryster

 <= /o:p>

------_=_NextPart_001_01C570FC.341ECB30-- --===============1151670401== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1151670401==-- From megaco-bounces@ietf.org Tue Jun 14 11:26:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiDJ2-0004BA-Sa; Tue, 14 Jun 2005 11:26:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiDJ0-00049A-In for megaco@megatron.ietf.org; Tue, 14 Jun 2005 11:26:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27097 for ; Tue, 14 Jun 2005 11:26:20 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiDfV-00085y-6G for megaco@ietf.org; Tue, 14 Jun 2005 11:49:38 -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 j5EFPjb24199; Tue, 14 Jun 2005 11:25:46 -0400 (EDT) Received: from [127.0.0.1] (acart092.ca.nortel.com [47.130.17.12]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MRAFNRCK; Tue, 14 Jun 2005 11:25:45 -0400 Message-ID: <42AEF6F6.6020108@nortel.com> Date: Tue, 14 Jun 2005 11:25:42 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Raphael Tryster Subject: Re: [Megaco] Who is responsible for stopping remote ringback? References: <9A64A99CD3F2BD4582BE4FB63FC1F381010D3109@MAILSERVER> In-Reply-To: <9A64A99CD3F2BD4582BE4FB63FC1F381010D3109@MAILSERVER> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Yes, the MGC has to stop the signal. This is a difference from MGCP, where events are effectively propagated across the context. Raphael Tryster wrote: > When A calls B, the MGC applies a ringing signal to physical termination B, > ringback tone on the ephemeral created in the same context as B, and > requests off-hook on *physical* termination B. When B goes off-hook, > signals *on that termination* are stopped. That means the ringing stops, > but who is supposed to stop the ringback tone on the ephemeral, where no > event occurred? Should the MG continue playing ringback tone on the > ephemeral until it gets an explicit command from the MGC to stop? > > Raphael Tryster > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Megaco mailing 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 Jun 14 11:44:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiDao-0007XO-KZ; Tue, 14 Jun 2005 11:44:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiDam-0007XJ-4X for megaco@megatron.ietf.org; Tue, 14 Jun 2005 11:44:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28291 for ; Tue, 14 Jun 2005 11:44:41 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiDxH-0000kM-2m for megaco@ietf.org; Tue, 14 Jun 2005 12:08:00 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j5EFhQe08540 for ; Tue, 14 Jun 2005 11:43:26 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jun 2005 11:30:17 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4027325FE@zrtphxm2> From: "Kevin Boyle" To: Raphael Tryster , megaco@ietf.org Subject: RE: [Megaco] Who is responsible for stopping remote ringback? Date: Tue, 14 Jun 2005 11:30:03 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 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 Yes. With V3, you could put the ringback on the physical and play it backward through the context, though that would have the disadvantage of not being directly associated with the bearer path. That means that the signal would move with the physical even though it is more correctly associated with the far end for that particular stream. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Raphael Tryster Sent: Tuesday, June 14, 2005 12:15 PM To: megaco@ietf.org Subject: [Megaco] Who is responsible for stopping remote ringback? When A calls B, the MGC applies a ringing signal to physical termination B, ringback tone on the ephemeral created in the same context as B, and requests off-hook on *physical* termination B. When B goes off-hook, signals *on that termination* are stopped. That means the ringing stops, but who is supposed to stop the ringback tone on the ephemeral, where no event occurred? Should the MG continue playing ringback tone on the ephemeral until it gets an explicit command from the MGC to stop? Raphael Tryster _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 14 12:16:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiE5G-0005mm-DF; Tue, 14 Jun 2005 12:16:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiE5F-0005lh-6V for megaco@megatron.ietf.org; Tue, 14 Jun 2005 12:16:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01176 for ; Tue, 14 Jun 2005 12:16:10 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiERk-0002uf-CH for megaco@ietf.org; Tue, 14 Jun 2005 12:39:29 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5EGFq128834 for ; Tue, 14 Jun 2005 12:15:52 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jun 2005 12:15:50 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4027326DF@zrtphxm2> From: "Kevin Boyle" To: Raphael Tryster , megaco@ietf.org Subject: RE: [Megaco] order of descriptors in remote ringback scenario Date: Tue, 14 Jun 2005 12:15:40 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 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 While yes, the remote descriptor must be present in order for the far end to hear the signal, that itself does not preclude the signal from being applied. This is similar in concept to talking into a muted phone -- the talker is certainly making noise, but the other end cannot hear anything. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Raphael Tryster Sent: Tuesday, June 14, 2005 10:35 AM To: megaco@ietf.org Subject: [Megaco] order of descriptors in remote ringback scenario "Descriptors may appear as parameters to commands in any order. The descriptors SHALL be processed in the order in which they appear". When remote ringback is required, the MGC adds an ephemeral termination to the context containing the called party, with signal descriptor cg/rt, and remote descriptor giving the address of the calling party who should hear the ringback tone. If the called party's MG processes the signal descriptor before the remote descriptor, it will not know where to send the ringback signal. Therefore, the MGC must place the ephemeral termination's media descriptor before the signal descriptor. Is this correct? Raphael Tryster _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 14 12:18:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiE7K-0006qp-4i; Tue, 14 Jun 2005 12:18:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiE7I-0006or-T7 for megaco@megatron.ietf.org; Tue, 14 Jun 2005 12:18:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01375 for ; Tue, 14 Jun 2005 12:18:18 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiETp-00036g-0F for megaco@ietf.org; Tue, 14 Jun 2005 12:41:37 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5EGIA129159 for ; Tue, 14 Jun 2005 12:18:10 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jun 2005 12:17:58 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4027326EB@zrtphxm2> From: "Kevin Boyle" To: Pankaj Kumar , megaco@ietf.org Subject: RE: [Megaco] RE: Megaco Digest, Vol 14, Issue 15 Date: Tue, 14 Jun 2005 12:17:46 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: 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 Number 2 is correct. Note that items listed as enumerations that took true/false would be "true" or "false". Because this is explicitly a boolean, the text is encoded as "on" and "off". Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Pankaj Kumar Sent: Tuesday, June 14, 2005 1:58 AM To: megaco@ietf.org Subject: [Megaco] RE: Megaco Digest, Vol 14, Issue 15 Hi Please ignore my previous mail since it was referencing to some other RFC. I am reframing the mail with reference to Megaco V2 Draft. Megaco V2 section E.9 where the "al" package is described, it tells that init should have Boolean values of true or false. It says the following - ObservedEventsDescriptor parameters Initial State ParameterID: init (0x0002) Type: Boolean Possible values: "True" means that the event was reported because the line was already on-hook when the events descriptor containing this event was activated; "False" means that the event represents an actual state transition to on-hook. Whereas in section B.2 it says the following - Boolean: Boolean values are encoded as "on" and "off" and are case insensitive. The SafeChar form of VALUE MUST be used. This is somewhat confusing between section E.9 and B.2 in Megaco V2 draft whether we have to encode init as true/false or on/off. So I have confusion out of below two Notify messages which one is correct. 1) MEGACO/1 [125.125.125.111]:55555 Transaction = 50008 { Context = 5000 { Notify = A5555 {ObservedEvents =1235 { 19990729T24020002:al/on{init=false}} } } } 2) MEGACO/1 [125.125.125.111]:55555 Transaction = 50008 { Context = 5000 { Notify = A5555 {ObservedEvents =1235 { 19990729T24020002:al/on{init=off}} } } } Thanks very much. Regards Pankaj -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of megaco-request@ietf.org Sent: Monday, June 13, 2005 9:41 PM To: megaco@ietf.org Subject: Megaco Digest, Vol 14, Issue 15 Send Megaco mailing list submissions to megaco@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/megaco or, via email, send a message with subject or body 'help' to megaco-request@ietf.org You can reach the person managing the list at megaco-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Megaco digest..." Today's Topics: 1. encode/decode al event parameter (Pankaj Kumar) ---------------------------------------------------------------------- Message: 1 Date: Sun, 12 Jun 2005 23:05:38 -0700 From: "Pankaj Kumar" Subject: [Megaco] encode/decode al event parameter To: Cc: Dalbir Singh Message-ID: Content-Type: text/plain; charset="us-ascii" Hi RFC 3525 section E.9 where the "al" package is described, it tells you that init should have Boolean values of true or false. Initial State ParameterID: init (0x0002) Type: Boolean Possible values: "True" means that the event was reported because the line was already on-hook when the events descriptor containing this event was activated; "False" means that the event represents an actual state transition to on-hook. Section B.2 of RFC 3015 says the following - ; Boolean values, indicated in the text as True and False, are ; encoded as "On" and "Off", respectively, in the ABNF. This is somewhat confusing between E.9 (RFC 3525) and B.2 (RFC 3015) whether we have to encode init as true/false or on/off. Thanks & Regards Pankaj Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/megaco/attachments/20050612/a9fedc52/atta chment.htm ------------------------------ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco End of Megaco Digest, Vol 14, Issue 15 ************************************** _______________________________________________ Megaco mailing 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 Jun 14 12:22:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiEBW-0008E5-HN; Tue, 14 Jun 2005 12:22:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiEBU-0008Dv-G1 for megaco@megatron.ietf.org; Tue, 14 Jun 2005 12:22:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01764 for ; Tue, 14 Jun 2005 12:22:38 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiEY0-0003La-Pb for megaco@ietf.org; Tue, 14 Jun 2005 12:45:57 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5EGMU129813 for ; Tue, 14 Jun 2005 12:22:30 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jun 2005 12:22:29 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402732702@zrtphxm2> From: "Kevin Boyle" To: Ashish Kumar , megaco@ietf.org Subject: RE: [Megaco] EventBuffering and Events Descriptor Date: Tue, 14 Jun 2005 12:22:18 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: uday@ccpu.com 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 First, this all assumes LockStep is on. Scenario 1: E1 is reported, events reporting is disabled and E3 is STILL buffered. Scenario 2: Upon receipt of the Events Descriptor with just E2, E1 and E3 are discarded. Events reporting is still active and the buffer is empty. Upon detection of E2, E2 is reported and event reporting is disabled. Any detected event other than E2 is discarded, including E1 and E3. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Ashish Kumar Sent: Tuesday, June 14, 2005 8:18 AM To: megaco@ietf.org Cc: uday@ccpu.com Subject: [Megaco] EventBuffering and Events Descriptor Hi, I have a query about handling of Events Descriptor when Events Buffering is on. Considering the following scenarios Scenario 1 ----------- EventsBufferedDescriptor has following events E1, E2, E3 Buffered Events E1, E3 A new events descriptor is received with following events: E1, E2 In this case E1 will be reported. Scenario 2 ----------- EventsBufferedDescriptor has following events E1, E2, E3 Buffered Events E1, E3 A new events descriptor is received with following events: E2 (At this point active event list would have E2). After this when, E2 occurs, should it be reported or buffered ? If E2 is buffered then, wouldn't it be wrong since Event E2 was requested. Basically in this case the behaviour is going to depend on the time when E2 occurs. If E2 occurs before Requested Event was received, then it will be reported. And if it occurs after that, it will not be reported. Is this behaviour correct ? Regards Ashish _______________________________________________ Megaco mailing 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 Jun 14 12:36:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiEOY-00024w-Er; Tue, 14 Jun 2005 12:36:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiEOW-00024r-Vn for megaco@megatron.ietf.org; Tue, 14 Jun 2005 12:36:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02555 for ; Tue, 14 Jun 2005 12:36:05 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiEl2-0004CU-Hp for megaco@ietf.org; Tue, 14 Jun 2005 12:59:25 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5EGZmb26872; Tue, 14 Jun 2005 12:35:48 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jun 2005 12:35:48 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402732757@zrtphxm2> From: "Kevin Boyle" To: Frank Reno , megaco@ietf.org Subject: RE: [Megaco] Conformance tests question Date: Tue, 14 Jun 2005 12:35:38 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This seems like a problem with the syntax of the protocol. Since we clearly allow error descriptors at the action level, and we allow following errors at the transaction and command levels, this appears to need fixing. It appears that the binary encoding allows an error at the action level for the second (or subsequent) action in a transaction. The fix itself would be straightforward, though non-backwards compatible. This would mean that it would have to be in V3, and not made retroactive to V1 and V2. The fix would be: transactionReply = ReplyToken EQUAL TransactionID LBRKT [ImmAckRequiredToken COMMA](errorDescriptor / actionReplyList [COMMA errorDescriptor]) RBRKT Fix is here------------------------^^^^^^^^^^^^^^^^^^^^^^^ So, for V1 and V2, it would appear that your solution, though suboptimal in my view, is the only solution available within the syntax as defined. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Frank Reno Sent: Friday, June 10, 2005 3:49 PM To: megaco@ietf.org Subject: RE: [Megaco] Conformance tests question If an action fails with a context ID of CHOOSE and it is not the first action in the transaction, then the error can't be placed at the action level, since the grammar does not permit action replies and an action level error descriptor in the same transaction reply. So it looks like CHOOSE should be allowed in the reply. Given T = 1 { C = 1 { Add = t1 }, C = $ { Add = t2 } } This is not legal: Reply = 1 { C = 1 { Add = t1 }, Error = 412 {} } So it would have to be: Reply = 1 { C = 1 { Add = t1 }, C = $ { Error = 412 {}} } Frank --- Kevin Boyle wrote: In most cases, the MG knows it cannot allocate a context at the time the request is detected -- that is, once the action is parsed. If the MG detects a problem, why would it continue to parse? The error descriptor ought to be placed at the action level, so there would not be a context indicated of any kind, let alone a CHOOSE wildcard. Remember, error detection occurs at the earliest possible time with the error descriptor occurring at the level of detection. If the MG was not able to detect that it was unable to allocate a context until the command or descriptor level, then the error descriptor would go at the lower level. Kevin -----Original Message----- From: megaco-bounces at ietf.org [mailto:megaco-bounces at ietf.org] On Behalf Of B Venkat S.R Swamy Sent: Thursday, May 26, 2005 8:25 AM To: Seraya.Miletzki at ecitele.com Cc: megaco at ietf.org Subject: Re: [Megaco] Conformance tests question Hi IMO it is perfectly valid to specify CHOOSE for contextID in response to the test cases you have mentioned below. As far as the protocol text you have mentioned it applies mostly to those scenario where you a valid context Id(includes wildcard also) or Null context. Where MG has never been able to create a context why should it return any other value. Even the ABNF and ASN grammar in Appendix does not put any limitation on the set of values that can be used in the Reply messages. I however do agree that the relevant text should be modified to clarify these scenario and request authors to take this in IG or upcoming V3 document. regards B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.hssworld.com Seraya.Miletzki at e citele.com Sent by: To megaco-bounces at ie megaco at ietf.org tf.org cc Subject 05/26/2005 05:17 [Megaco] Conformance tests question PM Hello all I was performing conformance tests for the MEGACO according ETSI TS 101 889-2 v1.1.1 (2002-08). I have a question regarding some of the expected results appeared on this tests: On error tests (BI type) there are several tests that send request with ContextID set to CHOOSE ($). The expected results on the tests contain action reply with ContextID set to CHOOSE. Here is an example for this tests : TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1 [3] clause 7.2.1 Selection criteria: ROOT termination implemented Initial condition: any Ensure that the IUT, on receipt of a Transaction Request containing * Action request with o CID set to CHOOSE o ADD Command request wi sends a Transaction Reply containing * Action reply with o CID set to CHOOSE o ADD Command reply wi RO The H.248.1 v1 spec mandate that transaction reply may only contain a specific ContextID, ALL (*), or NULL (-). Here's the relevant text from the H.248.1 v1 spec: 8.2.2 TransactionReply ... The ContextID parameter must specify a value to pertain to all Responses for the action. The ContextID may be specific, all or null. The following 19 items are the test cases with this requirement. 1. TP/MG/AD/BI-01 2. TP/MG/AC/BI-01 3. TP/MG/AC/BI-02 4. TP/MG/AC/BI-03 5. TP/MG/AC/BI-04 6. TP/MG/AV/BI-01 7. TP/MG/AV/BI-02 8. TP/MG/AV/BI-03 9. TP/MG/AV/BI-04 10. TP/MG/MD/BI-01 11. TP/MG/MD/BI-02 12. TP/MG/MD/BI-03 13. TP/MG/MD/BI-09 14. TP/MG/SU/BI-01 15. TP/MG/SU/BI-02 16. TP/MG/SU/BI-03 17. TP/MG/SU/BI-04 18. TP/MG/MV/BI-01 19. TP/MG/MV/BI-02 Please help me to clear this issue. Thanks Seraya_______________________________________________ Megaco mailing list Megaco at ietf.org https://www1.ietf.org/mailman/listinfo/megaco __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 14 12:38:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiEQc-0002Aq-AX; Tue, 14 Jun 2005 12:38:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiEQZ-0002Aj-J2 for megaco@megatron.ietf.org; Tue, 14 Jun 2005 12:38:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02603 for ; Tue, 14 Jun 2005 12:38:13 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiEn5-0004Eq-05 for megaco@ietf.org; Tue, 14 Jun 2005 13:01:32 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5EGc4102098 for ; Tue, 14 Jun 2005 12:38:04 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jun 2005 12:37:58 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402732763@zrtphxm2> From: "Kevin Boyle" To: Frank Reno , megaco@ietf.org Subject: RE: [Megaco] Emergency flag Date: Tue, 14 Jun 2005 12:37:50 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 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 Yes, a new token (EmergencyOff) was introduced into the IG for V1 and V2 and into V3 to combat this very problem. Since this was seen as a critical problem in the syntax, it was allowed as an IG entry, even though it alters the syntax. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Frank Reno Sent: Thursday, June 09, 2005 5:48 PM To: megaco@ietf.org Subject: [Megaco] Emergency flag Is there any way to remove the emergency status of a context in text mode? Binary mode supports three states: either the emergency flag is absent, true or false. In text mode it can only be absent or true. Frank __________________________________ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html _______________________________________________ Megaco mailing 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 Jun 14 14:21:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiG2a-0003TX-0x; Tue, 14 Jun 2005 14: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 1DiG2Y-0003TO-DN for megaco@megatron.ietf.org; Tue, 14 Jun 2005 14:21:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14853 for ; Tue, 14 Jun 2005 14:21:33 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiGP5-00041n-Lu for megaco@ietf.org; Tue, 14 Jun 2005 14:44:52 -0400 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 Subject: RE: [Megaco] Conformance tests question Date: Tue, 14 Jun 2005 14:21:21 -0400 Message-ID: Thread-Topic: [Megaco] Conformance tests question Thread-Index: AcVw/2PYFnISTYgFQlC+QdX20wgEHQADa93w From: "Steve Cipolli" To: "Kevin Boyle" , "Frank Reno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Content-Transfer-Encoding: quoted-printable Cc: 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 Kevin, Allowing '$' for context in replies also violates v1 and v2, so it appears there is no solution at all for v1 and v2. Do you mean that the IG for v1 and v2 should be updated to allow '$' for context in replies? --Stephen > -----Original Message----- > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org] On Behalf Of Kevin Boyle > Sent: Tuesday, June 14, 2005 12:36 PM > To: Frank Reno; megaco@ietf.org > Subject: RE: [Megaco] Conformance tests question >=20 >=20 > This seems like a problem with the syntax of the protocol. =20 > Since we clearly allow error descriptors at the action level,=20 > and we allow following errors at the transaction and command=20 > levels, this appears to need fixing. It appears that the=20 > binary encoding allows an error at the action level for the=20 > second (or subsequent) action in a transaction. >=20 > The fix itself would be straightforward, though non-backwards=20 > compatible. This would mean that it would have to be in V3,=20 > and not made retroactive to V1 and V2. The fix would be: >=20 > transactionReply =3D ReplyToken EQUAL TransactionID LBRKT > [ImmAckRequiredToken COMMA](errorDescriptor /=20 > actionReplyList [COMMA errorDescriptor])=20 > RBRKT Fix is here------------------------^^^^^^^^^^^^^^^^^^^^^^^ >=20 > So, for V1 and V2, it would appear that your solution, though=20 > suboptimal in my view, is the only solution available within=20 > the syntax as defined. >=20 > Kevin > =20 >=20 > -----Original Message----- > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org] On Behalf Of Frank Reno > Sent: Friday, June 10, 2005 3:49 PM > To: megaco@ietf.org > Subject: RE: [Megaco] Conformance tests question >=20 > If an action fails with a context ID of CHOOSE and it is not=20 > the first action in the transaction, then the error can't be=20 > placed at the action level, since the grammar does not permit=20 > action replies and an action level error descriptor in the=20 > same transaction reply. >=20 > So it looks like CHOOSE should be allowed in the reply. >=20 > Given >=20 > T =3D 1 > { > C =3D 1 { Add =3D t1 }, > C =3D $ { Add =3D t2 } > } >=20 > This is not legal: >=20 > Reply =3D 1 > { > C =3D 1 { Add =3D t1 }, > Error =3D 412 {} > } >=20 > So it would have to be: >=20 > Reply =3D 1 > { > C =3D 1 { Add =3D t1 }, > C =3D $ { Error =3D 412 {}} > } >=20 > Frank >=20 >=20 >=20 > --- Kevin Boyle wrote: >=20 > In most cases, the MG knows it cannot allocate a context at=20 > the time the request is detected -- that is, once the action=20 > is parsed. If the MG detects a problem, why would it=20 > continue to parse?=20 > The error descriptor > ought to be placed at the action level, so there would not be=20 > a context indicated of any kind, let alone a CHOOSE wildcard. >=20 > Remember, error detection occurs at the earliest possible=20 > time with the error descriptor occurring at the level of detection.=20 > If the MG was not > able to detect that it was unable to allocate a context until=20 > the command or descriptor level, then the error descriptor=20 > would go at the lower level. >=20 > Kevin=20 >=20 > -----Original Message----- > From: megaco-bounces at ietf.org > [mailto:megaco-bounces at ietf.org] On Behalf Of B Venkat S.R Swamy > Sent: Thursday, May 26, 2005 8:25 AM > To: Seraya.Miletzki at ecitele.com > Cc: megaco at ietf.org > Subject: Re: [Megaco] Conformance tests question >=20 >=20 >=20 >=20 >=20 >=20 > Hi >=20 > IMO it is perfectly valid to specify CHOOSE for contextID in=20 > response to the test cases you have mentioned below. As far=20 > as the protocol text you have mentioned it applies mostly to=20 > those scenario where you a valid context Id(includes wildcard=20 > also) or Null context. Where MG has never been able to create=20 > a context why should it return any other value. >=20 > Even the ABNF and ASN grammar in Appendix does not put any=20 > limitation on the set of values that can be used in the Reply=20 > messages. >=20 > I however do agree that the relevant text should be modified=20 > to clarify these scenario and request authors to take this in=20 > IG or upcoming V3 document. >=20 > regards > B Venkat S.R Swamy > Senior Technical Leader > Flextronics Software Systems > Phone: +91-124-2455555 Extn 3620 > Fax: +91-124-2455345 > web: www.hssworld.com >=20 >=20 >=20 >=20 >=20 > =20 > =20 > Seraya.Miletzki at e =20 > =20 > citele.com =20 > =20 > Sent by: =20 > To=20 > megaco-bounces at ie megaco at > ietf.org =20 > tf.org =20 > cc=20 > =20 > =20 > =20 > Subject=20 > 05/26/2005 05:17 [Megaco] > Conformance tests question=20 > PM =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Hello all >=20 > I was performing conformance tests for the MEGACO according=20 > ETSI TS 101 889-2 v1.1.1 (2002-08). I have a question=20 > regarding some of the expected results appeared on this > tests: > On error tests (BI type) there are several tests that send=20 > request with ContextID set to CHOOSE ($). The expected=20 > results on the tests contain action reply with ContextID set=20 > to CHOOSE. Here is an example for this tests : >=20 > TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1 [3]=20 > clause 7.2.1 Selection criteria: ROOT termination implemented=20 > Initial condition: any Ensure that the IUT, on receipt of a=20 > Transaction Request containing > * Action request with > o CID set to CHOOSE > o ADD Command request wi > sends a Transaction Reply containing > * Action reply with > o CID set to CHOOSE > o ADD Command reply wi > RO >=20 > The H.248.1 v1 spec mandate that transaction reply may only=20 > contain a specific ContextID, ALL (*), or NULL (-). >=20 > Here's the relevant text from the H.248.1 v1 spec: > 8.2.2 TransactionReply > ... > The ContextID parameter must specify a value to pertain to=20 > all Responses for the action. The ContextID may be specific,=20 > all or null. >=20 > The following 19 items are the test cases with this requirement. >=20 > 1. TP/MG/AD/BI-01 > 2. TP/MG/AC/BI-01 > 3. TP/MG/AC/BI-02 > 4. TP/MG/AC/BI-03 > 5. TP/MG/AC/BI-04 > 6. TP/MG/AV/BI-01 > 7. TP/MG/AV/BI-02 > 8. TP/MG/AV/BI-03 > 9. TP/MG/AV/BI-04 > 10. TP/MG/MD/BI-01 > 11. TP/MG/MD/BI-02 > 12. TP/MG/MD/BI-03 > 13. TP/MG/MD/BI-09 > 14. TP/MG/SU/BI-01 > 15. TP/MG/SU/BI-02 > 16. TP/MG/SU/BI-03 > 17. TP/MG/SU/BI-04 > 18. TP/MG/MV/BI-01 > 19. TP/MG/MV/BI-02 >=20 >=20 > Please help me to clear this issue. >=20 > Thanks >=20 > Seraya_______________________________________________ > Megaco mailing list > Megaco at ietf.org https://www1.ietf.org/mailman/listinfo/megaco >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection=20 > around http://mail.yahoo.com=20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 14 16:53:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIPl-0002E1-Vr; Tue, 14 Jun 2005 16:53:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIPj-0002Ba-9Z for megaco@megatron.ietf.org; Tue, 14 Jun 2005 16:53:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05576 for ; Tue, 14 Jun 2005 16:53:35 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiImF-0001AB-OV for megaco@ietf.org; Tue, 14 Jun 2005 17:16:56 -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 j5EKrH518781 for ; Tue, 14 Jun 2005 16:53:17 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jun 2005 16:53:16 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4027BCB85@zrtphxm2> From: "Kevin Boyle" To: Steve Cipolli , Frank Reno , megaco@ietf.org Subject: RE: [Megaco] Conformance tests question Date: Tue, 14 Jun 2005 16:53:05 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: 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 Where do you see that restriction? Kevin -----Original Message----- From: Steve Cipolli [mailto:SCipolli@radvision.com] Sent: Tuesday, June 14, 2005 2:21 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org Subject: RE: [Megaco] Conformance tests question Kevin, Allowing '$' for context in replies also violates v1 and v2, so it appears there is no solution at all for v1 and v2. Do you mean that the IG for v1 and v2 should be updated to allow '$' for context in replies? --Stephen > -----Original Message----- > From: megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org] On Behalf Of Kevin Boyle > Sent: Tuesday, June 14, 2005 12:36 PM > To: Frank Reno; megaco@ietf.org > Subject: RE: [Megaco] Conformance tests question > > > This seems like a problem with the syntax of the protocol. > Since we clearly allow error descriptors at the action level, and we > allow following errors at the transaction and command levels, this > appears to need fixing. It appears that the binary encoding allows an > error at the action level for the second (or subsequent) action in a > transaction. > > The fix itself would be straightforward, though non-backwards > compatible. This would mean that it would have to be in V3, and not > made retroactive to V1 and V2. The fix would be: > > transactionReply = ReplyToken EQUAL TransactionID LBRKT > [ImmAckRequiredToken COMMA](errorDescriptor / > actionReplyList [COMMA errorDescriptor]) RBRKT Fix > is here------------------------^^^^^^^^^^^^^^^^^^^^^^^ > > So, for V1 and V2, it would appear that your solution, though > suboptimal in my view, is the only solution available within the > syntax as defined. > > Kevin > > > -----Original Message----- > From: megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org] On Behalf Of Frank Reno > Sent: Friday, June 10, 2005 3:49 PM > To: megaco@ietf.org > Subject: RE: [Megaco] Conformance tests question > > If an action fails with a context ID of CHOOSE and it is not the first > action in the transaction, then the error can't be placed at the > action level, since the grammar does not permit action replies and an > action level error descriptor in the same transaction reply. > > So it looks like CHOOSE should be allowed in the reply. > > Given > > T = 1 > { > C = 1 { Add = t1 }, > C = $ { Add = t2 } > } > > This is not legal: > > Reply = 1 > { > C = 1 { Add = t1 }, > Error = 412 {} > } > > So it would have to be: > > Reply = 1 > { > C = 1 { Add = t1 }, > C = $ { Error = 412 {}} > } > > Frank > > > > --- Kevin Boyle wrote: > > In most cases, the MG knows it cannot allocate a context at the time > the request is detected -- that is, once the action is parsed. If the > MG detects a problem, why would it continue to parse? > The error descriptor > ought to be placed at the action level, so there would not be a > context indicated of any kind, let alone a CHOOSE wildcard. > > Remember, error detection occurs at the earliest possible time with > the error descriptor occurring at the level of detection. > If the MG was not > able to detect that it was unable to allocate a context until the > command or descriptor level, then the error descriptor would go at the > lower level. > > Kevin > > -----Original Message----- > From: megaco-bounces at ietf.org > [mailto:megaco-bounces at ietf.org] On Behalf Of B Venkat S.R Swamy > Sent: Thursday, May 26, 2005 8:25 AM > To: Seraya.Miletzki at ecitele.com > Cc: megaco at ietf.org > Subject: Re: [Megaco] Conformance tests question > > > > > > > Hi > > IMO it is perfectly valid to specify CHOOSE for contextID in response > to the test cases you have mentioned below. As far as the protocol > text you have mentioned it applies mostly to those scenario where you > a valid context Id(includes wildcard > also) or Null context. Where MG has never been able to create a > context why should it return any other value. > > Even the ABNF and ASN grammar in Appendix does not put any limitation > on the set of values that can be used in the Reply messages. > > I however do agree that the relevant text should be modified to > clarify these scenario and request authors to take this in IG or > upcoming V3 document. > > regards > B Venkat S.R Swamy > Senior Technical Leader > Flextronics Software Systems > Phone: +91-124-2455555 Extn 3620 > Fax: +91-124-2455345 > web: www.hssworld.com > > > > > > > > Seraya.Miletzki at e > > citele.com > > Sent by: > To > megaco-bounces at ie megaco at > ietf.org > tf.org > cc > > > > Subject > 05/26/2005 05:17 [Megaco] > Conformance tests question > PM > > > > > > > > > > > > > > > > > > > > > Hello all > > I was performing conformance tests for the MEGACO according ETSI TS > 101 889-2 v1.1.1 (2002-08). I have a question regarding some of the > expected results appeared on this > tests: > On error tests (BI type) there are several tests that send request > with ContextID set to CHOOSE ($). The expected results on the tests > contain action reply with ContextID set to CHOOSE. Here is an example > for this tests : > > TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1 [3] clause > 7.2.1 Selection criteria: ROOT termination implemented Initial > condition: any Ensure that the IUT, on receipt of a Transaction > Request containing > * Action request with > o CID set to CHOOSE > o ADD Command request wi > sends a Transaction Reply containing > * Action reply with > o CID set to CHOOSE > o ADD Command reply wi > RO > > The H.248.1 v1 spec mandate that transaction reply may only contain a > specific ContextID, ALL (*), or NULL (-). > > Here's the relevant text from the H.248.1 v1 spec: > 8.2.2 TransactionReply > ... > The ContextID parameter must specify a value to pertain to all > Responses for the action. The ContextID may be specific, all or null. > > The following 19 items are the test cases with this requirement. > > 1. TP/MG/AD/BI-01 > 2. TP/MG/AC/BI-01 > 3. TP/MG/AC/BI-02 > 4. TP/MG/AC/BI-03 > 5. TP/MG/AC/BI-04 > 6. TP/MG/AV/BI-01 > 7. TP/MG/AV/BI-02 > 8. TP/MG/AV/BI-03 > 9. TP/MG/AV/BI-04 > 10. TP/MG/MD/BI-01 > 11. TP/MG/MD/BI-02 > 12. TP/MG/MD/BI-03 > 13. TP/MG/MD/BI-09 > 14. TP/MG/SU/BI-01 > 15. TP/MG/SU/BI-02 > 16. TP/MG/SU/BI-03 > 17. TP/MG/SU/BI-04 > 18. TP/MG/MV/BI-01 > 19. TP/MG/MV/BI-02 > > > Please help me to clear this issue. > > Thanks > > Seraya_______________________________________________ > Megaco mailing list > Megaco at ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 14 17:33:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiJ20-0004FW-Qq; Tue, 14 Jun 2005 17:33:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiJ1z-0004FO-0a for megaco@megatron.ietf.org; Tue, 14 Jun 2005 17:33:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08062 for ; Tue, 14 Jun 2005 17:33:08 -0400 (EDT) Received: from web50703.mail.yahoo.com ([206.190.38.101]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DiJOX-0003l8-15 for megaco@ietf.org; Tue, 14 Jun 2005 17:56:30 -0400 Received: (qmail 75149 invoked by uid 60001); 14 Jun 2005 21:32:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EXdC3YWJcXS8+GG3oCU09LmHIn8E1BVPSLSMGKeFfgmDczEyTy7c7M/dM4FGe2jFovUncqa3HI3e/88dhgXzTjK05pkVdnH6bJ84dh/0Joc+XOeiuzXAZZGJYAaPmiqq+WEO2nlqw4tJ/QS6fS9lTq1VEarxqms3apwTSC/HvXs= ; Message-ID: <20050614213258.75147.qmail@web50703.mail.yahoo.com> Received: from [161.44.182.103] by web50703.mail.yahoo.com via HTTP; Tue, 14 Jun 2005 14:32:58 PDT Date: Tue, 14 Jun 2005 14:32:58 -0700 (PDT) From: David Cherkus To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 8bit Subject: [Megaco] ServiceChange/Forced 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: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org The description of ServiceChange in 7.2.8 #2 says: Forced: indicates that the specified Terminations were taken abruptly out of service and any established connections associated with them may be lost. For non-Root terminations, the MGC is responsible for cleaning up the Context (if any) with which the failed Termination is associated. At a minimum, the Termination shall be subtracted from the Context. This last sentence seems ambiguous: is it saying (a) the MG must subtract the termination from the context, OR, (b) the MG should expect the MGC to issue a command that will subtract the termination from the context? I would have guessed (b) based just on the text I've quoted, but one could guess (a) expecially if you read the rest of the paragraph. Thanks, Dave _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 14 17:40:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiJ9W-00052X-2Z; Tue, 14 Jun 2005 17:40:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiJ9U-00052S-D9 for megaco@megatron.ietf.org; Tue, 14 Jun 2005 17:40:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08362 for ; Tue, 14 Jun 2005 17:40:54 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiJW2-00048c-RO for megaco@ietf.org; Tue, 14 Jun 2005 18:04:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Conformance tests question Date: Tue, 14 Jun 2005 17:40:44 -0400 Message-ID: Thread-Topic: [Megaco] Conformance tests question Thread-Index: AcVxIx4/PkM0dXKwS4qOLJhKO6w2lQABh3GA From: "Steve Cipolli" To: "Kevin Boyle" , "Frank Reno" , X-Spam-Score: 0.6 (/) X-Scan-Signature: 0cc6ce33a3e165c84359672fc0328059 Cc: 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="===============1234376224==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1234376224== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57129.B83C72CC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57129.B83C72CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 As the original poster pointed out, 8.2.2 says: =20 8.2.2 TransactionReply =20 ... The ContextID parameter must specify a value to pertain to all Responses for the action. The ContextID may be specific, all or null. =20 --Stephen -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com]=20 Sent: Tuesday, June 14, 2005 4:53 PM To: Steve Cipolli; Frank Reno; megaco@ietf.org Subject: RE: [Megaco] Conformance tests question =09 =09 Where do you see that restriction?=20 Kevin=20 -----Original Message-----=20 From: Steve Cipolli [mailto:SCipolli@radvision.com]=20 Sent: Tuesday, June 14, 2005 2:21 PM=20 To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org=20 Subject: RE: [Megaco] Conformance tests question=20 Kevin,=20 Allowing '$' for context in replies also violates v1 and v2, so it appears there is no solution at all for v1 and v2. Do you mean that the IG for v1 and v2 should be updated to allow '$' for context in replies? --Stephen=20 > -----Original Message-----=20 > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org] On Behalf Of Kevin Boyle=20 > Sent: Tuesday, June 14, 2005 12:36 PM=20 > To: Frank Reno; megaco@ietf.org=20 > Subject: RE: [Megaco] Conformance tests question=20 >=20 >=20 > This seems like a problem with the syntax of the protocol. =20 > Since we clearly allow error descriptors at the action level, and we=20 > allow following errors at the transaction and command levels, this=20 > appears to need fixing. It appears that the binary encoding allows an=20 > error at the action level for the second (or subsequent) action in a=20 > transaction.=20 >=20 > The fix itself would be straightforward, though non-backwards=20 > compatible. This would mean that it would have to be in V3, and not=20 > made retroactive to V1 and V2. The fix would be:=20 >=20 > transactionReply =3D ReplyToken EQUAL TransactionID LBRKT=20 > [ImmAckRequiredToken COMMA](errorDescriptor /=20 > actionReplyList [COMMA errorDescriptor]) RBRKT Fix=20 > is here------------------------^^^^^^^^^^^^^^^^^^^^^^^=20 >=20 > So, for V1 and V2, it would appear that your solution, though=20 > suboptimal in my view, is the only solution available within the=20 > syntax as defined.=20 >=20 > Kevin=20 > =20 >=20 > -----Original Message-----=20 > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org] On Behalf Of Frank Reno=20 > Sent: Friday, June 10, 2005 3:49 PM=20 > To: megaco@ietf.org=20 > Subject: RE: [Megaco] Conformance tests question=20 >=20 > If an action fails with a context ID of CHOOSE and it is not the first=20 > action in the transaction, then the error can't be placed at the=20 > action level, since the grammar does not permit action replies and an=20 > action level error descriptor in the same transaction reply.=20 >=20 > So it looks like CHOOSE should be allowed in the reply.=20 >=20 > Given=20 >=20 > T =3D 1=20 > {=20 > C =3D 1 { Add =3D t1 },=20 > C =3D $ { Add =3D t2 }=20 > }=20 >=20 > This is not legal:=20 >=20 > Reply =3D 1=20 > {=20 > C =3D 1 { Add =3D t1 },=20 > Error =3D 412 {}=20 > }=20 >=20 > So it would have to be:=20 >=20 > Reply =3D 1=20 > {=20 > C =3D 1 { Add =3D t1 },=20 > C =3D $ { Error =3D 412 {}}=20 > }=20 >=20 > Frank=20 >=20 >=20 >=20 > --- Kevin Boyle wrote:=20 >=20 > In most cases, the MG knows it cannot allocate a context at the time=20 > the request is detected -- that is, once the action is parsed. If the=20 > MG detects a problem, why would it continue to parse?=20 > The error descriptor=20 > ought to be placed at the action level, so there would not be a=20 > context indicated of any kind, let alone a CHOOSE wildcard.=20 >=20 > Remember, error detection occurs at the earliest possible time with=20 > the error descriptor occurring at the level of detection.=20 > If the MG was not=20 > able to detect that it was unable to allocate a context until the=20 > command or descriptor level, then the error descriptor would go at the=20 > lower level.=20 >=20 > Kevin=20 >=20 > -----Original Message-----=20 > From: megaco-bounces at ietf.org=20 > [mailto:megaco-bounces at ietf.org] On Behalf Of B Venkat S.R Swamy=20 > Sent: Thursday, May 26, 2005 8:25 AM=20 > To: Seraya.Miletzki at ecitele.com=20 > Cc: megaco at ietf.org=20 > Subject: Re: [Megaco] Conformance tests question=20 >=20 >=20 >=20 >=20 >=20 >=20 > Hi=20 >=20 > IMO it is perfectly valid to specify CHOOSE for contextID in response=20 > to the test cases you have mentioned below. As far as the protocol=20 > text you have mentioned it applies mostly to those scenario where you=20 > a valid context Id(includes wildcard=20 > also) or Null context. Where MG has never been able to create a=20 > context why should it return any other value.=20 >=20 > Even the ABNF and ASN grammar in Appendix does not put any limitation=20 > on the set of values that can be used in the Reply messages.=20 >=20 > I however do agree that the relevant text should be modified to=20 > clarify these scenario and request authors to take this in IG or=20 > upcoming V3 document.=20 >=20 > regards=20 > B Venkat S.R Swamy=20 > Senior Technical Leader=20 > Flextronics Software Systems=20 > Phone: +91-124-2455555 Extn 3620=20 > Fax: +91-124-2455345=20 > web: www.hssworld.com=20 >=20 >=20 >=20 >=20 >=20 > =20 > =20 > Seraya.Miletzki at e =20 > =20 > citele.com =20 > =20 > Sent by: =20 > To=20 > megaco-bounces at ie megaco at=20 > ietf.org =20 > tf.org =20 > cc=20 > =20 > =20 > =20 > Subject=20 > 05/26/2005 05:17 [Megaco]=20 > Conformance tests question=20 > PM =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Hello all=20 >=20 > I was performing conformance tests for the MEGACO according ETSI TS=20 > 101 889-2 v1.1.1 (2002-08). I have a question regarding some of the=20 > expected results appeared on this=20 > tests:=20 > On error tests (BI type) there are several tests that send request=20 > with ContextID set to CHOOSE ($). The expected results on the tests=20 > contain action reply with ContextID set to CHOOSE. Here is an example=20 > for this tests :=20 >=20 > TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1 [3] clause=20 > 7.2.1 Selection criteria: ROOT termination implemented Initial > condition: any Ensure that the IUT, on receipt of a Transaction=20 > Request containing=20 > * Action request with=20 > o CID set to CHOOSE=20 > o ADD Command request wi=20 > sends a Transaction Reply containing=20 > * Action reply with=20 > o CID set to CHOOSE=20 > o ADD Command reply wi=20 > RO=20 >=20 > The H.248.1 v1 spec mandate that transaction reply may only contain a=20 > specific ContextID, ALL (*), or NULL (-).=20 >=20 > Here's the relevant text from the H.248.1 v1 spec:=20 > 8.2.2 TransactionReply=20 > ...=20 > The ContextID parameter must specify a value to pertain to all > Responses for the action. The ContextID may be specific, all or null.=20 >=20 > The following 19 items are the test cases with this requirement.=20 >=20 > 1. TP/MG/AD/BI-01=20 > 2. TP/MG/AC/BI-01=20 > 3. TP/MG/AC/BI-02=20 > 4. TP/MG/AC/BI-03=20 > 5. TP/MG/AC/BI-04=20 > 6. TP/MG/AV/BI-01=20 > 7. TP/MG/AV/BI-02=20 > 8. TP/MG/AV/BI-03=20 > 9. TP/MG/AV/BI-04=20 > 10. TP/MG/MD/BI-01=20 > 11. TP/MG/MD/BI-02=20 > 12. TP/MG/MD/BI-03=20 > 13. TP/MG/MD/BI-09=20 > 14. TP/MG/SU/BI-01=20 > 15. TP/MG/SU/BI-02=20 > 16. TP/MG/SU/BI-03=20 > 17. TP/MG/SU/BI-04=20 > 18. TP/MG/MV/BI-01=20 > 19. TP/MG/MV/BI-02=20 >=20 >=20 > Please help me to clear this issue.=20 >=20 > Thanks=20 >=20 > Seraya_______________________________________________=20 > Megaco mailing list=20 > Megaco at ietf.org https://www1.ietf.org/mailman/listinfo/megaco=20 >=20 > __________________________________________________=20 > Do You Yahoo!?=20 > Tired of spam? Yahoo! Mail has the best spam protection around=20 > http://mail.yahoo.com=20 >=20 > _______________________________________________=20 > Megaco mailing list=20 > Megaco@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/megaco=20 >=20 >=20 > _______________________________________________=20 > Megaco mailing list=20 > Megaco@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/megaco=20 >=20 >=20 >=20 ------_=_NextPart_001_01C57129.B83C72CC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
As the = original=20 poster pointed out, 8.2.2 says:
 
8.2.2=20 TransactionReply
 
...
The ContextID = parameter=20 must specify a value to pertain to all Responses for the action. The = ContextID=20 may be specific, all or null.
 
--Stephen
-----Original Message-----
From: = Kevin Boyle=20 [mailto:kboyle@nortel.com]
Sent: Tuesday, June 14, 2005 = 4:53=20 PM
To: Steve Cipolli; Frank Reno; = megaco@ietf.org
Subject:=20 RE: [Megaco] Conformance tests question

Where do you see that restriction?

Kevin

-----Original Message-----
From: Steve=20 Cipolli [mailto:SCipolli@radvision.com]= =20
Sent: Tuesday, June 14, 2005 2:21 PM =
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; = megaco@ietf.org=20
Subject: RE: [Megaco] Conformance tests = question

Kevin,

Allowing '$' for context in replies also violates v1 = and v2,=20 so it appears there is no solution at all for v1 and v2.  Do you = mean=20 that the IG for v1 and v2 should be updated to allow '$' for context = in=20 replies?

--Stephen

> -----Original Message-----
>=20 From: megaco-bounces@ietf.org
> [mailto:megaco-bounces@ietf.org] On=20 Behalf Of Kevin Boyle
> Sent: Tuesday, = June 14,=20 2005 12:36 PM
> To: Frank Reno;=20 megaco@ietf.org
> Subject: RE: [Megaco] = Conformance=20 tests question
>
>=20
> This seems like a problem with the = syntax of the=20 protocol. 
> Since we clearly allow = error=20 descriptors at the action level, and we
> = allow=20 following errors at the transaction and command levels, this =
> appears to need fixing.  It appears that the binary = encoding=20 allows an
> error at the action level for = the=20 second (or subsequent) action in a
>=20 transaction.
>
> The fix=20 itself would be straightforward, though non-backwards
> compatible. This would mean that it would have to be in = V3, and=20 not
> made retroactive to V1 and = V2.  The fix=20 would be:
>
>=20 transactionReply =3D ReplyToken EQUAL TransactionID LBRKT =
>          =          =20 [ImmAckRequiredToken COMMA](errorDescriptor /
>          =          =20 actionReplyList [COMMA errorDescriptor]) RBRKT Fix
> is = here------------------------^^^^^^^^^^^^^^^^^^^^^^^=20
>
> So, for V1 and = V2, it would=20 appear that your solution, though
> = suboptimal in=20 my view, is the only solution available within the
> syntax as defined.
> =
> Kevin
>  =
>
> -----Original = Message-----=20
> From: megaco-bounces@ietf.org
> [mailto:megaco-bounces@ietf.org] On=20 Behalf Of Frank Reno
> Sent: Friday, June = 10, 2005=20 3:49 PM
> To: megaco@ietf.org =
> Subject: RE: [Megaco] Conformance tests question =
>
> If an action fails with a = context ID=20 of CHOOSE and it is not the first
> = action in the=20 transaction, then the error can't be placed at the
> action level, since the grammar does not permit action = replies and=20 an
> action level error descriptor in the = same=20 transaction reply.
>
>=20 So it looks like CHOOSE should be allowed in the reply. =
>
> Given
>=20
> T =3D 1
> = {=20
>     C =3D 1 { Add =3D t1 = },=20
>     C =3D $ { Add =3D t2 = }=20
> }
> =
> This is not legal:
> =
> Reply =3D 1
> { =
>     C =3D 1 { Add =3D t1 }, =
>     Error =3D 412 {} =
> }
>
> So it=20 would have to be:
>
>=20 Reply =3D 1
> {
>     C =3D 1 { Add =3D t1 }, =
>     C =3D $ { Error =3D 412 = {}}
> }
>
>=20 Frank
>
>=20
>
> --- = Kevin Boyle=20 <kboyle at nortel.com> wrote:
>=20
> In most cases, the MG knows it cannot = allocate a=20 context at the time
> the request is = detected --=20 that is, once the action is parsed.  If the
>=20 MG detects a problem, why would it continue to parse?
> The error descriptor
> = ought to be=20 placed at the action level, so there would not be a
> context indicated of any kind, let alone a CHOOSE = wildcard.=20
>
> Remember, error = detection=20 occurs at the earliest possible time with
> the=20 error descriptor occurring at the level of detection.
> If the MG was not
> able to = detect that=20 it was unable to allocate a context until the
>=20 command or descriptor level, then the error descriptor would go at the =
> lower level.
>=20
> Kevin
>=20
> -----Original Message----- =
> From: megaco-bounces at ietf.org
> [mailto:megaco-bounces at ietf.org] = On Behalf=20 Of B Venkat S.R Swamy
> Sent: Thursday, = May 26,=20 2005 8:25 AM
> To: Seraya.Miletzki at=20 ecitele.com
> Cc: megaco at = ietf.org=20
> Subject: Re: [Megaco] Conformance tests = question=20
>
> =
>
>
>=20
>
> = Hi
>
> IMO it is perfectly valid = to specify=20 CHOOSE for contextID in response
> to the = test=20 cases you have mentioned below.  As far as the protocol =
> text you have mentioned it applies mostly to those = scenario where=20 you
> a valid context Id(includes = wildcard=20
> also) or Null context. Where MG has never been = able to=20 create a
> context why should it return = any other=20 value.
>
> = Even the ABNF=20 and ASN grammar in Appendix does not put any limitation =
> on the set of values that can be used in the Reply=20 messages.
>
> I however=20 do agree that the relevant text should be modified to
> clarify these scenario and request authors to take this = in IG or=20
> upcoming V3 document.
>
> regards
>=20 B Venkat S.R Swamy
> Senior Technical = Leader=20
> Flextronics Software Systems
> Phone:  +91-124-2455555 Extn 3620
> Fax: +91-124-2455345
> web: = www.hssworld.com
>
>=20
>
> =
>
>          =             &= nbsp;           &n= bsp;           &nb= sp;       =20
>          =           =20
>          =    =20 Seraya.Miletzki at=20 = e            =         =20
>          =             &= nbsp;=20
>          =    =20 = citele.com          &nb= sp;           &nbs= p;       =20
>          =           =20
>          =    =20 Sent=20 = by:           &nbs= p;            = ;        =20
>          =        =20 To
>          =    =20 megaco-bounces at ie         = megaco=20 at
>=20 = ietf.org           = ;         =20
>          =    =20 = tf.org           &= nbsp;           &n= bsp;          =20
>          =        =20 cc
>          =             &= nbsp;           &n= bsp;           &nb= sp;       =20
>          =           =20
>          =             &= nbsp;           &n= bsp;           &nb= sp;       =20
>          =   =20 Subject
>          =    =20 05/26/2005 05:17          = [Megaco]
> Conformance tests question=20
>          =    =20 = PM            = ;            =             &= nbsp; =20
>          =           =20
>          =             &= nbsp;           &n= bsp;           &nb= sp;       =20
>          =           =20
>          =             &= nbsp;           &n= bsp;           &nb= sp;       =20
>          =           =20
>          =             &= nbsp;           &n= bsp;           &nb= sp;       =20
>          =           =20
>          =             &= nbsp;           &n= bsp;           &nb= sp;       =20
>          =           =20
>          =             &= nbsp;           &n= bsp;           &nb= sp;       =20
>          =           =20
>
> =
>
>
>=20
>
> =
>
>
> Hello=20 all
>
> I = was performing=20 conformance tests for the MEGACO according ETSI TS
> 101 889-2 v1.1.1 (2002-08). I have a question regarding = some of=20 the
> expected results appeared on = this=20
> tests:
> On error = tests (BI=20 type) there are several tests that send request
>=20 with ContextID set to CHOOSE ($). The expected results on the tests=20
> contain action reply with ContextID set = to=20 CHOOSE. Here is an example
> for this = tests=20 :
>
> = TP/MG/AD/BI-01=20 Reference: ITU-T Recommendation H.248.1 [3] clause
> 7.2.1 Selection criteria: ROOT termination implemented = Initial=20
> condition: any Ensure that the IUT, on = receipt of=20 a Transaction
> Request containing =
>       * Action request = with=20
>          =   =20 o CID set to CHOOSE
>          =   =20 o ADD Command request wi
> sends a = Transaction=20 Reply containing
>       * Action reply = with=20
>          =   =20 o CID set to CHOOSE
>          =   =20 o ADD Command reply wi
> RO =
>
> The H.248.1 v1 spec = mandate that=20 transaction reply may only contain a
> = specific=20 ContextID, ALL (*), or NULL (-).
> =
> Here's the relevant text from the H.248.1 v1 = spec:=20
> 8.2.2     = TransactionReply=20
> ...
> The = ContextID parameter=20 must specify a value to pertain to all
> = Responses=20 for the action. The ContextID may be specific, all or null. =
>
> The following 19 items = are the test=20 cases with this requirement.
> =
> 1.    TP/MG/AD/BI-01
>=20 2.    TP/MG/AC/BI-01
>=20 3.    TP/MG/AC/BI-02
>=20 4.    TP/MG/AC/BI-03
>=20 5.    TP/MG/AC/BI-04
>=20 6.    TP/MG/AV/BI-01
>=20 7.    TP/MG/AV/BI-02
>=20 8.    TP/MG/AV/BI-03
>=20 9.    TP/MG/AV/BI-04
>=20 10.   TP/MG/MD/BI-01
> = 11.  =20 TP/MG/MD/BI-02
> 12.  =20 TP/MG/MD/BI-03
> 13.  =20 TP/MG/MD/BI-09
> 14.  =20 TP/MG/SU/BI-01
> 15.  =20 TP/MG/SU/BI-02
> 16.  =20 TP/MG/SU/BI-03
> 17.  =20 TP/MG/SU/BI-04
> 18.  =20 TP/MG/MV/BI-01
> 19.  =20 TP/MG/MV/BI-02
>
>=20
> Please help me to clear this = issue.=20
>
> Thanks =
>
>=20 Seraya_______________________________________________
> Megaco mailing list
> = Megaco at=20 ietf.org https://www1.ietf.org/mailman/listinfo/megaco =
>
>=20 __________________________________________________
> Do You Yahoo!?
> Tired of = spam? =20 Yahoo! Mail has the best spam protection around
>=20 http://mail.yahoo.com=20
>
>=20 _______________________________________________
>=20 Megaco mailing list
> = Megaco@ietf.org=20
> https://www1.ietf.org/mailman/listinfo/megaco =
>
> =
> _______________________________________________ =
> Megaco mailing list
>=20 Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco =
>
> =
>

------_=_NextPart_001_01C57129.B83C72CC-- --===============1234376224== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1234376224==-- From megaco-bounces@ietf.org Tue Jun 14 19:29:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiKqn-0005oH-GP; Tue, 14 Jun 2005 19:29:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiKql-0005o3-3f for megaco@megatron.ietf.org; Tue, 14 Jun 2005 19:29:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18169 for ; Tue, 14 Jun 2005 19:29:39 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiLDH-0002k4-Kw for megaco@ietf.org; Tue, 14 Jun 2005 19:53:03 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F1F52A99; Wed, 15 Jun 2005 01:29:19 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 01:29:18 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 01:29:17 +0200 Received: from [146.11.22.15] (EG2E500202DSEGL [146.11.22.15]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MLXTP1K3; Wed, 15 Jun 2005 09:29:13 +1000 Message-ID: <42AF6870.9000800@ericsson.com> Date: Wed, 15 Jun 2005 09:29:52 +1000 X-Sybari-Trust: fb25f0e7 3280b041 ccfcc74e 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: megaco@ietf.org Subject: Re: [Megaco] Emergency flag References: <34B3EAA5B3066A42914D28C5ECF5FEA402732763@zrtphxm2> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA402732763@zrtphxm2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2005 23:29:17.0440 (UTC) FILETIME=[E20AE800:01C57138] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello, Just to clarify the EmergencyOff was added to the syntax for the return on Audits and thus did not cause interop problems as it would be ignored if not understood (eg. no error reply). Christian Kevin Boyle wrote: > Yes, a new token (EmergencyOff) was introduced into the IG for V1 and V2 > and > into V3 to combat this very problem. Since this was seen as a critical > problem in the syntax, it was allowed as an IG entry, even though it > alters > the syntax. > > Kevin > > -----Original Message----- > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf > Of > Frank Reno > Sent: Thursday, June 09, 2005 5:48 PM > To: megaco@ietf.org > Subject: [Megaco] Emergency flag > > Is there any way to remove the emergency status of a context in text > mode? > > Binary mode supports three states: either the emergency flag is absent, > true > or false. In text mode it can only be absent or true. > > Frank > > > > __________________________________ > Discover Yahoo! > Stay in touch with email, IM, photo sharing and more. Check it out! > http://discover.yahoo.com/stayintouch.html > > _______________________________________________ > Megaco mailing 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 Jun 15 01:53:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiQpo-0007z1-Hp; Wed, 15 Jun 2005 01:53:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiQpl-0007yt-6u for megaco@megatron.ietf.org; Wed, 15 Jun 2005 01:53:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09152 for ; Wed, 15 Jun 2005 01:53:03 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DiRCN-0007MI-5N for megaco@ietf.org; Wed, 15 Jun 2005 02:16:28 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1118769128; Wed Jun 15 08:53:13 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Wed, 15 Jun 2005 08:55:58 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D310A@MAILSERVER> From: Raphael Tryster To: "'David Cherkus'" , megaco@ietf.org Subject: RE: [Megaco] ServiceChange/Forced Question Date: Wed, 15 Jun 2005 08:55:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.5 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: 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="===============1521313683==" 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. --===============1521313683== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57177.44DF50E0" 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_01C57177.44DF50E0 Content-Type: text/plain; charset="iso-8859-1" The answer is b). This is what Kevin Boyle wrote about it on the 6th of November 2003: The MG is specifically prohibited from altering terminations or contexts without MGC direction. Because of this prohibition, the MGC MUST intervene to clean up any contexts that existed at the time of communications loss. The only exception to this is if the MG undergoes a Cold Boot, at which time the MGC can assume that all state is lost and the MG is in a newly started state. Raphael Tryster -----Original Message----- From: David Cherkus [mailto:dcherkus@yahoo.com] Sent: Tuesday, June 14, 2005 11:33 PM To: megaco@ietf.org Subject: [Megaco] ServiceChange/Forced Question The description of ServiceChange in 7.2.8 #2 says: Forced: indicates that the specified Terminations were taken abruptly out of service and any established connections associated with them may be lost. For non-Root terminations, the MGC is responsible for cleaning up the Context (if any) with which the failed Termination is associated. At a minimum, the Termination shall be subtracted from the Context. This last sentence seems ambiguous: is it saying (a) the MG must subtract the termination from the context, OR, (b) the MG should expect the MGC to issue a command that will subtract the termination from the context? I would have guessed (b) based just on the text I've quoted, but one could guess (a) expecially if you read the rest of the paragraph. Thanks, Dave _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C57177.44DF50E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] ServiceChange/Forced Question

The answer is b).  This is what Kevin Boyle wrote = about it on the 6th of November 2003:

The MG is specifically prohibited from altering termina= tions or contexts
without MGC direction.  Because of this prohibiti= on, the MGC MUST intervene
to clean up any contexts that existed at the time of c= ommunications loss.
The only exception to this is if the MG undergoes a Co= ld Boot, at which time
the MGC can assume that all state is lost and the MG i= s in a newly started
state.


Raphael Tryster


-----Original Message-----
From: David Cherkus [mailto:dcherkus@yahoo.com]
Sent: Tuesday, June 14, 2005 11:33 PM
To: megaco@ietf.org
Subject: [Megaco] ServiceChange/Forced Question

The description of ServiceChange in 7.2.8 #2 says:

Forced: indicates that the specified Terminations were = taken abruptly
out of service and any established connections associa= ted with them may
be lost. For non-Root terminations, the MGC is respons= ible for cleaning
up the Context (if any) with which the failed Terminat= ion is
associated. At a minimum, the Termination shall be sub= tracted from the
Context.

This last sentence seems ambiguous: is it saying (a) th= e MG must
subtract the termination from the context, OR, (b) the= MG should expect
the MGC to issue a command that will subtract the term= ination from
the context?

I would have guessed (b) based just on the text I've qu= oted, but one
could guess (a) expecially if you read the rest of the= paragraph.

Thanks,
Dave


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

------_=_NextPart_001_01C57177.44DF50E0-- --===============1521313683== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1521313683==-- From megaco-bounces@ietf.org Wed Jun 15 09:40:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiY7r-0000eF-5D; Wed, 15 Jun 2005 09:40:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiY7o-0000e9-Ap for megaco@megatron.ietf.org; Wed, 15 Jun 2005 09:40:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15984 for ; Wed, 15 Jun 2005 09:40:09 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiYUS-0000ZM-Uf for megaco@ietf.org; Wed, 15 Jun 2005 10:03:39 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5FDdnC06285 for ; Wed, 15 Jun 2005 09:39:49 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jun 2005 09:39:49 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4027BD0E2@zrtphxm2> From: "Kevin Boyle" To: Steve Cipolli , Frank Reno , megaco@ietf.org Subject: RE: [Megaco] Conformance tests question Date: Wed, 15 Jun 2005 09:39:33 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: 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 Well, the two choices are: 1) lift this restriction in the text for the particular case of an error response for a second action in a transaction; or 2) change the ABNF syntax of the protocol. I believe the better choice for V1 and V2 is to do the former, since no parsing changes will be required. For V3 we should choose the latter, since this appears to be an oversight in the grammar. Kevin _____ From: Steve Cipolli [mailto:SCipolli@radvision.com] Sent: Tuesday, June 14, 2005 5:41 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org Subject: RE: [Megaco] Conformance tests question As the original poster pointed out, 8.2.2 says: 8.2.2 TransactionReply ... The ContextID parameter must specify a value to pertain to all Responses for the action. The ContextID may be specific, all or null. --Stephen -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Tuesday, June 14, 2005 4:53 PM To: Steve Cipolli; Frank Reno; megaco@ietf.org Subject: RE: [Megaco] Conformance tests question Where do you see that restriction? Kevin -----Original Message----- From: Steve Cipolli [mailto:SCipolli@radvision.com ] Sent: Tuesday, June 14, 2005 2:21 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org Subject: RE: [Megaco] Conformance tests question Kevin, Allowing '$' for context in replies also violates v1 and v2, so it appears there is no solution at all for v1 and v2. Do you mean that the IG for v1 and v2 should be updated to allow '$' for context in replies? --Stephen > -----Original Message----- > From: megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org ] On Behalf Of Kevin Boyle > Sent: Tuesday, June 14, 2005 12:36 PM > To: Frank Reno; megaco@ietf.org > Subject: RE: [Megaco] Conformance tests question > > > This seems like a problem with the syntax of the protocol. > Since we clearly allow error descriptors at the action level, and we > allow following errors at the transaction and command levels, this > appears to need fixing. It appears that the binary encoding allows an > error at the action level for the second (or subsequent) action in a > transaction. > > The fix itself would be straightforward, though non-backwards > compatible. This would mean that it would have to be in V3, and not > made retroactive to V1 and V2. The fix would be: > > transactionReply = ReplyToken EQUAL TransactionID LBRKT > [ImmAckRequiredToken COMMA](errorDescriptor / > actionReplyList [COMMA errorDescriptor]) RBRKT Fix > is here------------------------^^^^^^^^^^^^^^^^^^^^^^^ > > So, for V1 and V2, it would appear that your solution, though > suboptimal in my view, is the only solution available within the > syntax as defined. > > Kevin > > > -----Original Message----- > From: megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org ] On Behalf Of Frank Reno > Sent: Friday, June 10, 2005 3:49 PM > To: megaco@ietf.org > Subject: RE: [Megaco] Conformance tests question > > If an action fails with a context ID of CHOOSE and it is not the first > action in the transaction, then the error can't be placed at the > action level, since the grammar does not permit action replies and an > action level error descriptor in the same transaction reply. > > So it looks like CHOOSE should be allowed in the reply. > > Given > > T = 1 > { > C = 1 { Add = t1 }, > C = $ { Add = t2 } > } > > This is not legal: > > Reply = 1 > { > C = 1 { Add = t1 }, > Error = 412 {} > } > > So it would have to be: > > Reply = 1 > { > C = 1 { Add = t1 }, > C = $ { Error = 412 {}} > } > > Frank > > > > --- Kevin Boyle wrote: > > In most cases, the MG knows it cannot allocate a context at the time > the request is detected -- that is, once the action is parsed. If the > MG detects a problem, why would it continue to parse? > The error descriptor > ought to be placed at the action level, so there would not be a > context indicated of any kind, let alone a CHOOSE wildcard. > > Remember, error detection occurs at the earliest possible time with > the error descriptor occurring at the level of detection. > If the MG was not > able to detect that it was unable to allocate a context until the > command or descriptor level, then the error descriptor would go at the > lower level. > > Kevin > > -----Original Message----- > From: megaco-bounces at ietf.org > [mailto:megaco-bounces at ietf.org] On Behalf Of B Venkat S.R Swamy > Sent: Thursday, May 26, 2005 8:25 AM > To: Seraya.Miletzki at ecitele.com > Cc: megaco at ietf.org > Subject: Re: [Megaco] Conformance tests question > > > > > > > Hi > > IMO it is perfectly valid to specify CHOOSE for contextID in response > to the test cases you have mentioned below. As far as the protocol > text you have mentioned it applies mostly to those scenario where you > a valid context Id(includes wildcard > also) or Null context. Where MG has never been able to create a > context why should it return any other value. > > Even the ABNF and ASN grammar in Appendix does not put any limitation > on the set of values that can be used in the Reply messages. > > I however do agree that the relevant text should be modified to > clarify these scenario and request authors to take this in IG or > upcoming V3 document. > > regards > B Venkat S.R Swamy > Senior Technical Leader > Flextronics Software Systems > Phone: +91-124-2455555 Extn 3620 > Fax: +91-124-2455345 > web: www.hssworld.com > > > > > > > > Seraya.Miletzki at e > > citele.com > > Sent by: > To > megaco-bounces at ie megaco at > ietf.org > tf.org > cc > > > > Subject > 05/26/2005 05:17 [Megaco] > Conformance tests question > PM > > > > > > > > > > > > > > > > > > > > > Hello all > > I was performing conformance tests for the MEGACO according ETSI TS > 101 889-2 v1.1.1 (2002-08). I have a question regarding some of the > expected results appeared on this > tests: > On error tests (BI type) there are several tests that send request > with ContextID set to CHOOSE ($). The expected results on the tests > contain action reply with ContextID set to CHOOSE. Here is an example > for this tests : > > TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1 [3] clause > 7.2.1 Selection criteria: ROOT termination implemented Initial > condition: any Ensure that the IUT, on receipt of a Transaction > Request containing > * Action request with > o CID set to CHOOSE > o ADD Command request wi > sends a Transaction Reply containing > * Action reply with > o CID set to CHOOSE > o ADD Command reply wi > RO > > The H.248.1 v1 spec mandate that transaction reply may only contain a > specific ContextID, ALL (*), or NULL (-). > > Here's the relevant text from the H.248.1 v1 spec: > 8.2.2 TransactionReply > ... > The ContextID parameter must specify a value to pertain to all > Responses for the action. The ContextID may be specific, all or null. > > The following 19 items are the test cases with this requirement. > > 1. TP/MG/AD/BI-01 > 2. TP/MG/AC/BI-01 > 3. TP/MG/AC/BI-02 > 4. TP/MG/AC/BI-03 > 5. TP/MG/AC/BI-04 > 6. TP/MG/AV/BI-01 > 7. TP/MG/AV/BI-02 > 8. TP/MG/AV/BI-03 > 9. TP/MG/AV/BI-04 > 10. TP/MG/MD/BI-01 > 11. TP/MG/MD/BI-02 > 12. TP/MG/MD/BI-03 > 13. TP/MG/MD/BI-09 > 14. TP/MG/SU/BI-01 > 15. TP/MG/SU/BI-02 > 16. TP/MG/SU/BI-03 > 17. TP/MG/SU/BI-04 > 18. TP/MG/MV/BI-01 > 19. TP/MG/MV/BI-02 > > > Please help me to clear this issue. > > Thanks > > Seraya_______________________________________________ > Megaco mailing list > Megaco at ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Jun 15 10:45:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiZ9M-0007fG-1B; Wed, 15 Jun 2005 10:45:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiZ9K-0007ev-5H for megaco@megatron.ietf.org; Wed, 15 Jun 2005 10:45:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23390 for ; Wed, 15 Jun 2005 10:45:45 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiZVz-0004om-Sq for megaco@ietf.org; Wed, 15 Jun 2005 11:09:16 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j5FEiUV29617 for ; Wed, 15 Jun 2005 10:44:30 -0400 (EDT) Received: from [127.0.0.1] (acart22d.ca.nortel.com [47.130.25.22]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MRAFNXSM; Wed, 15 Jun 2005 10:45:28 -0400 Message-ID: <42B03F02.5050503@nortel.com> Date: Wed, 15 Jun 2005 10:45:22 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [Megaco] Expert review of requests for new packages X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org It may be a bit late to get anything done about this question in v3, but perhaps all we need is a consensus agreement on the list. I am the designated expert for review of requests to register new packages with IANA. The question is what criteria I apply to new public packages. Is the intent that: (a) I ensure that the formal requirements as currently specified in Megaco/H.248 documentation are satisfied, or (b) do I have the responsibility to require clarification of substantive items in the document that seem unclear, or (c) do I have authority to at least question the content of proposed packages in a broader way? If my responsibility goes beyond (a), groups that are preparing Megaco/H.248 packages will have to get IANA and thus me involved before their documents are set in concrete. Looking forward to your comments. Tom Taylor _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Jun 15 16:38:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DieeZ-00005p-CF; Wed, 15 Jun 2005 16:38:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DieeX-00004u-Up for megaco@megatron.ietf.org; Wed, 15 Jun 2005 16:38:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01724 for ; Wed, 15 Jun 2005 16:38:22 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dif1G-0003eY-NR for megaco@ietf.org; Wed, 15 Jun 2005 17:01:55 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j5FKauV11157 for ; Wed, 15 Jun 2005 16:36:56 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jun 2005 16:37:52 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402849C8C@zrtphxm2> From: "Kevin Boyle" To: Jon Rowland , Rajkumar Nair , megaco@ietf.org Subject: RE: [Megaco] EventBufferDescriptor and EventDescriptor!! Date: Wed, 15 Jun 2005 16:37:42 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: 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 While editing the doc and thinking some more about this discussion, I have found that I must concede. I believe you are correct, and that the buffering does not occur until the current Events Descriptor has matched. The text in particular that got my attention is: "The EventBufferControl Property specifies whether events are buffered following detection of an event in the Events Descriptor, or processed immediately. See 7.1.9 for details." This text is in section 7.1.5, "TerminationState Descriptor". So the intent is there that the enforcement of buffering not occur until the currently active Events Descriptor matches. You are right, and I was wrong. I will see if I can get some better wording put around this to make it clear that the buffering only comes into effect while there is not an active Events Descriptor. Kevin _____ From: Jon Rowland [mailto:Jon.Rowland@dataconnection.com] Sent: Thursday, April 21, 2005 12:44 PM To: Jon Rowland; Boyle, Kevin [NCRTP:3Z40:EXCH]; Rajkumar Nair; megaco@ietf.org Subject: RE: [Megaco] EventBufferDescriptor and EventDescriptor!! Kevin, I'm not proposing there should be exceptions in particular cases. I'm trying to define how the interaction of the event descriptor and the event buffer descriptor works in general. I can see nothing in the spec that backs up your assertion that the event buffer filters events while there is an active event descriptor. Indeed, I can see statements suggesting the opposite: - Paragraph 5 of 7.1.9 says "... following detection of such an event [as per the mechanism in the previous paragraph] normal handling of events is suspended. [i.e. prior to this, when there is an active events descriptor, handling of events _is_ normal] Any event which is _subsequently_ detected and occurs in the eventbuffer descriptor is added to the end of the eventbuffer FIFO queue..." - Same section, case 1, 1) says "If the eventbuffer is empty [no events detected and put on FIFO queue], the MG waits for detection of events based on the new events descriptor..." This is all self-consistent. The eventbuffer buffers events while there is no active event descriptor. When a new event descriptor is applied, if there are buffered events, then they instantaneously match the events descriptor and the event descriptor is instantly disabled. There is logically no period when there is an active events descriptor when new events can be detected, so the issue of whether they should match the event descriptor is irrelevant. In this case, until the FIFO is empty, all events that match the event buffer will be buffered, because there is never an active events descriptor when a new event is detected. When the FIFO is empty, then there can be a persistent active event descriptor, and so newly detected events will be matched directly against that - the event buffer does not come into play in this case. The spec is quite clear that the event buffer only comes into play once normal event detection has been suspended. My assertion and example below therefore stands, and is not a special case - note that this is not necessarily the point where event detection enters lockstep mode - in my first bullet point in the example below, there could already have been an active events descriptor in lockstep mode. This is in line with all the H.248 implementations I have experienced. The fact that we are arguing this suggests the spec is poorly worded here, so some clarifications in the next version might be a good idea! :-) Jon. _____ From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: 21 April 2005 15:44 To: Jon Rowland; Rajkumar Nair; megaco@ietf.org Subject: RE: [Megaco] EventBufferDescriptor and EventDescriptor!! The text states how the Events descriptor functions when the value of the BF property is SP or OFF. I do not see anything that would support the assertion that the application of the EB descriptor is delayed due to the presence of an active Events descriptor at the time BF is set to SP. The paragraph that seems to be the main point of contention is describing behavior at all times when BF is SP, not just when it is first set. It is also a natural follow-on from the previous paragraph talking about the methodology by which events are matched by the Events descriptor. If the MGC wishes to be predictive of the events it wishes to match in the next Events descriptor, it certainly can do that -- via embedding. The EB descriptor is meant to filter the event input to the recognition/reporting process controlled by the Events descriptor. I stand by the position that the EB descriptor takes effect immediately upon the transition of BF from OFF to SP. I do not believe there is, or should be, an exception in the particular case you describe. Kevin _____ From: Jon Rowland [mailto:Jon.Rowland@dataconnection.com] Sent: Tuesday, April 19, 2005 5:24 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Rajkumar Nair; megaco@ietf.org Subject: RE: [Megaco] EventBufferDescriptor and EventDescriptor!! Kevin, I think we may actually be in sync in most of the below. I agree, that when you activate a new event descriptor, in order to report events that have been detected in the meantime, those events must also be present in the eventbuffer descriptor. That's fine. The key scenario that I think is in confusion is as follows: - No events have been detected or buffered. - A new event descriptor is programmed by the MGC. - An event matching that event descriptor is detected. - The event is reported to the MGC - The event descriptor is disabled because we're in lockstep mode. - Subsequent events are matched against the eventbuffer descriptor. - When the MGC programs a new event descriptor, any buffered event that also matches the new event descriptor is reported to the MGC. - Repeat. The key thing here is the start of the sequence. If there have been no events detected and buffered before the active event descriptor is programmed, then the value of the eventbuffer descriptor is irrelevant. An event is detected and there is an active event descriptor that matches it, so it is reported. The eventbuffer descriptor only comes into play for events detected while the MG is waiting for a new active event descriptor. Agree? It has to be this way. There are situations where you simply don't want the eventbuffer descriptor to match the same set of events as the active event descriptor - instead it's predicting the set of events you might want to detect in the _next_ active event descriptor. Cheers, Jon. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Jun 15 16:40:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiegL-0001fI-9Z; Wed, 15 Jun 2005 16:40:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiegG-0001dq-Kq for megaco@megatron.ietf.org; Wed, 15 Jun 2005 16:40:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02698 for ; Wed, 15 Jun 2005 16:40:10 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dif2y-00048T-Jv for megaco@ietf.org; Wed, 15 Jun 2005 17:03:43 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5FKdoC24315 for ; Wed, 15 Jun 2005 16:39:50 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jun 2005 16:39:45 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402849C9A@zrtphxm2> From: "Kevin Boyle" To: Mudit Gupta , megaco@ietf.org Subject: RE: [Megaco] DigitMap and EventBuffer !! Date: Wed, 15 Jun 2005 16:39:33 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 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 As per the discussion about two months ago and my email earlier today, LockStep does not get enforced until the currently active Events Descriptor matches. This means that the DigitMap runs as normal, and buffering takes effect once the DigitMap completes and the completion event is reported. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Mudit Gupta Sent: Tuesday, May 03, 2005 1:29 AM To: megaco@ietf.org Subject: [Megaco] DigitMap and EventBuffer !! Hi I have some doubt, please, try to resolve it. My query is like this: Suppose, I sent a DM, completion event and the eventBuffer control mode as lockstep to MG in one MODIFY request. Then I have following doubts: 1. Will the timers for DM (short, long and start) run? 2. Will the dialed digits be buffered or handled by DM string? 3. If handled by the DM, then after matching fully or time out if there will be a notify event for this DM irrespective of lockstep mode. Regards, Mudit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Jun 15 17:34:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DifWZ-0005hb-AR; Wed, 15 Jun 2005 17:34:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DifWW-0005hT-KY for megaco@megatron.ietf.org; Wed, 15 Jun 2005 17:34:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08244 for ; Wed, 15 Jun 2005 17:34:09 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiftG-00082N-V6 for megaco@ietf.org; Wed, 15 Jun 2005 17:57:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Conformance tests question Date: Wed, 15 Jun 2005 17:34:02 -0400 Message-ID: Thread-Topic: [Megaco] Conformance tests question Thread-Index: AcVxr7jVuE4iQzx6Q7GN+AdP6q3+jwAD+27A From: "Steve Cipolli" To: "Kevin Boyle" , "Frank Reno" , X-Spam-Score: 0.9 (/) X-Scan-Signature: 90f8d7cac99eccf384c4cdc57475e98c Cc: 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="===============0079179946==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0079179946== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C571F1.F2CEF3E7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C571F1.F2CEF3E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kevin, =20 I assume that v3 will have to support both choice #1 and #2 if we choose choice #1 for v1 and v2. That said, I believe this will mean that most implementations will use the form from choice #1 even for v3. I'm OK with that, but it is something to consider. =20 =20 My preference would be to do choice #1 and choice #2 in all versions. This way anyone who has to change their implementation because they currently do not allow $ could as easily use the form from choice #2. This will make it more likely that choice #2 is used in version 3. =20 =20 The downside to both choices is that they could create incompatibilies between new implementations of v1 (or v2) vs old implementations of v1 (or v2), but I see the risk the same for either choice. =20 --Stephen=20 -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com]=20 Sent: Wednesday, June 15, 2005 9:40 AM To: Steve Cipolli; Frank Reno; megaco@ietf.org Subject: RE: [Megaco] Conformance tests question =09 =09 Well, the two choices are: 1) lift this restriction in the text for the particular case of an error response for a second action in a transaction; or 2) change the ABNF syntax of the protocol. I believe the better choice for V1 and V2 is to do the former, since no parsing changes will be required. For V3 we should choose the latter, since this appears to be an oversight in the grammar. =20 Kevin ________________________________ From: Steve Cipolli [mailto:SCipolli@radvision.com]=20 Sent: Tuesday, June 14, 2005 5:41 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org Subject: RE: [Megaco] Conformance tests question =09 =09 =20 As the original poster pointed out, 8.2.2 says: =20 8.2.2 TransactionReply =20 ... The ContextID parameter must specify a value to pertain to all Responses for the action. The ContextID may be specific, all or null. =20 --Stephen -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com]=20 Sent: Tuesday, June 14, 2005 4:53 PM To: Steve Cipolli; Frank Reno; megaco@ietf.org Subject: RE: [Megaco] Conformance tests question =09 =09 Where do you see that restriction?=20 Kevin=20 -----Original Message-----=20 From: Steve Cipolli [mailto:SCipolli@radvision.com]=20 Sent: Tuesday, June 14, 2005 2:21 PM=20 To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org=20 Subject: RE: [Megaco] Conformance tests question Kevin,=20 Allowing '$' for context in replies also violates v1 and v2, so it appears there is no solution at all for v1 and v2. Do you mean that the IG for v1 and v2 should be updated to allow '$' for context in replies? --Stephen=20 > -----Original Message-----=20 > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org ] On Behalf Of Kevin Boyle=20 > Sent: Tuesday, June 14, 2005 12:36 PM=20 > To: Frank Reno; megaco@ietf.org=20 > Subject: RE: [Megaco] Conformance tests question=20 >=20 >=20 > This seems like a problem with the syntax of the protocol. =20 > Since we clearly allow error descriptors at the action level, and we=20 > allow following errors at the transaction and command levels, this=20 > appears to need fixing. It appears that the binary encoding allows an=20 > error at the action level for the second (or subsequent) action in a=20 > transaction.=20 >=20 > The fix itself would be straightforward, though non-backwards=20 > compatible. This would mean that it would have to be in V3, and not=20 > made retroactive to V1 and V2. The fix would be:=20 >=20 > transactionReply =3D ReplyToken EQUAL TransactionID LBRKT=20 > [ImmAckRequiredToken COMMA](errorDescriptor /=20 > actionReplyList [COMMA errorDescriptor]) RBRKT Fix=20 > is here------------------------^^^^^^^^^^^^^^^^^^^^^^^=20 >=20 > So, for V1 and V2, it would appear that your solution, though=20 > suboptimal in my view, is the only solution available within the=20 > syntax as defined.=20 >=20 > Kevin=20 > =20 >=20 > -----Original Message-----=20 > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org ] On Behalf Of Frank Reno=20 > Sent: Friday, June 10, 2005 3:49 PM=20 > To: megaco@ietf.org=20 > Subject: RE: [Megaco] Conformance tests question=20 >=20 > If an action fails with a context ID of CHOOSE and it is not the first=20 > action in the transaction, then the error can't be placed at the=20 > action level, since the grammar does not permit action replies and an=20 > action level error descriptor in the same transaction reply.=20 >=20 > So it looks like CHOOSE should be allowed in the reply.=20 >=20 > Given=20 >=20 > T =3D 1=20 > {=20 > C =3D 1 { Add =3D t1 },=20 > C =3D $ { Add =3D t2 }=20 > }=20 >=20 > This is not legal:=20 >=20 > Reply =3D 1=20 > {=20 > C =3D 1 { Add =3D t1 },=20 > Error =3D 412 {}=20 > }=20 >=20 > So it would have to be:=20 >=20 > Reply =3D 1=20 > {=20 > C =3D 1 { Add =3D t1 },=20 > C =3D $ { Error =3D 412 {}}=20 > }=20 >=20 > Frank=20 >=20 >=20 >=20 > --- Kevin Boyle wrote:=20 >=20 > In most cases, the MG knows it cannot allocate a context at the time=20 > the request is detected -- that is, once the action is parsed. If the=20 > MG detects a problem, why would it continue to parse?=20 > The error descriptor=20 > ought to be placed at the action level, so there would not be a=20 > context indicated of any kind, let alone a CHOOSE wildcard.=20 >=20 > Remember, error detection occurs at the earliest possible time with=20 > the error descriptor occurring at the level of detection.=20 > If the MG was not=20 > able to detect that it was unable to allocate a context until the=20 > command or descriptor level, then the error descriptor would go at the=20 > lower level.=20 >=20 > Kevin=20 [SNIP...]=20 ------_=_NextPart_001_01C571F1.F2CEF3E7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Kevin,
 
I=20 assume that v3 will have to support both choice #1 and #2 if = we=20 choose choice #1 for v1 and v2.   That said, I = believe this=20 will mean that most implementations will use the form from choice = #1 even=20 for v3.  I'm OK with that, but it is something to consider. =20
 
My=20 preference would be to do choice #1 and choice #2 in all versions.  = This=20 way anyone who has to change their implementation because they currently = do not=20 allow $ could as easily use the form from choice #2.  This = will make=20 it more likely that choice #2 is used in version 3. =20
 
The=20 downside to both choices is that they could create incompatibilies = between=20 new implementations of v1 (or v2) vs old implementations of v1 (or v2), = but I=20 see the risk the same for either choice.
 
--Stephen 
-----Original Message-----
From: = Kevin Boyle=20 [mailto:kboyle@nortel.com]
Sent: Wednesday, June 15, 2005 = 9:40=20 AM
To: Steve Cipolli; Frank Reno; = megaco@ietf.org
Subject:=20 RE: [Megaco] Conformance tests question

Well, the two choices are: 1) lift this restriction in the = text for the=20 particular case of an error response for a second action in a = transaction; or=20 2) change the ABNF syntax of the protocol.  I believe the = better=20 choice for V1 and V2 is to do the former, since no parsing changes = will be=20 required.  For V3 we should choose the latter, since this appears = to be=20 an oversight in the grammar.
 
Kevin

From: Steve Cipolli=20 [mailto:SCipolli@radvision.com]
Sent: Tuesday, June 14, = 2005 5:41=20 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno;=20 megaco@ietf.org
Subject: RE: [Megaco] Conformance tests=20 question

 
As = the original=20 poster pointed out, 8.2.2 says:
 
8.2.2=20 TransactionReply
 
...
The = ContextID parameter=20 must specify a value to pertain to all Responses for the action. The = ContextID may be specific, all or null.
 
--Stephen
-----Original Message-----
From: = Kevin Boyle=20 [mailto:kboyle@nortel.com]
Sent: Tuesday, June 14, 2005 = 4:53=20 PM
To: Steve Cipolli; Frank Reno;=20 megaco@ietf.org
Subject: RE: [Megaco] Conformance tests=20 question

Where do you see that restriction?

Kevin

-----Original Message-----
From:=20 Steve Cipolli [mailto:SCipolli@radvision.com]= =20
Sent: Tuesday, June 14, 2005 2:21 = PM=20
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; = megaco@ietf.org
Subject: RE: [Megaco] = Conformance=20 tests question

Kevin,

Allowing '$' for context in replies also = violates v1 and=20 v2, so it appears there is no solution at all for v1 and v2.  = Do you=20 mean that the IG for v1 and v2 should be updated to allow '$' for = context=20 in replies?

--Stephen

> -----Original Message-----
> From: megaco-bounces@ietf.org
> [mailto:megaco-bounces@ietf.org] On = Behalf Of=20 Kevin Boyle
> Sent: Tuesday, June 14, = 2005=20 12:36 PM
> To: Frank Reno;=20 megaco@ietf.org
> Subject: RE: = [Megaco]=20 Conformance tests question
> =
>
> This seems like a = problem with=20 the syntax of the protocol. 
> = Since we=20 clearly allow error descriptors at the action level, and we=20
> allow following errors at the = transaction and=20 command levels, this
> appears to = need=20 fixing.  It appears that the binary encoding allows an=20
> error at the action level for the = second (or=20 subsequent) action in a
> = transaction.=20
>
> The fix = itself would be=20 straightforward, though non-backwards
>=20 compatible. This would mean that it would have to be in V3, and = not=20
> made retroactive to V1 and = V2.  The fix=20 would be:
>
>=20 transactionReply =3D ReplyToken EQUAL TransactionID LBRKT =
>          =          =20 [ImmAckRequiredToken COMMA](errorDescriptor /
>          =          =20 actionReplyList [COMMA errorDescriptor]) RBRKT Fix =
> is = here------------------------^^^^^^^^^^^^^^^^^^^^^^^=20
>
> So, for V1 = and V2, it=20 would appear that your solution, though
>=20 suboptimal in my view, is the only solution available within the=20
> syntax as defined.
>
> Kevin =
> 
> =
> -----Original Message-----
> From:=20 megaco-bounces@ietf.org
> [mailto:megaco-bounces@ietf.org] On = Behalf Of=20 Frank Reno
> Sent: Friday, June 10, = 2005 3:49=20 PM
> To: megaco@ietf.org =
> Subject: RE: [Megaco] Conformance tests = question=20
>
> If an = action fails with=20 a context ID of CHOOSE and it is not the first
> action in the transaction, then the error can't be = placed at=20 the
> action level, since the grammar = does not=20 permit action replies and an
> action = level=20 error descriptor in the same transaction reply.
>
> So it looks like = CHOOSE should be=20 allowed in the reply.
> =
> Given
> =
> T =3D 1
> { =
>     C =3D 1 { Add =3D t1 = },
>     C =3D $ { Add =3D t2 = }
> }
>
>=20 This is not legal:
>
> Reply =3D 1
> { =
>     C =3D 1 { Add =3D t1 = },
>     Error =3D 412 {} =
> }
>
> So=20 it would have to be:
> =
> Reply =3D 1
> { =
>     C =3D 1 { Add =3D t1 = },
>     C =3D $ { Error =3D 412 = {}}=20
> }
> =
> Frank
> =
>
>
> ---=20 Kevin Boyle <kboyle at nortel.com> wrote:
>
> In most cases, the MG = knows it=20 cannot allocate a context at the time
> the=20 request is detected -- that is, once the action is parsed.  = If the=20
> MG detects a problem, why would it = continue=20 to parse?
> The error = descriptor=20
> ought to be placed at the action level, so = there=20 would not be a
> context indicated of = any kind,=20 let alone a CHOOSE wildcard.
> =
> Remember, error detection occurs at the earliest = possible time=20 with
> the error descriptor occurring = at the=20 level of detection.
> If the MG was = not=20
> able to detect that it was unable to = allocate a=20 context until the
> command or = descriptor=20 level, then the error descriptor would go at the
> lower level.
> =
> Kevin 
 [SNIP...] 

------_=_NextPart_001_01C571F1.F2CEF3E7-- --===============0079179946== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0079179946==-- From megaco-bounces@ietf.org Thu Jun 16 00:03:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dilaq-0005RS-Qu; Thu, 16 Jun 2005 00:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dilao-0005RN-QM for megaco@megatron.ietf.org; Thu, 16 Jun 2005 00:03:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13486 for ; Thu, 16 Jun 2005 00:02:59 -0400 (EDT) Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dilxc-0007Rz-Gc for megaco@ietf.org; Thu, 16 Jun 2005 00:26:37 -0400 Received: from spark.hss.co.in (localhost [127.0.0.1]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j5G3wCfd022003 for ; Thu, 16 Jun 2005 09:28:13 +0530 (IST) Received: from webmail.hss.hns.com (webmail.hss.hns.com [10.203.158.17]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j5G3wAGO021992 for ; Thu, 16 Jun 2005 09:28:11 +0530 (IST) To: megaco@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "B Venkat S.R Swamy" Date: Thu, 16 Jun 2005 09:27:02 +0530 X-MIMETrack: Serialize by Router on WebMail/HSS(Release 6.5.1|January 21, 2004) at 06/16/2005 09:27:04 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 3.1 (+++) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [Megaco] Audit on Wildcarded Context and ROOT Termination issue- 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, H.248.1 V1 and V2 section 7.2.5 say Auditvalue on Termination ID Root with context ID All should return list of all ContextIds (the ContextID list should be returned by using multiple action replies, each containing a ContextID from the list). Now the question is: How will the reply for the following scenario look like? Audit on termination ROOT with context * and empty audit descriptor MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 { Context = * { AuditValue = ROOT { Audit {}} } } There are currently three options: Option 1: Audit on ROOT termination returning only context information: MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = 1 {Auditvalue = ROOT}, Context = 2 {Auditvalue = ROOT} } Option 2: As per ETSI TS 101 889-2 section 5.1.9.1 "TP/MG/AV/BV-05" MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = 1 {Auditvalue = A4444 , Auditvalue = A4445}, Context = 2 {Auditvalue = A5444 , Auditvalue = A5445} } Option 3: condensed form of option 2 above : MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = 1 {Auditvalue = Context {A4444 , A4445} }, Context = 2 {Auditvalue = Context {A5444 , A5445} }, } However the option2 and option3 can be obtained through- Audit on Wildcarded context and Wildcarded termination with Empty Audit Descriptor. MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 { Context = * { AuditValue = * { Audit {}} } } Now considering the fact that the basic objective of Audit on ROOT termination and Context * is to get the list of context IDs only without any termination information, an optimized solution is suggested below. This however requires changes in the protocol grammar. MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = * {Auditvalue = ROOT {1, 2} } Request mailing list comments on the above issue, on either accepting the above solution or discontinuing the option of sending Audit on ROOT Termination and Context *. Regards, B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.flextronicssoftware.com *********************** FSS-Restricted *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 16 03:25:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diol0-0000FS-Rm; Thu, 16 Jun 2005 03:25:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diokw-0000Ez-S5 for megaco@megatron.ietf.org; Thu, 16 Jun 2005 03:25:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21635 for ; Thu, 16 Jun 2005 03:25:38 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dip7l-0005XS-Di for megaco@ietf.org; Thu, 16 Jun 2005 03:49:20 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BDACBCA7; Thu, 16 Jun 2005 09:25:36 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 09:25:35 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 09:25:34 +0200 Received: from [146.11.22.192] (EG2E500202DSEGL [146.11.22.192]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MLXTQCZX; Thu, 16 Jun 2005 17:25:30 +1000 Message-ID: <42B12996.1090602@ericsson.com> Date: Thu, 16 Jun 2005 17:26:14 +1000 X-Sybari-Trust: e1c68e15 3280b041 9d81ff69 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Steve Cipolli Subject: Re: [Megaco] Conformance tests question References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 07:25:35.0169 (UTC) FILETIME=[961C0B10:01C57244] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 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 Hello, I'm not really in favour of option 1 or 2. Relaxing 8.2.2 is still a protocol change. You may not be updating the syntax but something different will be sent in the protocol. Also by relaxing 8.2.2 you will also be making a change to the binary protocol. I think the only choice is to issue a note for V1 and V2 that for the text encoding that implementors issue the C=? as the first command in a transaction. In v3 update the syntax so that this is fixed properly. Regards, Christian Steve Cipolli wrote: > Kevin, > > I assume that v3 will have to support both choice #1 and #2 if we choose > choice #1 for v1 and v2. That said, I believe this will mean that most > implementations will use the form from choice #1 even for v3. I'm OK > with that, but it is something to consider. > > My preference would be to do choice #1 and choice #2 in all versions. > This way anyone who has to change their implementation because they > currently do not allow $ could as easily use the form from choice #2. > This will make it more likely that choice #2 is used in version 3. > > The downside to both choices is that they could create incompatibilies > between new implementations of v1 (or v2) vs old implementations of v1 > (or v2), but I see the risk the same for either choice. > > --Stephen > > -----Original Message----- > From: Kevin Boyle [mailto:kboyle@nortel.com] > Sent: Wednesday, June 15, 2005 9:40 AM > To: Steve Cipolli; Frank Reno; megaco@ietf.org > Subject: RE: [Megaco] Conformance tests question > > > Well, the two choices are: 1) lift this restriction in the text for the > particular case of an error response for a second action in a > transaction; or 2) change the ABNF syntax of the protocol. I believe > the better choice for V1 and V2 is to do the former, since no parsing > changes will be required. For V3 we should choose the latter, since > this appears to be an oversight in the grammar. > > Kevin > > > _____ > > From: Steve Cipolli [mailto:SCipolli@radvision.com] > Sent: Tuesday, June 14, 2005 5:41 PM > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org > Subject: RE: [Megaco] Conformance tests question > > > > As the original poster pointed out, 8.2.2 says: > > 8.2.2 TransactionReply > > ... > The ContextID parameter must specify a value to pertain to all Responses > for the action. The ContextID may be specific, all or null. > > --Stephen > > -----Original Message----- > From: Kevin Boyle [mailto:kboyle@nortel.com] > Sent: Tuesday, June 14, 2005 4:53 PM > To: Steve Cipolli; Frank Reno; megaco@ietf.org > Subject: RE: [Megaco] Conformance tests question > > > > Where do you see that restriction? > > Kevin > > -----Original Message----- > From: Steve Cipolli [mailto:SCipolli@radvision.com > ] > Sent: Tuesday, June 14, 2005 2:21 PM > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org > Subject: RE: [Megaco] Conformance tests question > > Kevin, > > Allowing '$' for context in replies also violates v1 and v2, so it > appears there is no solution at all for v1 and v2. Do you mean that the > IG for v1 and v2 should be updated to allow '$' for context in replies? > > --Stephen > > >>-----Original Message----- >>From: megaco-bounces@ietf.org >>[ mailto:megaco-bounces@ietf.org] On > > Behalf Of Kevin Boyle > >>Sent: Tuesday, June 14, 2005 12:36 PM >>To: Frank Reno; megaco@ietf.org >>Subject: RE: [Megaco] Conformance tests question >> >> >>This seems like a problem with the syntax of the protocol. >>Since we clearly allow error descriptors at the action level, and we >>allow following errors at the transaction and command levels, this >>appears to need fixing. It appears that the binary encoding allows an > > >>error at the action level for the second (or subsequent) action in a >>transaction. >> >>The fix itself would be straightforward, though non-backwards >>compatible. This would mean that it would have to be in V3, and not >>made retroactive to V1 and V2. The fix would be: >> >>transactionReply = ReplyToken EQUAL TransactionID LBRKT >> [ImmAckRequiredToken COMMA](errorDescriptor / >> actionReplyList [COMMA errorDescriptor]) RBRKT Fix >>is here------------------------^^^^^^^^^^^^^^^^^^^^^^^ >> >>So, for V1 and V2, it would appear that your solution, though >>suboptimal in my view, is the only solution available within the >>syntax as defined. >> >>Kevin >> >> >>-----Original Message----- >>From: megaco-bounces@ietf.org >>[ mailto:megaco-bounces@ietf.org] On > > Behalf Of Frank Reno > >>Sent: Friday, June 10, 2005 3:49 PM >>To: megaco@ietf.org >>Subject: RE: [Megaco] Conformance tests question >> >>If an action fails with a context ID of CHOOSE and it is not the first > > >>action in the transaction, then the error can't be placed at the >>action level, since the grammar does not permit action replies and an >>action level error descriptor in the same transaction reply. >> >>So it looks like CHOOSE should be allowed in the reply. >> >>Given >> >>T = 1 >>{ >> C = 1 { Add = t1 }, >> C = $ { Add = t2 } >>} >> >>This is not legal: >> >>Reply = 1 >>{ >> C = 1 { Add = t1 }, >> Error = 412 {} >>} >> >>So it would have to be: >> >>Reply = 1 >>{ >> C = 1 { Add = t1 }, >> C = $ { Error = 412 {}} >>} >> >>Frank >> >> >> >>--- Kevin Boyle wrote: >> >>In most cases, the MG knows it cannot allocate a context at the time >>the request is detected -- that is, once the action is parsed. If the > > >>MG detects a problem, why would it continue to parse? >>The error descriptor >>ought to be placed at the action level, so there would not be a >>context indicated of any kind, let alone a CHOOSE wildcard. >> >>Remember, error detection occurs at the earliest possible time with >>the error descriptor occurring at the level of detection. >>If the MG was not >>able to detect that it was unable to allocate a context until the >>command or descriptor level, then the error descriptor would go at the > > >>lower level. >> >>Kevin > > [SNIP...] > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Megaco mailing 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 Jun 16 04:22:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DipeH-0004XA-HJ; Thu, 16 Jun 2005 04:22:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DipeE-0004Wu-QX for megaco@megatron.ietf.org; Thu, 16 Jun 2005 04:22:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25201 for ; Thu, 16 Jun 2005 04:22:45 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diq15-0001Xd-0w for megaco@ietf.org; Thu, 16 Jun 2005 04:46:28 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 570D9A83; Thu, 16 Jun 2005 10:22:34 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 10:22:33 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 10:22:32 +0200 Received: from [146.11.22.192] (EG2E500202DSEGL [146.11.22.192]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MLXTQDR5; Thu, 16 Jun 2005 18:22:29 +1000 Message-ID: <42B0F529.9080709@ericsson.com> Date: Thu, 16 Jun 2005 13:42:33 +1000 X-Sybari-Trust: 84f856d9 3280b041 9d81ff69 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Tom Taylor Subject: Re: [Megaco] Expert review of requests for new packages References: <42B03F02.5050503@nortel.com> In-Reply-To: <42B03F02.5050503@nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 08:22:33.0153 (UTC) FILETIME=[8B630310:01C5724C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.7 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Hello Tom, I think your role should be a least to ensure a). With regards to b) and c) I had hoped that standards groups who are developing packages liaise with SG16 to see that their packages are correct and not duplicating functionality. I don't think this role should be left to one person nor do I think that it is IANAs role to police the functionality defined in packages as they are not a technical body. Of course given your considerable history with H.248 I think its more than reasonable that you can personally question the merits of a package but I don't think this should be linked to assigning a packageID. Regards, Christian Tom Taylor wrote: > It may be a bit late to get anything done about this question in v3, but > > perhaps all we need is a consensus agreement on the list. > > I am the designated expert for review of requests to register new > packages with IANA. The question is what criteria I apply to new public > > packages. Is the intent that: > > (a) I ensure that the formal requirements as currently specified in > Megaco/H.248 documentation are satisfied, or > > (b) do I have the responsibility to require clarification of substantive > > items in the document that seem unclear, or > > (c) do I have authority to at least question the content of proposed > packages in a broader way? > > If my responsibility goes beyond (a), groups that are preparing > Megaco/H.248 packages will have to get IANA and thus me involved before > their documents are set in concrete. > > Looking forward to your comments. > > 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 Thu Jun 16 04:22:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DipeI-0004Xf-NK; Thu, 16 Jun 2005 04:22:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DipeG-0004X5-Lt for megaco@megatron.ietf.org; Thu, 16 Jun 2005 04:22:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25205 for ; Thu, 16 Jun 2005 04:22:47 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diq17-0001Xk-Pw for megaco@ietf.org; Thu, 16 Jun 2005 04:46:30 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 78A9EBF1; Thu, 16 Jun 2005 10:22:42 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 10:22:41 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 10:22:41 +0200 Received: from [146.11.22.192] (EG2E500202DSEGL [146.11.22.192]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MLXTQDSC; Thu, 16 Jun 2005 18:22:37 +1000 Message-ID: <42B12AF8.10007@ericsson.com> Date: Thu, 16 Jun 2005 17:32:08 +1000 X-Sybari-Trust: 72396c64 3280b041 9d81ff69 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Stephen Mell Subject: Re: [Megaco] andisp/dwa and Hook State Change Race References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 08:22:41.0473 (UTC) FILETIME=[90588B10:01C5724C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Hello Stephen, I believe this issue as been discussed at a recent Tispan meeting. I expect to see a liaison come into the July SG16 meeting on enhancements to H.248.23. So this will be discussed then. Regards, Christian Stephen Mell wrote: > Hello Kevin, > > We have experienced a situation which highlights a slight drawback with > the current definition of andisp/dwa in H248.23, and thought it might be > worth pointing it out now, should an "xandisp" ever materialise. > > With most signals that my MG needs to apply, the nature of the signal > implies whether or not it is sensible or not to apply that signal in the > face of a given hook state. This is good as it helps greatly to mitigate > the effect of network crossover situations. For example I can choose to > fail ringing if the line is now off-hook and send the required Notify to > indicate failure if g/sc is armed. > > andisp/dwa is constructed in such an economical way that that the on and > off hook signalling messages are syntactically the same, but are > interpreted differently at the Gateway, dependant on the actual Hook > state - However the MGC's anticipated hook state when it requested the > signal is not conveyed to the Gateway. > > When there is a crossover between an OFF/ON-HOOK notification from the > MG and a anddisp/dwa Signal from the MGC, the MG may end up > inadvertantly applying inappropraite signalling to the line. Where there > is packet loss this Crossover window is naturally opened further. > > Another optional signal parameter, identifying the MGC's anticipated > hook state, which the MG is required to match before attempting to apply > the signal, would help to shut this window. > > > Regards, > > Steve > > > ------------------------------------------------------------------------ > > _______________________________________________ > Megaco mailing 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 Jun 16 04:22:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DipeK-0004YH-NA; Thu, 16 Jun 2005 04:22:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DipeH-0004XN-Vc for megaco@megatron.ietf.org; Thu, 16 Jun 2005 04:22:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25212 for ; Thu, 16 Jun 2005 04:22:48 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diq17-0001Xg-Ps for megaco@ietf.org; Thu, 16 Jun 2005 04:46:31 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 62105B20; Thu, 16 Jun 2005 10:22:41 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 10:22:40 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 10:22:39 +0200 Received: from [146.11.22.192] (EG2E500202DSEGL [146.11.22.192]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MLXTQDR0; Thu, 16 Jun 2005 18:22:34 +1000 Message-ID: <42B126B9.6010305@ericsson.com> Date: Thu, 16 Jun 2005 17:14:01 +1000 X-Sybari-Trust: 928ac8cd 3280b041 9d81ff69 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Contardi Angelo Subject: Re: [Megaco] Ambiguities,Errors and forgotten things in Packages Desc ription References: <8E6DA0ECC9F8EE4483CBF31602B1537E81D316@BESONE.corp.dom> In-Reply-To: <8E6DA0ECC9F8EE4483CBF31602B1537E81D316@BESONE.corp.dom> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 08:22:39.0507 (UTC) FILETIME=[8F2C8E30:01C5724C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Content-Transfer-Encoding: 7bit Cc: "Megaco IETF - Mail List \(E-mail\)" 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 Contardi Angelo wrote: > Hello, > > During the reading of H.248.1 packages description i have encountered > many difficulties i try to explain in this mail. > > I hope someone can clarify my doubts. Furthermore, if any of my > considerations > is valid, i hope will be taken in count in the new "incoming" H.248.1 V3 > ITU > specification. The V2 specification probably is "too stable" to be > modified :-) > > REFERENCE SPECIFICATION: > ------------------------ > > ITU H.248.1 V2 Corrigendum 1 (i think the last one approved by ITU). > > PREFACE: > -------- > > The Textual (ABNF) coding of VALUEs allows ONE of the following forms: > > * A sequence of ONE or MORE SafeChar (let me say SafeChar form). > > * A quotedString form that is a DOUBLE QUOTED string of ZERO or MORE > ASCII chars, > with some exceptions (DOUBLE QUOTES, non printable chars, C language > string > terminator '\0' (0x00), etc.). > > Of the two forms, the quotedString form is the more general one. > > Errors (?): > ----------- > > 1) In the textual coding i think it's impossible to code ANY UTF-8 char > (RFC 3629) because of the FIRST byte of an UTF-8 char may be ANY > ASCII > char in the range 0x00-0x7E and, for instance, the ASCII 0x01-0x07, > that > are not allowed in ABNF form of VALUE. > Furthermore, UTF-8 chars "greater than 0x7E", need ASCII chars in the > > range 0x80-0xFF (not ALL), not allowed in the ABNF form of VALUE. > If my assertion is true, in the packages description (paragraphs > 12.x.x of > H.248.1 V2 Corrigendum 1), the TYPEs of VALUEs (i suppose they should > be valid > for BOTH ASN.1 and ABNF coding): > > - String: can't be ANY UTF-8 string but JUST an ASCII string with > the > limitation of the quotedString !!! So it can't include > '"', > '\0', etc. > > - Character: can't be ANY UTF-8 for the same above reasons and with > the > same limitation. > > In other words, String and Character types may be JUST quotedString. > Otherwise, to code UTF-8 chars with an ASCII string it's necessary to > extend > the quotedString definition allowing ANY ASCII, except '\0' and '"'. [CHG] Yes I agree with many of your assertions. I thought this is already covered at the start of the ABNF in H.248.1 section B.2. > > 2) Due probably to a "copy & paste" operation of the "Octet String" > references, > the references o Sub-List type in paragraphs 12.1.2, 12.1.5 and 12.2 > are > probably wrong and should be: > > "The encoding of Sub-lists is specified in Annex A and B.2 > (alternativeValue > description)." [CHG] Yes this should reference B.2 not B.3. > > 3) The Integer and Double types of Properties and Parameters are BOTH > SIGNED (paragraphs 12.x.x of Corrigendum), while in ABNF description > of > VALUEs ("top" ANNEX B.2 comment) there is the possibility of Unsigned > Integer > TOO. Why ? Note that from the "implementor" point of view, Integer > and Unsigned > Integer (on 32 Bits) aren't the same thing (different range: the sign > "eat" > on bit). [CHG] The paragraphs of 12.x.x are the overriding descriptions. The ABNF itself does not enforce all the H.248.1 syntax and procedures. As you've pointed out VALUE is very flexible but it is the type defined in the packages (and sect 12.) that say how it is used. > > Ambiguities: > ------------ > > 1) About the Sub-List type of a package Property/Parameter: > > - Sub-List is not "strictly speaking" a type but a Sub-set of Items, > ALL > of a specified Type (Integer, Double, etc.). [CHG] Yes. > > - The term Sub-List appears just in the descriptive paragraphs of > Packages > (12.x.x) but NOT in packages definitions (ANNEX E) in witch appears > JUST > List (see tonedet ad tonegen base packages). > [CHG] This has been fixed in H.248.1v3 to say sub-list > - Paragraph 12.3 is titled "Lists", but describe how to register > enumerated > types to IANA. [CHG] I don't believe anybody has made use of this facility. I actually would propose to remove this. > > - A Sub-List may assume 3 forms (in BOTH ASN.1 and ABNF > implementations): > > * An OR sublist of elements > * An AND sublist of elements > * A RANGE sublist of elements (AND or OR ?) > > So, to specify COMPLETELY a VALUE of a Parameter/Property of "type" > Sub-list, > somewhere in the package one should write which relation, AND or > OR, "ties" > the Sub-list VALUEs. > > Furthermore, if it is reasonable to allow packages that MAY admit > BOTH > AND or OR relations, the syntax of the "RANGE" is not suited to > carry > the AND or OR "relation attribute". > I think in some applications the AND or OR attribute may have, in > different > times, sense. For instance, a modem tone detector (when i was jung > i work > with modems :-), can be programmed as a DTMF tone detector (so it > detects > a COUPLE of SINGLE tones at the same time (relation AND)) or as a > "multy" > (single) tone detector, capable to detect toneA OR toneB > ...(relation OR)). > > My proposal: > > * In a package description, specify the type of the values as usual > and do > not include Sub-List as a type but ADD a the new descriptive > "item": > > Sub-Set: None/AND/OR or BOTH > > * Reference the Sub-Set with the string "Sub-Set" everywhere in the > specification, > both in the Packages definitions and in the syntax description > (ASN.1 and > ABNF notation comments, to indicate how the Sub-Set is > implemented). [CHG] I don't think we need to formalise this. I think it is up to the package writers to address this. It is also largely dependent on the individual capabilities of the Media gateways. > > 2) About Octet String ABNF representation: > > - The octet string ABNF representation is described in ANNEX B.3 in a > way > i think is not so clear: > > "...This octet encoding SHOULD be used when encoding octet strings > in the > text version of the protocol..." > > I think it means, more explicitly: > > "The ASCII character string corresponding to this octet encoding > SHOULD > be used when encoding octet strings in the text version of the > protocol." > > So, for instance, the Hex Coding "0x90" correspond to the string > "90". [CHG] This is probably clearer but the example clarifies exactly what is required. > > - Furthermore i think ANNEX B.4 may be deleted because it just > contribute > to confuse ideas. It seems it says "text coding of octet string > must be > terminated with a CARRIAGE RETURN", not allowed in the ABNF form of > VALUE. > > Things left out (forgotten): > ---------------------------- > > 1) The ASN.1 implementation of VALUE allow a NULL list of VALUEs that > means > CHOOSE: the VALUE may be choosen by MG. How CHOOSE is implemented in > ABNF syntax ? [CHG] Choose is implemented in the ABNF by sending down "?" It does not need to be equivalent to the ASN.1. So long as both encodings can alway to choose. > > My Proposal: > > * Non conservative: Change the syntax of alternativeValue: > > VALUE *(COMMA VALUE) become [VALUE *(COMMA VALUE)] > > It may introduce "parser ambiguities". > > * Conservative (as i have already implemented :-): > > If parmValue is EQUAL to an EMPTY QUOTED STRING, the parameter > VALUE may > be choose by MG. Note that THIS is done at PARSER level so the TYPE > of > the VALE (semantic level) doesn't affect the way an EMPTY VALUE of > ANY TYPE > is represented (""). > I think the "semantic" distinction made in paragraph 7.2.6: > > "For property and parameter values of type string, character or > octet string, > the MG shall return an empty value. > For the text encoding, strings and characters return an empty > quotedString > construct, while octet strings return NUL (0x00)." > > is NOT necessary at ALL and NOT applicable to ALL allowed values > types. > Furthermore i don't understand what it means with: > > "... while octet strings return NUL (0x00)" > > Does it means the text Octect Coding of 0x00, thus the string "00" > (not quoted)? > The ASCII '\0' (0x00) is NOT allowed in ABNF VALUEs forms. > > 2) When describing the fact that a package may be an extension of an > other it > should be stated that the "added Items Ids can't assume ANY of the > (already > existing) base package Items Ids values". This to ensure the the fact > that > any Item of "extended package" (UNION of the base and added ones), > must be > identified in an unambiguous mode. [CHG] It already states this in H.248.1 section 12.1.1 "An extended package shall not redefine or overload an identifier defined in the original package and packages it may have extended (multiple levels of extension). " > > Best Regards > > o o o o o o o . . . ___________________________________ > o _____ || Angelo Contardi | > .][__n_n_|DD[ ====_____ | angelo.contardi@italtel.it | > >(________|__|_[_________]_|________________________________| > _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o` > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Megaco mailing 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 Jun 16 05:55:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dir5d-0005Ym-8X; Thu, 16 Jun 2005 05:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dir5b-0005Yh-78 for megaco@megatron.ietf.org; Thu, 16 Jun 2005 05:55:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02198 for ; Thu, 16 Jun 2005 05:55:05 -0400 (EDT) Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DirSQ-00005P-9w for megaco@ietf.org; Thu, 16 Jun 2005 06:18:49 -0400 Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 10:54:55 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Audit on Wildcarded Context and ROOT Termination issue- X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 16 Jun 2005 10:54:54 +0100 Message-ID: <7397E98E3B94C544BB0485F2283EF8BD10C880@enfimail1.datcon.co.uk> Thread-Topic: [Megaco] Audit on Wildcarded Context and ROOT Termination issue- Thread-Index: AcVyKIO6iHa4f13yRZu64X0ZaVs79AAL3VTg From: "Jon Rowland" To: "B Venkat S.R Swamy" X-OriginalArrivalTime: 16 Jun 2005 09:54:55.0405 (UTC) FILETIME=[72D38DD0:01C57259] X-Spam-Score: 0.2 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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 Option 1 is correct. Options 2 and 3 are responses to a wildcard termination audit of wildcarded context IDs as you correctly point out. This suggests that the ETSI spec is erroneous. Your suggested compressed scheme doesn't really add very much over the short-text encoding of the transaction response: !/1 [124.124.124.124]:55555 P=3D9999{ C=3D1{AV=3DROOT}, C=3D2{AV=3DROOT} } Hence, I'm not sure it is justifiable given it is not back-compatible. The general problem with this type of command, when used in conjunction with large gateways, is that the response size can get quite large, which can be a problem when using TCP or UDP transports. This has been addressed in V3 by the introduction of a scheme for segmenting responses. Jon. =20 -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of B Venkat S.R Swamy Sent: 16 June 2005 04:57 To: megaco@ietf.org Subject: [Megaco] Audit on Wildcarded Context and ROOT Termination issue- Hi, H.248.1 V1 and V2 section 7.2.5 say Auditvalue on Termination ID Root with context ID All should return list of all ContextIds (the ContextID list should be returned by using multiple action replies, each containing a ContextID from the list). Now the question is: How will the reply for the following scenario look like? Audit on termination ROOT with context * and empty audit descriptor MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction =3D 9999 { Context =3D * { AuditValue =3D ROOT { Audit {}} } } There are currently three options: Option 1: Audit on ROOT termination returning only context information: MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply =3D 9999 { Context =3D 1 {Auditvalue =3D ROOT}, Context =3D 2 {Auditvalue =3D ROOT} } Option 2: As per ETSI TS 101 889-2 section 5.1.9.1 "TP/MG/AV/BV-05" MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply =3D 9999 { Context =3D 1 {Auditvalue =3D A4444 , Auditvalue =3D A4445}, Context =3D 2 {Auditvalue =3D A5444 , Auditvalue =3D A5445} } Option 3: condensed form of option 2 above : MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply =3D 9999 { Context =3D 1 {Auditvalue =3D Context {A4444 , A4445} }, Context =3D 2 {Auditvalue =3D Context {A5444 , A5445} }, } However the option2 and option3 can be obtained through- Audit on Wildcarded context and Wildcarded termination with Empty Audit Descriptor. MEGACO/1 [123.123.123.4]:55555 Transaction =3D 9999 { Context =3D * { AuditValue =3D * { Audit {}} } } Now considering the fact that the basic objective of Audit on ROOT termination and Context * is to get the list of context IDs only without any termination information, an optimized solution is suggested below. This however requires changes in the protocol grammar. MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply =3D 9999 { Context =3D * {Auditvalue =3D ROOT {1, 2} } Request mailing list comments on the above issue, on either accepting the above solution or discontinuing the option of sending Audit on ROOT Termination and Context *. Regards, B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.flextronicssoftware.com *********************** FSS-Restricted *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately.=20 If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 16 10:26:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivKU-0002As-36; Thu, 16 Jun 2005 10:26:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivKS-00029L-4U for megaco@megatron.ietf.org; Thu, 16 Jun 2005 10:26:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26037 for ; Thu, 16 Jun 2005 10:26:42 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DivhK-0003Ev-L8 for megaco@ietf.org; Thu, 16 Jun 2005 10:50:28 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j5GEPPc10424; Thu, 16 Jun 2005 10:25:26 -0400 (EDT) Received: from [127.0.0.1] (acart553.ca.nortel.com [47.130.17.210]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MRAFN0SR; Thu, 16 Jun 2005 10:26:24 -0400 Message-ID: <42B18C09.9090003@nortel.com> Date: Thu, 16 Jun 2005 10:26:17 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves Subject: Re: [Megaco] Expert review of requests for new packages References: <42B03F02.5050503@nortel.com> <42B0F529.9080709@ericsson.com> In-Reply-To: <42B0F529.9080709@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 If there are no further comments from the list I am happy to take (a) as my clarified mandate. Christian Groves wrote: > Hello Tom, > > I think your role should be a least to ensure a). > With regards to b) and c) I had hoped that standards groups who are > developing packages liaise with SG16 to see that their packages are > correct and not duplicating functionality. I don't think this role > should be left to one person nor do I think that it is IANAs role to > police the functionality defined in packages as they are not a technical > body. > > Of course given your considerable history with H.248 I think its more > than reasonable that you can personally question the merits of a package > but I don't think this should be linked to assigning a packageID. > > Regards, Christian > > Tom Taylor wrote: > >> It may be a bit late to get anything done about this question in v3, but >> >> perhaps all we need is a consensus agreement on the list. >> >> I am the designated expert for review of requests to register new >> packages with IANA. The question is what criteria I apply to new public >> >> packages. Is the intent that: >> >> (a) I ensure that the formal requirements as currently specified in >> Megaco/H.248 documentation are satisfied, or >> >> (b) do I have the responsibility to require clarification of substantive >> >> items in the document that seem unclear, or >> >> (c) do I have authority to at least question the content of proposed >> packages in a broader way? >> >> If my responsibility goes beyond (a), groups that are preparing >> Megaco/H.248 packages will have to get IANA and thus me involved >> before their documents are set in concrete. >> >> Looking forward to your comments. >> >> 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 Thu Jun 16 10:45:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Divcx-00070h-FG; Thu, 16 Jun 2005 10:45:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Divcv-00070b-Uc for megaco@megatron.ietf.org; Thu, 16 Jun 2005 10:45:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27680 for ; Thu, 16 Jun 2005 10:45:48 -0400 (EDT) Received: from 65.105.113.195.ptr.us.xo.net ([65.105.113.195] helo=win2kserv.internal.tecore.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Divzo-0004Di-P9 for megaco@ietf.org; Thu, 16 Jun 2005 11:09:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Jun 2005 10:45:26 -0400 Message-ID: Thread-Topic: Ephemeral Termination Management Thread-Index: AcVyggiubmDP9e5wQQmlTQPJuHtT1g== From: "Ben Wang" To: X-Spam-Score: 1.2 (+) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Subject: [Megaco] Ephemeral Termination Management 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="===============0290486239==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0290486239== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57282.08DA11D2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57282.08DA11D2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can MGC (Media Gateway Controller) manage Ephemeral (RTP) Terminations contained within the MG (Media Gateway) via Megaco interface? How can MGC know how many RTP resources are available for a MG? =20 Thanks very much! =20 Regards, =20 Ben C. Wang =20 TECORE Wireless Systems Phone 410-872-6000 ext. 233 Email: Ben C. Wang =20 =20 =20 ------_=_NextPart_001_01C57282.08DA11D2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can MGC (Media Gateway Controller) manage Ephemeral = (RTP) Terminations contained within the MG (Media Gateway) via Megaco interface? How can = MGC know how many RTP resources are available for a = MG?

 

Thanks very much!

 

Regards,

 

Ben C. Wang

 

TECORE Wireless = Systems

=

Phone 410-872-6000 ext. = 233

Email: Ben C. Wang

 

 

=00 ------_=_NextPart_001_01C57282.08DA11D2-- --===============0290486239== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0290486239==-- From megaco-bounces@ietf.org Thu Jun 16 10:58:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Divpa-00021Y-H3; Thu, 16 Jun 2005 10:58:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivpX-00021Q-0L for megaco@megatron.ietf.org; Thu, 16 Jun 2005 10:58:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28949 for ; Thu, 16 Jun 2005 10:58:49 -0400 (EDT) Received: from [62.90.58.229] (helo=tparelay.telradnetworks.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiwCJ-0005A1-7C for megaco@ietf.org; Thu, 16 Jun 2005 11:22:35 -0400 Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j5GEsXZ3020155 for ; Thu, 16 Jun 2005 17:54:33 +0300 (IDT) Received: from tpa-mail1.Telrad.co.il ([141.226.76.57]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j5GEsXt5020149 for ; Thu, 16 Jun 2005 17:54:33 +0300 (IDT) Received: by tpa-mail1.telrad.co.il with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Jun 2005 17:59:40 +0300 Message-ID: From: Tamar Nemet To: megaco@ietf.org Date: Thu, 16 Jun 2005 17:59:38 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Subject: [Megaco] Base Root 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: , Content-Type: multipart/mixed; boundary="===============0054031265==" 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. --===============0054031265== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57283.77046F4E" 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_01C57283.77046F4E Content-Type: text/plain; charset="ISO-8859-8" H ello, The properties defined in the base root package are been sent by the MG or by the MGC ? Who is the one which determine the MaxNrOfcontexts/NormalMGexecutionTime/NormalMGCExecutionTime and all others ? In which command it should be sent and when ? After registration ? Can somebody give me an example for a message ? Thanks, Tamar ------_=_NextPart_001_01C57283.77046F4E Content-Type: text/html; charset="ISO-8859-8" Content-Transfer-Encoding: quoted-printable
H ello,
=
 
The properties defined in the base root = package are=20 been sent by the MG or by the MGC ?
 
Who is the one which determine the=20 MaxNrOfcontexts/NormalMGexecutionTime/NormalMGCExecutionTime  and = all=20 others ?
 
In which command it should be sent and when = ? After=20 registration ?
 
Can somebody give me an example for a = message=20 ?
 
Thanks,
Tamar 
 
 
------_=_NextPart_001_01C57283.77046F4E-- --===============0054031265== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0054031265==-- From megaco-bounces@ietf.org Thu Jun 16 11:15:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diw5b-0006X5-SF; Thu, 16 Jun 2005 11:15:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diw5Y-0006We-V4 for megaco@megatron.ietf.org; Thu, 16 Jun 2005 11:15:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00433 for ; Thu, 16 Jun 2005 11:15:23 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiwST-0006DK-Uj for megaco@ietf.org; Thu, 16 Jun 2005 11:39:10 -0400 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 Subject: RE: [Megaco] Conformance tests question Date: Thu, 16 Jun 2005 11:15:21 -0400 Message-ID: Thread-Topic: [Megaco] Conformance tests question Thread-Index: AcVyRJn/BDFA0zHrSeu7WD+htFrvSwAPTmjg From: "Steve Cipolli" To: "Christian Groves" X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 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 Christian, I agree that avoiding any incompatible change to v1 and v2 is the ideal solution. However, I'm not sure I follow your alternative: First, the problem is not encoding specific. 8.2.2 applies to both binary and text encoding (the ABNF also allows '$', but 8.2.2 prohibits its use in replies). My reading of the ASN.1 does not allow action replies and an action-level error in the same reply, just as the ABNF does not. Second, I think you mean "... Implementors issue C=3D$ as the first = action in the transaction ", not "... Implementors issue C=3D? as the first command in the transaction". Third, there maybe multiple actions with a context of '$'. How would an MGC know which of these actions might fail? =20 --Stephen > -----Original Message----- > From: Christian Groves [mailto:christian.groves@ericsson.com]=20 > Sent: Thursday, June 16, 2005 3:26 AM > To: Steve Cipolli > Cc: Kevin Boyle; Frank Reno; megaco@ietf.org > Subject: Re: [Megaco] Conformance tests question >=20 >=20 > Hello, >=20 > I'm not really in favour of option 1 or 2. Relaxing 8.2.2 is=20 > still a protocol=20 > change. You may not be updating the syntax but something=20 > different will be sent=20 > in the protocol. Also by relaxing 8.2.2 you will also be=20 > making a change to the=20 > binary protocol. >=20 > I think the only choice is to issue a note for V1 and V2 that=20 > for the text=20 > encoding that implementors issue the C=3D? as the first command=20 > in a transaction.=20 > In v3 update the syntax so that this is fixed properly. >=20 > Regards, Christian >=20 > Steve Cipolli wrote: >=20 > > Kevin, > > =20 > > I assume that v3 will have to support both choice #1 and #2=20 > if we choose > > choice #1 for v1 and v2. That said, I believe this will=20 > mean that most > > implementations will use the form from choice #1 even for=20 > v3. I'm OK=20 > > with that, but it is something to consider. > > =20 > > My preference would be to do choice #1 and choice #2 in all=20 > versions.=20 > > This way anyone who has to change their implementation because they=20 > > currently do not allow $ could as easily use the form from=20 > choice #2.=20 > > This will make it more likely that choice #2 is used in version 3. > > =20 > > The downside to both choices is that they could create=20 > incompatibilies=20 > > between new implementations of v1 (or v2) vs old=20 > implementations of v1=20 > > (or v2), but I see the risk the same for either choice. > > =20 > > --Stephen > >=20 > > -----Original Message----- > > From: Kevin Boyle [mailto:kboyle@nortel.com] > > Sent: Wednesday, June 15, 2005 9:40 AM > > To: Steve Cipolli; Frank Reno; megaco@ietf.org > > Subject: RE: [Megaco] Conformance tests question > >=20 > >=20 > > Well, the two choices are: 1) lift this restriction in the text for=20 > > the particular case of an error response for a second action in a=20 > > transaction; or 2) change the ABNF syntax of the protocol. =20 > I believe=20 > > the better choice for V1 and V2 is to do the former, since=20 > no parsing=20 > > changes will be required. For V3 we should choose the=20 > latter, since=20 > > this appears to be an oversight in the grammar. > > =20 > > Kevin > >=20 > >=20 > > _____ > >=20 > > From: Steve Cipolli [mailto:SCipolli@radvision.com] > > Sent: Tuesday, June 14, 2005 5:41 PM > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org > > Subject: RE: [Megaco] Conformance tests question > >=20 > >=20 > > =20 > > As the original poster pointed out, 8.2.2 says: > > =20 > > 8.2.2 TransactionReply > > =20 > > ... > > The ContextID parameter must specify a value to pertain to all=20 > > Responses for the action. The ContextID may be specific,=20 > all or null. > > =20 > > --Stephen > >=20 > > -----Original Message----- > > From: Kevin Boyle [mailto:kboyle@nortel.com] > > Sent: Tuesday, June 14, 2005 4:53 PM > > To: Steve Cipolli; Frank Reno; megaco@ietf.org > > Subject: RE: [Megaco] Conformance tests question > >=20 > >=20 > >=20 > > Where do you see that restriction? > >=20 > > Kevin > >=20 > > -----Original Message----- > > From: Steve Cipolli [mailto:SCipolli@radvision.com > > ]=20 > > Sent: Tuesday, June 14, 2005 2:21 PM=20 > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org=20 > > Subject: RE: [Megaco] Conformance tests question=20 > >=20 > > Kevin, > >=20 > > Allowing '$' for context in replies also violates v1 and v2, so it=20 > > appears there is no solution at all for v1 and v2. Do you=20 > mean that=20 > > the IG for v1 and v2 should be updated to allow '$' for context in=20 > > replies? > >=20 > > --Stephen > >=20 > >=20 > >>-----Original Message----- > >>From: megaco-bounces@ietf.org=20 > >>[ =20 > mailto:megaco-bounces@ietf.org] On > >=20 > > Behalf Of Kevin Boyle > >=20 > >>Sent: Tuesday, June 14, 2005 12:36 PM > >>To: Frank Reno; megaco@ietf.org=20 > >>Subject: RE: [Megaco] Conformance tests question=20 > >> > >> > >>This seems like a problem with the syntax of the protocol. > >>Since we clearly allow error descriptors at the action=20 > level, and we=20 > >>allow following errors at the transaction and command levels, this=20 > >>appears to need fixing. It appears that the binary=20 > encoding allows an > >=20 > >=20 > >>error at the action level for the second (or subsequent) action in a > >>transaction.=20 > >> > >>The fix itself would be straightforward, though non-backwards > >>compatible. This would mean that it would have to be in V3, and not=20 > >>made retroactive to V1 and V2. The fix would be:=20 > >> > >>transactionReply =3D ReplyToken EQUAL TransactionID LBRKT=20 > >> [ImmAckRequiredToken COMMA](errorDescriptor /=20 > >> actionReplyList [COMMA errorDescriptor])=20 > RBRKT Fix > >>is here------------------------^^^^^^^^^^^^^^^^^^^^^^^=20 > >> > >>So, for V1 and V2, it would appear that your solution, though > >>suboptimal in my view, is the only solution available within the=20 > >>syntax as defined.=20 > >> > >>Kevin > >>=20 > >> > >>-----Original Message----- > >>From: megaco-bounces@ietf.org=20 > >>[ =20 > mailto:megaco-bounces@ietf.org] On > >=20 > > Behalf Of Frank Reno > >=20 > >>Sent: Friday, June 10, 2005 3:49 PM > >>To: megaco@ietf.org=20 > >>Subject: RE: [Megaco] Conformance tests question=20 > >> > >>If an action fails with a context ID of CHOOSE and it is=20 > not the first > >=20 > >=20 > >>action in the transaction, then the error can't be placed at the > >>action level, since the grammar does not permit action=20 > replies and an=20 > >>action level error descriptor in the same transaction reply.=20 > >> > >>So it looks like CHOOSE should be allowed in the reply. > >> > >>Given > >> > >>T =3D 1 > >>{=20 > >> C =3D 1 { Add =3D t1 },=20 > >> C =3D $ { Add =3D t2 }=20 > >>}=20 > >> > >>This is not legal: > >> > >>Reply =3D 1 > >>{=20 > >> C =3D 1 { Add =3D t1 },=20 > >> Error =3D 412 {}=20 > >>}=20 > >> > >>So it would have to be: > >> > >>Reply =3D 1 > >>{=20 > >> C =3D 1 { Add =3D t1 },=20 > >> C =3D $ { Error =3D 412 {}}=20 > >>}=20 > >> > >>Frank > >> > >> > >> > >>--- Kevin Boyle wrote: > >> > >>In most cases, the MG knows it cannot allocate a context at the time > >>the request is detected -- that is, once the action is=20 > parsed. If the > >=20 > >=20 > >>MG detects a problem, why would it continue to parse? > >>The error descriptor=20 > >>ought to be placed at the action level, so there would not be a=20 > >>context indicated of any kind, let alone a CHOOSE wildcard.=20 > >> > >>Remember, error detection occurs at the earliest possible time with > >>the error descriptor occurring at the level of detection.=20 > >>If the MG was not=20 > >>able to detect that it was unable to allocate a context until the=20 > >>command or descriptor level, then the error descriptor=20 > would go at the > >=20 > >=20 > >>lower level. > >> > >>Kevin > >=20 > > [SNIP...] > >=20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 16 11:15:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diw5r-0006Yu-1x; Thu, 16 Jun 2005 11:15:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diw5p-0006Yk-NA for megaco@megatron.ietf.org; Thu, 16 Jun 2005 11:15:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00471 for ; Thu, 16 Jun 2005 11:15:39 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiwSk-0006DR-8y for megaco@ietf.org; Thu, 16 Jun 2005 11:39:26 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5GFFPr12448 for ; Thu, 16 Jun 2005 11:15:25 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jun 2005 11:15:25 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40284A520@zrtphxm2> From: "Kevin Boyle" To: Christian Groves , Stephen Mell Subject: RE: [Megaco] andisp/dwa and Hook State Change Race Date: Thu, 16 Jun 2005 11:15:13 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 This race condition, in practice, occurs extremely rarely and does not seem to cause confusion to the end-user. In more than 5 years of active deployment across literally millions of lines of service there has never been a single compliant. There are two possible scenarios: 1. User picks up and listens for dialtone, intending to place a call but discovering that there is already a connection. They hear Call Wait tone and potentially get the number delivered (if the Signals descriptor isn't canceled fast enough). 2. User hangs up the phone from an existing call, and instantly gets ringing and number delivery. Scenario one is a weird case anyway. People don't generally enjoy picking up the phone and finding a connection present when they are expecting dialtone. This does happen on rare occasions, and the inclusion of a call wait tone at that moment does not seem to create any additional discomfort or problem over the already existing "twilight zone" connection. (The creepiest of these is when the person on the other end of the connection happens to be the person you were intending to call!) Scenario 2 is OK, because the call was going to present anyway -- this actually saves a NACK from the MG and a potential call loss. So, I think the issue here is being made out to be much bigger than it really is. In fact, given that scenario 2 saves a NACK, there is some beneficial economy to the methodology that exists. Kevin -----Original Message----- From: Christian Groves [mailto:christian.groves@ericsson.com] Sent: Thursday, June 16, 2005 3:32 AM To: Stephen Mell Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: Re: [Megaco] andisp/dwa and Hook State Change Race Hello Stephen, I believe this issue as been discussed at a recent Tispan meeting. I expect to see a liaison come into the July SG16 meeting on enhancements to H.248.23. So this will be discussed then. Regards, Christian Stephen Mell wrote: > Hello Kevin, > > We have experienced a situation which highlights a slight drawback > with the current definition of andisp/dwa in H248.23, and thought it > might be worth pointing it out now, should an "xandisp" ever materialise. > > With most signals that my MG needs to apply, the nature of the signal > implies whether or not it is sensible or not to apply that signal in > the face of a given hook state. This is good as it helps greatly to > mitigate the effect of network crossover situations. For example I can > choose to fail ringing if the line is now off-hook and send the > required Notify to indicate failure if g/sc is armed. > > andisp/dwa is constructed in such an economical way that that the on > and off hook signalling messages are syntactically the same, but are > interpreted differently at the Gateway, dependant on the actual Hook > state - However the MGC's anticipated hook state when it requested the > signal is not conveyed to the Gateway. > > When there is a crossover between an OFF/ON-HOOK notification from the > MG and a anddisp/dwa Signal from the MGC, the MG may end up > inadvertantly applying inappropraite signalling to the line. Where > there is packet loss this Crossover window is naturally opened further. > > Another optional signal parameter, identifying the MGC's anticipated > hook state, which the MG is required to match before attempting to > apply the signal, would help to shut this window. > > > Regards, > > Steve > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Megaco mailing 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 Jun 16 11:20:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwAi-0006sE-Ht; Thu, 16 Jun 2005 11:20:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwAg-0006s4-Qv for megaco@megatron.ietf.org; Thu, 16 Jun 2005 11:20:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00757 for ; Thu, 16 Jun 2005 11:20:41 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiwXa-0006Y4-0X for megaco@ietf.org; Thu, 16 Jun 2005 11:44:28 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j5GFJac05335 for ; Thu, 16 Jun 2005 11:19:36 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jun 2005 11:20:22 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40284A541@zrtphxm2> From: "Kevin Boyle" To: Christian Groves , "Tom-PT Taylor" Subject: RE: [Megaco] Expert review of requests for new packages Date: Thu, 16 Jun 2005 11:20:12 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 I second Christian's view on this. IANA's job is as a repository, not a formal review board. SG16 is capable of functioning in the latter role. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Christian Groves Sent: Wednesday, June 15, 2005 11:43 PM To: Taylor, Tom-PT [CAR:5N00:EXCH] Cc: megaco@ietf.org Subject: Re: [Megaco] Expert review of requests for new packages Hello Tom, I think your role should be a least to ensure a). With regards to b) and c) I had hoped that standards groups who are developing packages liaise with SG16 to see that their packages are correct and not duplicating functionality. I don't think this role should be left to one person nor do I think that it is IANAs role to police the functionality defined in packages as they are not a technical body. Of course given your considerable history with H.248 I think its more than reasonable that you can personally question the merits of a package but I don't think this should be linked to assigning a packageID. Regards, Christian Tom Taylor wrote: > It may be a bit late to get anything done about this question in v3, > but > > perhaps all we need is a consensus agreement on the list. > > I am the designated expert for review of requests to register new > packages with IANA. The question is what criteria I apply to new > public > > packages. Is the intent that: > > (a) I ensure that the formal requirements as currently specified in > Megaco/H.248 documentation are satisfied, or > > (b) do I have the responsibility to require clarification of > substantive > > items in the document that seem unclear, or > > (c) do I have authority to at least question the content of proposed > packages in a broader way? > > If my responsibility goes beyond (a), groups that are preparing > Megaco/H.248 packages will have to get IANA and thus me involved > before their documents are set in concrete. > > Looking forward to your comments. > > 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 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 16 11:29:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwJ2-0001Hd-Ko; Thu, 16 Jun 2005 11:29:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwJ0-0001Es-F4 for megaco@megatron.ietf.org; Thu, 16 Jun 2005 11:29:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01658 for ; Thu, 16 Jun 2005 11:29:16 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Diwfv-00077a-13 for megaco@ietf.org; Thu, 16 Jun 2005 11:53:03 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1118925044; Thu Jun 16 18:29:39 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Jun 2005 18:32:30 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D311F@MAILSERVER> From: Raphael Tryster To: megaco@ietf.org Date: Thu, 16 Jun 2005 18:32:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Subject: [Megaco] even H.248.2 has typos 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="===============0616447873==" 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. --===============0616447873== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57290.FD482CF0" 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_01C57290.FD482CF0 Content-Type: text/plain; charset="WINDOWS-1255" 1. In section 7.1.6 of H.248.2, ctyp property is titled PhasereversalDetect, but the propertyID is given as v8bsup, which is copied from the property in 7.1.3. I assume the propertyID was intended to be PhasereversalDetect. 2. In section 8.1.2, fax property ftrpt has possible values T30, T30ECM and T.30V34. This is syntactically permitted, but I think for consistency the author did not intend the last value to include a dot. Raphael Tryster ------_=_NextPart_001_01C57290.FD482CF0 Content-Type: text/html; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable order of descriptors in remote ringback scenario

1.     &nbs= p; In section 7.1.6 of H.248.2, ctyp property is titled PhasereversalDetect, but the propertyID = is given as v8bsup, which is copied from the property in 7.1.3.  I assume the propertyID was int= ended to be PhasereversalDetect.

 <= /p>

2.     &nbs= p; In section 8.1.2, fax= property ftrpt has possible values T30, T30ECM and T.30V34.  This is syntactically permitted, but I think for consi= stency the author did not intend the last value to include a dot.

 <= /p>

Raphael Tryster

 

 

 <= /o:p>

------_=_NextPart_001_01C57290.FD482CF0-- --===============0616447873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0616447873==-- From megaco-bounces@ietf.org Thu Jun 16 11:30:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwK1-0001a7-DM; Thu, 16 Jun 2005 11:30:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwJz-0001YS-Hq for megaco@megatron.ietf.org; Thu, 16 Jun 2005 11:30:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01745 for ; Thu, 16 Jun 2005 11:30:17 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diwgu-00078G-BG for megaco@ietf.org; Thu, 16 Jun 2005 11:54:04 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5GFU3r15230 for ; Thu, 16 Jun 2005 11:30:03 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jun 2005 11:30:01 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40284A590@zrtphxm2> From: "Kevin Boyle" To: Tamar Nemet , megaco@ietf.org Subject: RE: [Megaco] Base Root package Date: Thu, 16 Jun 2005 11:29:44 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 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 ReadOnly properties are set by the MG and cannot be changed by the MGC. Read/Write properties are initially set by the MG but may be altered by the MGC. Properties may be changed in any Add/Move/Modify command, though typically a Modify is used. This must occur after registration -- how could an MGC alter a property value prior to MG registration? There are sample messages in Appendix I which show properties being set. The methodology is the same whether the properties are on Root or on some other termination. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Tamar Nemet Sent: Thursday, June 16, 2005 11:00 AM To: megaco@ietf.org Subject: [Megaco] Base Root package H ello, The properties defined in the base root package are been sent by the MG or by the MGC ? Who is the one which determine the MaxNrOfcontexts/NormalMGexecutionTime/NormalMGCExecutionTime and all others ? In which command it should be sent and when ? After registration ? Can somebody give me an example for a message ? Thanks, Tamar _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 16 11:33:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwNE-0002Lk-RV; Thu, 16 Jun 2005 11:33:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwND-0002LF-IA for megaco@megatron.ietf.org; Thu, 16 Jun 2005 11:33:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02304 for ; Thu, 16 Jun 2005 11:33:37 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diwk7-0007Mi-Nn for megaco@ietf.org; Thu, 16 Jun 2005 11:57:25 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5GFXWr15847 for ; Thu, 16 Jun 2005 11:33:32 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jun 2005 11:33:20 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40284A5A3@zrtphxm2> From: "Kevin Boyle" To: Raphael Tryster , megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos Date: Thu, 16 Jun 2005 11:33:14 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 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 Are these in the revision that was recently issued? If so, I will add an IG item to fix these. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Raphael Tryster Sent: Thursday, June 16, 2005 12:33 PM To: megaco@ietf.org Subject: [Megaco] even H.248.2 has typos 1. In section 7.1.6 of H.248.2, ctyp property is titled PhasereversalDetect, but the propertyID is given as v8bsup, which is copied from the property in 7.1.3. I assume the propertyID was intended to be PhasereversalDetect. 2. In section 8.1.2, fax property ftrpt has possible values T30, T30ECM and T.30V34. This is syntactically permitted, but I think for consistency the author did not intend the last value to include a dot. Raphael Tryster _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 16 11:43:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwWk-0005H8-A7; Thu, 16 Jun 2005 11: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 1DiwWe-0005Gk-Mx for megaco@megatron.ietf.org; Thu, 16 Jun 2005 11:43:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03432 for ; Thu, 16 Jun 2005 11:43:22 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DiwtW-000807-VP for megaco@ietf.org; Thu, 16 Jun 2005 12:07:09 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1118925044; Thu Jun 16 18:43:36 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Jun 2005 18:46:27 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D3120@MAILSERVER> From: Raphael Tryster To: "'Kevin Boyle'" , megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos Date: Thu, 16 Jun 2005 18:46:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 Cc: 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="===============1245800182==" 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. --===============1245800182== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57292.EFE4AD20" 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_01C57292.EFE4AD20 Content-Type: text/plain; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable The revision in which I found these is dated 11/2000, which was the curre= nt edition at least to the end of 2004. =93This Recommendation was first approved and published as Annex F to H.248, and then renumbered as H.248.= 2 on 2002-03-29 without further modification=94. I don=92t know what has h= appened in 2005. =20 Raphael Tryster =20 =20 -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Thursday, June 16, 2005 5:33 PM To: Raphael Tryster; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos =20 Are these in the revision that was recently issued? If so, I will add an= IG item to fix these. =20 Kevin =20 _____ =20 From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf = Of Raphael Tryster Sent: Thursday, June 16, 2005 12:33 PM To: megaco@ietf.org Subject: [Megaco] even H.248.2 has typos 1. In section 7.1.6 of H.248.2, ctyp property is titled PhasereversalDetect, but the propertyID is given as v8bsup, which is copi= ed from the property in 7.1.3. I assume the propertyID was intended to be PhasereversalDetect. =20 2. In section 8.1.2, fax property ftrpt has possible values T30, T30ECM and T.30V34. This is syntactically permitted, but I think for consistency the author did not intend the last value to include a dot. =20 Raphael Tryster =20 =20 =20 ------_=_NextPart_001_01C57292.EFE4AD20 Content-Type: text/html; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable order of descriptors in remote ringback scenario

The revision in which I found these is dated 11/2000, which was th= e current edition at least to the end of 2004.  =93This Recommendation was first approved and published a= s Annex F to H.248, and then renumbered as H.248.2 on 2002-03-29 without fu= rther modification=94.  I don=92t know what has happene= d in 2005.

 

Raphael Tryster=

 <= ![endif]>

 <= /p>

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortel.com]
Sent: Thursday, June 16, 2= 005 5:33 PM
To: Raphael Tryster; megaco@ietf.org
Subject: RE: [Megaco] even= H.248.2 has typos

 

Are these in the revision that was recently issued?  If so, I will add a= n IG item to fix these.

&nb= sp;<= /o:p>

Kevin<= /o:p>

 <= /o:p>

From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Raphael Tryster
Sent: Thursday, June 16, 2= 005 12:33 PM
To: megaco@ietf.org
Subject: [Megaco] even H.2= 48.2 has typos

1.= =2E     &nb= sp; In section 7.1.6 of H.248.2, ctyp property is titled PhasereversalDetect, but the propertyID = is given as v8bsup, which is copied from the property in 7.1.3.  I assume the propertyID was int= ended to be PhasereversalDetect.

 

2.= =2E     &nb= sp; In section 8.1.2, fax property ftrpt has possible values T30, T30ECM and T.30V34.  This is syntactically permitted= , but I think for consistency the author did not intend the last value to include= a dot.

 

Raphael Tryster<= /o:p>

 = ;

 

; Thu, 16 Jun 2005 11:45:47 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diwvt-0008A8-Rw for megaco@ietf.org; Thu, 16 Jun 2005 12:09:35 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5GFjWm12048 for ; Thu, 16 Jun 2005 11:45:32 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jun 2005 11:45:31 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40284A616@zrtphxm2> From: "Kevin Boyle" To: Raphael Tryster , megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos Date: Thu, 16 Jun 2005 11:45:19 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 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.2 was revised at the November 2004 meeting of SG16. The new spec is dated 01/2005. Kevin _____ From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, June 16, 2005 12:46 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos The revision in which I found these is dated 11/2000, which was the current edition at least to the end of 2004. "This Recommendation was first approved and published as Annex F to H.248, and then renumbered as H.248.2 on 2002-03-29 without further modification". I don't know what has happened in 2005. Raphael Tryster -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Thursday, June 16, 2005 5:33 PM To: Raphael Tryster; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos Are these in the revision that was recently issued? If so, I will add an IG item to fix these. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Raphael Tryster Sent: Thursday, June 16, 2005 12:33 PM To: megaco@ietf.org Subject: [Megaco] even H.248.2 has typos 1.. In section 7.1.6 of H.248.2, ctyp property is titled PhasereversalDetect, but the propertyID is given as v8bsup, which is copied from the property in 7.1.3. I assume the propertyID was intended to be PhasereversalDetect. 2.. In section 8.1.2, fax property ftrpt has possible values T30, T30ECM and T.30V34. This is syntactically permitted, but I think for consistency the author did not intend the last value to include a dot. Raphael Tryster _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 16 14:14:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diypb-0008Sh-66; Thu, 16 Jun 2005 14:11:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiypX-0008RO-9Y for megaco@megatron.ietf.org; Thu, 16 Jun 2005 14:11:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21272 for ; Thu, 16 Jun 2005 14:11:01 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DizCQ-0002Bd-Uh for megaco@ietf.org; Thu, 16 Jun 2005 14:34:49 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1118925044; Thu Jun 16 21:11:14 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Jun 2005 21:13:57 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D3121@MAILSERVER> From: Raphael Tryster To: "'Kevin Boyle'" , megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos Date: Thu, 16 Jun 2005 21:13:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.4 (/) X-Scan-Signature: dabfd8cc2c196ec56401c44f64d155c2 Cc: 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="===============1425237288==" 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. --===============1425237288== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C572A7.8B1018C0" 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_01C572A7.8B1018C0 Content-Type: text/plain; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable I noticed something else. The basic Megaco packages and others, e.g. H.248.23, do not have any identifiers of events, signals, properties and statistics with the same values as one another. I had the impression tha= t this was a requirement. But several of the packages in H.248.2 start the= ir events, signals, properties and statistics identifiers at 0x0001. Does i= t matter? =20 One thing that probably does matter is that in fax package, properties faxstate and ftrpt both have propertyID =3D 0x0001. =20 Raphael Tryster =20 =20 -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Thursday, June 16, 2005 5:45 PM To: Raphael Tryster; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos =20 H.248.2 was revised at the November 2004 meeting of SG16. The new spec i= s dated 01/2005. =20 Kevin =20 _____ =20 From: Raphael Tryster [mailto:raphael@tdsoft.com]=20 Sent: Thursday, June 16, 2005 12:46 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos The revision in which I found these is dated 11/2000, which was the curre= nt edition at least to the end of 2004. =93This Recommendation was first approved and published as Annex F to H.248, and then renumbered as H.248.= 2 on 2002-03-29 without further modification=94. I don=92t know what has h= appened in 2005. =20 Raphael Tryster =20 =20 -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Thursday, June 16, 2005 5:33 PM To: Raphael Tryster; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos =20 Are these in the revision that was recently issued? If so, I will add an= IG item to fix these. =20 Kevin =20 _____ =20 From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf = Of Raphael Tryster Sent: Thursday, June 16, 2005 12:33 PM To: megaco@ietf.org Subject: [Megaco] even H.248.2 has typos 1.. In section 7.1.6 of H.248.2, ctyp property is titled PhasereversalDetect, but the propertyID is given as v8bsup, which is copi= ed from the property in 7.1.3. I assume the propertyID was intended to be PhasereversalDetect. =20 2.. In section 8.1.2, fax property ftrpt has possible values T30, T30ECM and T.30V34. This is syntactically permitted, but I think for consistency the author did not intend the last value to include a dot. =20 Raphael Tryster =20 =20 =20 ------_=_NextPart_001_01C572A7.8B1018C0 Content-Type: text/html; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable order of descriptors in remote ringback scenario

I noticed something else.  = The basic Megaco packages and others, e.g. H.248.23, do not have any identifi= ers of events, signals, properties and statistics with the same values as one an= other.  I had the impression that this = was a requirement.  But several o= f the packages in H.248.2 start their events, signals, properties and statistic= s identifiers at 0x0001.  Does it matter?=

 

One thing that probably does matter is that in fax package, proper= ties faxstate and ftrpt both have propertyID =3D 0x0001.

 

Raphael Tryster=

 <= ![endif]>

 <= /p>

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortel.com]
Sent: Thursday, June 16, 2= 005 5:45 PM
To: Raphael Tryster; megaco@ietf.org
Subject: RE: [Megaco] even= H.248.2 has typos

 

H.248.2 was revised at the November 2004 meeting of SG16.  The new spec is d= ated 01/2005.

&nb= sp;<= /o:p>

Kevin<= /o:p>

 <= /o:p>

From: Raphael Tryster [mailto:raphael@tdsoft.com]
Sent: Thursday, June 16, 2= 005 12:46 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: RE: [Megaco] even= H.248.2 has typos

The revision in which I found these is dated 11= /2000, which was the current edition at least to the end of 2004.  =93This Recommendation was first approved an= d published as Annex F to H.248, and then renumbered as H.248.2 on 2002-03-= 29 without further modification=94.  I don=92t know what has happene= d in 2005.

 

Raphael Tryster<= /o:p>

&n= bsp;

<= span class=3DEmailStyle20>&n= bsp;

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortel.com]
Sent: Thursday, June 16, 2= 005 5:33 PM
To: Raphael Tryster; megaco@ietf.org
Subject: RE: [Megaco] even= H.248.2 has typos

&nb= sp;<= /o:p>

Are these in the revision that was recently issued?  If so, I will add a= n IG item to fix these.

&nb= sp;<= /o:p>

Kevin<= /o:p>

&nb= sp;<= /o:p>

From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Raphael Tryster
Sent: Thursday, June 16, 2= 005 12:33 PM
To: megaco@ietf.org
Subject: [Megaco] even H.2= 48.2 has typos

1.= =2E.     &nb= sp; In section 7.1.6 of H.248.2, ctyp property is titled PhasereversalDetect, but the propertyID = is given as v8bsup, which is copied from the property in 7.1.3.  I assume the propertyID was int= ended to be PhasereversalDetect.

 

2.= =2E.     &nb= sp; In section 8.1.2, fax property ftrpt has possible values T30, T30ECM and T.30V34.  This is syntactically permitted= , but I think for consistency the author did not intend the last value to include= a dot.

 

Raphael Tryster<= /o:p>

 = ;

 

; Thu, 16 Jun 2005 15:16:40 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dj0Dz-00065T-2p for megaco@ietf.org; Thu, 16 Jun 2005 15:40:28 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1118925044; Thu Jun 16 22:16:55 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Jun 2005 22:19:45 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D3122@MAILSERVER> From: Raphael Tryster To: megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos Date: Thu, 16 Jun 2005 22:19:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.4 (/) X-Scan-Signature: c72c29da2ca4b2bd12d89dfc936ad645 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="===============0684494078==" 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. --===============0684494078== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C572B0.BC601070" 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_01C572B0.BC601070 Content-Type: text/plain; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable Also for ctyp/dtone, parameter dtt has values DTMF and Sig which are both 0x000B. For ctyp/v8bs, parameter v8bsn has values MRdrl and Crel which are both 0x0006, and Creh and Crdi which are both 0x0007. =20 Raphael Tryster =20 =20 -----Original Message----- From: Raphael Tryster=20 Sent: Thursday, June 16, 2005 9:14 PM To: 'Kevin Boyle'; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos =20 I noticed something else. The basic Megaco packages and others, e.g. H.248.23, do not have any identifiers of events, signals, properties and statistics with the same values as one another. I had the impression tha= t this was a requirement. But several of the packages in H.248.2 start the= ir events, signals, properties and statistics identifiers at 0x0001. Does i= t matter? =20 One thing that probably does matter is that in fax package, properties faxstate and ftrpt both have propertyID =3D 0x0001. =20 Raphael Tryster =20 =20 -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Thursday, June 16, 2005 5:45 PM To: Raphael Tryster; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos =20 H.248.2 was revised at the November 2004 meeting of SG16. The new spec i= s dated 01/2005. =20 Kevin =20 _____ =20 From: Raphael Tryster [mailto:raphael@tdsoft.com]=20 Sent: Thursday, June 16, 2005 12:46 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos The revision in which I found these is dated 11/2000, which was the curre= nt edition at least to the end of 2004. =93This Recommendation was first approved and published as Annex F to H.248, and then renumbered as H.248.= 2 on 2002-03-29 without further modification=94. I don=92t know what has h= appened in 2005. =20 Raphael Tryster =20 =20 -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Thursday, June 16, 2005 5:33 PM To: Raphael Tryster; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos =20 Are these in the revision that was recently issued? If so, I will add an= IG item to fix these. =20 Kevin =20 _____ =20 From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf = Of Raphael Tryster Sent: Thursday, June 16, 2005 12:33 PM To: megaco@ietf.org Subject: [Megaco] even H.248.2 has typos 1... In section 7.1.6 of H.248.2, ctyp property is titled PhasereversalDetect, but the propertyID is given as v8bsup, which is copi= ed from the property in 7.1.3. I assume the propertyID was intended to be PhasereversalDetect. =20 2... In section 8.1.2, fax property ftrpt has possible values T30, T30ECM and T.30V34. This is syntactically permitted, but I think for consistency the author did not intend the last value to include a dot. =20 Raphael Tryster =20 =20 =20 ------_=_NextPart_001_01C572B0.BC601070 Content-Type: text/html; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable order of descriptors in remote ringback scenario

Also for ctyp/dtone, parameter dtt has values DTMF and Sig which a= re both 0x000B.

For ctyp/v8bs, parameter v8bsn has values MRdrl and Crel which are= both 0x0006, and Creh and Crdi which are both 0x0007.=

 

Raphael Tryster<= /o:p>

 

I noticed something else.  The basic Megaco packages and others, e.g. H.248.23, d= o not have any identifiers of events, signals, properties and statistics with t= he same values as one another.  I had the impression that this was a requirement.  But several of the packages in H.248.2 start their eve= nts, signals, properties and statistics identifiers at 0x0001.  Does it matter?

 =

One thing that probably does matter is that in = fax package, properties faxstate and ftrpt both have propertyID =3D 0x0001.

 =

Raphael Tryster<= /o:p>

 

<= span class=3DEmailStyle21> <= /p>

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortel.com]
Sent: Thursday, June 16, 2= 005 5:45 PM
To: Raphael Tryster; megaco@ietf.org
Subject: RE: [Megaco] even= H.248.2 has typos

 <= /o:p>

H.248.2 was revised at the November 2004 meeting of SG16.  The new spec is d= ated 01/2005.

&nb= sp;<= /o:p>

Kevin<= /o:p>

 <= /o:p>

From: Raphael Tryster [mailto:raphael@tdsoft.com]
Sent: Thursday, June 16, 2= 005 12:46 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: RE: [Megaco] even= H.248.2 has typos

The revision in which I found these is dated 11= /2000, which was the current edition at least to the end of 2004.  =93This Recommendation was first approved an= d published as Annex F to H.248, and then renumbered as H.248.2 on 2002-03-= 29 without further modification=94.  I don=92t know what has happene= d in 2005.

 

Raphael Tryster<= /o:p>

&n= bsp;

<= span class=3DEmailStyle20>&n= bsp;

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortel.com]
Sent: Thursday, June 16, 2= 005 5:33 PM
To: Raphael Tryster; megaco@ietf.org
Subject: RE: [Megaco] even= H.248.2 has typos

&nb= sp;<= /o:p>

Are these in the revision that was recently issued?  If so, I will add an IG i= tem to fix these.

&nb= sp;<= /o:p>

Kevin<= /o:p>

&nb= sp;<= /o:p>

From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Raphael Tryster
Sent: Thursday, June 16, 2= 005 12:33 PM
To: megaco@ietf.org
Subject: [Megaco] even H.2= 48.2 has typos

1.= =2E..     &nb= sp; In section 7.1.6 of H.248.2, ctyp property is titled PhasereversalDetect, but the propertyID = is given as v8bsup, which is copied from the property in 7.1.3.  I assume the propertyID was int= ended to be PhasereversalDetect.

 

2.= =2E..     &nb= sp; In section 8.1.2, fax property ftrpt has possible values T30, T30ECM and T.30V34.  This is syntactically permitted= , but I think for consistency the author did not intend the last value to include= a dot.

 

Raphael Tryster<= /o:p>

 = ;

 

; Thu, 16 Jun 2005 15:56:49 -0400 (EDT) Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj0ql-0000OV-JP for megaco@ietf.org; Thu, 16 Jun 2005 16:20:38 -0400 Received: from vit (213.64.230.47) by pne-smtpout1-sn1.fre.skanova.net (7.2.059.6) id 429C54210038D8A8; Thu, 16 Jun 2005 21:56:23 +0200 From: "Gunnar Hellstrom" To: "Raphael Tryster" , Subject: RE: [Megaco] even H.248.2 has typos Date: Thu, 16 Jun 2005 21:56:22 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <9A64A99CD3F2BD4582BE4FB63FC1F381010D3122@MAILSERVER> Importance: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 4eaba8a3f66804313fcc9b62b5e6d8a8 Cc: 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="===============0004916280==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0004916280== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0174_01C572BE.3BC7CDF0" This is a multi-part message in MIME format. ------=_NextPart_000_0174_01C572BE.3BC7CDF0 Content-Type: text/plain; charset="WINDOWS-1255" Content-Transfer-Encoding: Quoted-Printable order of descriptors in remote ringback scenarioRaphael, I checked the November draft that was for Consent in SG16, and it had at least the conflict of ctyp/dtone, parameter dtt values DTMF and Sig resolved. A lot of other cleaning and adding good functionality for more automonous call type discrimination. So, you should have the latest approved ITU version before you start detailed review. Regards Gunnar Hellstr?m ------------------------------------------- Gunnar Hellstr?m Omnitor AB Renathv?gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On Behalf= Of Raphael Tryster Sent: Thursday, June 16, 2005 10:20 PM To: megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos Also for ctyp/dtone, parameter dtt has values DTMF and Sig which are bo= th 0x000B. For ctyp/v8bs, parameter v8bsn has values MRdrl and Crel which are both 0x0006, and Creh and Crdi which are both 0x0007. Raphael Tryster -----Original Message----- From: Raphael Tryster Sent: Thursday, June 16, 2005 9:14 PM To: 'Kevin Boyle'; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos I noticed something else. The basic Megaco packages and others, e.g. H.248.23, do not have any identifiers of events, signals, properties and statistics with the same values as one another. I had the impression tha= t this was a requirement. But several of the packages in H.248.2 start the= ir events, signals, properties and statistics identifiers at 0x0001. Does i= t matter? One thing that probably does matter is that in fax package, properties faxstate and ftrpt both have propertyID =3D 0x0001. Raphael Tryster -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Thursday, June 16, 2005 5:45 PM To: Raphael Tryster; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos H.248.2 was revised at the November 2004 meeting of SG16. The new spec= is dated 01/2005. Kevin -------------------------------------------------------------------------= --- -- From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, June 16, 2005 12:46 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos The revision in which I found these is dated 11/2000, which was the current edition at least to the end of 2004. =93This Recommendation was = first approved and published as Annex F to H.248, and then renumbered as H.248.= 2 on 2002-03-29 without further modification=94. I don=92t know what has h= appened in 2005. Raphael Tryster -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Thursday, June 16, 2005 5:33 PM To: Raphael Tryster; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos Are these in the revision that was recently issued? If so, I will add = an IG item to fix these. Kevin -------------------------------------------------------------------------= --- -- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behal= f Of Raphael Tryster Sent: Thursday, June 16, 2005 12:33 PM To: megaco@ietf.org Subject: [Megaco] even H.248.2 has typos 1.... In section 7.1.6 of H.248.2, ctyp property is titled PhasereversalDetect, but the propertyID is given as v8bsup, which is copi= ed =66rom the property in 7.1.3. I assume the propertyID was intended to be PhasereversalDetect. 2.... In section 8.1.2, fax property ftrpt has possible values T3= 0, T30ECM and T.30V34. This is syntactically permitted, but I think for consistency the author did not intend the last value to include a dot. Raphael Tryster ------=_NextPart_000_0174_01C572BE.3BC7CDF0 Content-Type: text/html; charset="WINDOWS-1255" Content-Transfer-Encoding: Quoted-Printable order of = descriptors in remote ringback scenario

Raphael,
 
I = checked the=20 November draft that was for Consent in SG16, and it had at least =  the=20 conflict of ctyp/dtone, parameter dtt values DTMF = and Sig=20 resolved.
A = lot of other=20 cleaning and adding good functionality for more automonous call type=20 discrimination.
 
So, = you should=20 have the latest approved ITU version before you start detailed=20 review.
 
Regards
 
Gunnar=20 Hellström

-------------------------------------------
Gunnar=20 Hellström
Omnitor AB
Renathvägen 2
SE 121 37=20 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204=20 288
www.omnitor.se
Gunnar.Hellstrom@Omnitor.se
-----------------= ---------------------------
 =20

-----Original Message-----
From: = megaco-bounces@ietf.org=20 [mailto:megaco-bounces@ietf.org]On Behalf Of Raphael=20 Tryster
Sent: Thursday, June 16, 2005 10:20 PM
To: = megaco@ietf.org
Subject: RE: [Megaco] even H.248.2 has=20 typos

Also=20 for ctyp/dtone, parameter dtt has values DTMF and Sig which are both=20 0x000B.

For=20 ctyp/v8bs, parameter v8bsn has values MRdrl and Crel which are both = 0x0006,=20 and Creh and Crdi which are both = 0x0007.

 

Raphael = Tryster

 

<= SPAN=20 class=3DEmailStyle22> 

-----Original=20 Message-----
From: = Raphael=20 Tryster
Sent: = Thursday, June=20 16, 2005 9:14 PM
To: 'Kevin=20 Boyle'; megaco@ietf.org
Subject: RE: [Megaco] even = H.248.2 has=20 typos

 

I=20 noticed something else.  = The basic=20 Megaco packages and others, e.g. H.248.23, do not have any identifiers = of=20 events, signals, properties and statistics with the same values as one = another.  I had the = impression=20 that this was a requirement.  = But=20 several of the packages in H.248.2 start their events, signals, = properties and=20 statistics identifiers at 0x0001. =20 Does it matter?

 

One=20 thing that probably does matter is that in fax package, properties = faxstate=20 and ftrpt both have propertyID =3D = 0x0001.

 

Raphael = Tryster

 

<= SPAN=20 class=3DEmailStyle21> 

-----Original=20 Message-----
From: = Kevin=20 Boyle [mailto:kboyle@nortel.com]
Sent: Thursday, June 16, 2005 = 5:45=20 PM
To: Raphael = Tryster;=20 megaco@ietf.org
Subject: RE:=20 [Megaco] even H.248.2 has typos

 

H.248.2=20 was revised at the November 2004 meeting of SG16.  The new spec = is dated=20 01/2005.

 

Kevin

 

From: Raphael = Tryster=20 [mailto:raphael@tdsoft.com]
Sent: Thursday, June 16, 2005 = 12:46=20 PM
To: Boyle, Kevin = [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: RE: [Megaco] even = H.248.2 has=20 typos

The=20 revision in which I found these is dated 11/2000, which was the = current=20 edition at least to the end of 2004. =20 =93This=20 Recommendation was first approved and published as Annex F to H.248, = and then=20 renumbered as H.248.2 on 2002-03-29 without further=20 modification=94.  I don=92t know what has = happened in=20 2005.

 

Raphael = Tryster

 

<= SPAN=20 class=3DEmailStyle20> 

-----Original=20 Message-----
From: = Kevin=20 Boyle [mailto:kboyle@nortel.com]
Sent: Thursday, June 16, 2005 = 5:33=20 PM
To: Raphael = Tryster;=20 megaco@ietf.org
Subject: RE:=20 [Megaco] even H.248.2 has typos

 

Are=20 these in the revision that was recently issued?  If so, I will = add an IG=20 item to fix these.

 

Kevin

 

From:=20 megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Raphael = Tryster
Sent: Thursday, June 16, 2005 = 12:33=20 PM
To:=20 megaco@ietf.org
Subject:=20 [Megaco] even H.248.2 has typos

1....      =20 In=20 section 7.1.6 of H.248.2, ctyp property is titled PhasereversalDetect, = but the=20 propertyID is given as v8bsup, which is copied from the property in=20 7.1.3.  I assume the = propertyID=20 was intended to be = PhasereversalDetect.

 

2....      =20 In=20 section 8.1.2, fax property ftrpt has possible values T30, T30ECM and=20 T.30V34.  This is = syntactically=20 permitted, but I think for consistency the author did not intend the = last=20 value to include a dot.

 

Raphael = Tryster

 

<= FONT=20 color=3Dblack> 

 

------=_NextPart_000_0174_01C572BE.3BC7CDF0-- --===============0004916280== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0004916280==-- From megaco-bounces@ietf.org Thu Jun 16 17:16:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj1iu-00009r-8Z; Thu, 16 Jun 2005 17:16:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj1is-00008e-6J for megaco@megatron.ietf.org; Thu, 16 Jun 2005 17:16:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16432 for ; Thu, 16 Jun 2005 17:16:18 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj25o-0008Ay-Au for megaco@ietf.org; Thu, 16 Jun 2005 17:40:08 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j5GLF5c12597 for ; Thu, 16 Jun 2005 17:15:05 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jun 2005 17:16:04 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4028ADA00@zrtphxm2> From: "Kevin Boyle" To: Gunnar Hellstrom , Raphael Tryster , megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos Date: Thu, 16 Jun 2005 17:15:50 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: 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 Yes, there were a significant number of typographical errors in H.248.2 that were resolved by IG items. All these IG items were incorporated into the revision of H.248.2. I would suggest having a look at the more recent document and seeing if the problems still exist. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Gunnar Hellstrom Sent: Thursday, June 16, 2005 3:56 PM To: Raphael Tryster; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos Raphael, I checked the November draft that was for Consent in SG16, and it had at least the conflict of ctyp/dtone, parameter dtt values DTMF and Sig resolved. A lot of other cleaning and adding good functionality for more automonous call type discrimination. So, you should have the latest approved ITU version before you start detailed review. Regards Gunnar Hellström ------------------------------------------- Gunnar Hellström Omnitor AB Renathvägen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On Behalf Of Raphael Tryster Sent: Thursday, June 16, 2005 10:20 PM To: megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos Also for ctyp/dtone, parameter dtt has values DTMF and Sig which are both 0x000B. For ctyp/v8bs, parameter v8bsn has values MRdrl and Crel which are both 0x0006, and Creh and Crdi which are both 0x0007. Raphael Tryster -----Original Message----- From: Raphael Tryster Sent: Thursday, June 16, 2005 9:14 PM To: 'Kevin Boyle'; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos I noticed something else. The basic Megaco packages and others, e.g. H.248.23, do not have any identifiers of events, signals, properties and statistics with the same values as one another. I had the impression that this was a requirement. But several of the packages in H.248.2 start their events, signals, properties and statistics identifiers at 0x0001. Does it matter? One thing that probably does matter is that in fax package, properties faxstate and ftrpt both have propertyID = 0x0001. Raphael Tryster -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Thursday, June 16, 2005 5:45 PM To: Raphael Tryster; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos H.248.2 was revised at the November 2004 meeting of SG16. The new spec is dated 01/2005. Kevin _____ From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, June 16, 2005 12:46 PM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos The revision in which I found these is dated 11/2000, which was the current edition at least to the end of 2004. "This Recommendation was first approved and published as Annex F to H.248, and then renumbered as H.248.2 on 2002-03-29 without further modification". I don't know what has happened in 2005. Raphael Tryster -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Thursday, June 16, 2005 5:33 PM To: Raphael Tryster; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos Are these in the revision that was recently issued? If so, I will add an IG item to fix these. Kevin _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Raphael Tryster Sent: Thursday, June 16, 2005 12:33 PM To: megaco@ietf.org Subject: [Megaco] even H.248.2 has typos 1.... In section 7.1.6 of H.248.2, ctyp property is titled PhasereversalDetect, but the propertyID is given as v8bsup, which is copied from the property in 7.1.3. I assume the propertyID was intended to be PhasereversalDetect. 2.... In section 8.1.2, fax property ftrpt has possible values T30, T30ECM and T.30V34. This is syntactically permitted, but I think for consistency the author did not intend the last value to include a dot. Raphael Tryster _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 16 19:35:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj3tT-0005df-Gn; Thu, 16 Jun 2005 19:35:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj3tR-0005bu-Lv for megaco@megatron.ietf.org; Thu, 16 Jun 2005 19:35:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26561 for ; Thu, 16 Jun 2005 19:35:22 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.192]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj4GN-0007T5-V0 for megaco@ietf.org; Thu, 16 Jun 2005 19:59:15 -0400 Received: by wproxy.gmail.com with SMTP id 71so763728wra for ; Thu, 16 Jun 2005 16:35:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SjR+hBImSRga0jrgrZHcYjh9eqo+1OMp0/pb1lFrerwo41OMQJsa9c0jzbLBELjMM/vyO2vpqBugAKtPz/lUlYZtZsiPkv7W8v9X6L7/2LMciQD6KQNXX3jMTnrfMQwI5NmUxuSK4lh20+yKzVfHEoqtsjGhU/i35AfXD2LoM7Y= Received: by 10.54.143.4 with SMTP id q4mr923145wrd; Thu, 16 Jun 2005 16:35:17 -0700 (PDT) Received: by 10.54.126.1 with HTTP; Thu, 16 Jun 2005 16:35:16 -0700 (PDT) Message-ID: Date: Thu, 16 Jun 2005 16:35:16 -0700 From: John Lazarus To: megaco@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Subject: [Megaco] StreamID of 0 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Lazarus 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 default StreamID for events and signals within their respective descrip= tors is 0, indicating that they are not related to a specific media stream.=20 Does this mean that events and signals that are related to media, such as DTMF events or announcements, either: a) require that a valid StreamID for the termination be specified in order for them to be detected/generated, or, b) that they will be detected/generated on any/all appropriate streams? In other words, if no StreamID has been specified in the Local/Remote descriptors, can DTMF events or announcements be detected/generated without having a StreamID =3D 1 specified for the event/signal? Thanks in advance, John _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 16 20:05:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj4Me-0002w5-VM; Thu, 16 Jun 2005 20:05:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj4Mc-0002vz-Vn for megaco@megatron.ietf.org; Thu, 16 Jun 2005 20:05:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28416 for ; Thu, 16 Jun 2005 20:05:34 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj4jb-0000d5-Rf for megaco@ietf.org; Thu, 16 Jun 2005 20:29:25 -0400 Received: by wproxy.gmail.com with SMTP id 71so769783wri for ; Thu, 16 Jun 2005 17:05:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lqMn21kl0WNwec98uDWy6vAKVyX8h62HKOGHxm11QvONzxBlmXXwKcxr3Pwin/utrnkxX5aen+BtL/S2AnSOIsSwK35n1NBujcvAn+8EdMMVnOpLSXz6PolJ1+YMmEwRVF0bhu4EJasm17b0oCoevZQECGQ8lc6AbM+spmMmaIE= Received: by 10.54.116.2 with SMTP id o2mr920612wrc; Thu, 16 Jun 2005 17:05:29 -0700 (PDT) Received: by 10.54.126.1 with HTTP; Thu, 16 Jun 2005 17:05:29 -0700 (PDT) Message-ID: Date: Thu, 16 Jun 2005 17:05:29 -0700 From: John Lazarus To: Kevin Boyle Subject: Re: [Megaco] order of descriptors in remote ringback scenario In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4027326DF@zrtphxm2> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <34B3EAA5B3066A42914D28C5ECF5FEA4027326DF@zrtphxm2> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: megaco@ietf.org, Raphael Tryster X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Lazarus List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org I would have thought that a 441 "Missing Remote or Local Descriptor" would be generated if a Signal is requested to be played and there is no Remote descriptor. If this is not the case, when would this error be generated? John On 6/14/05, Kevin Boyle wrote: > While yes, the remote descriptor must be present in order for the far end= to > hear the signal, that itself does not preclude the signal from being > applied. This is similar in concept to talking into a muted phone -- the > talker is certainly making noise, but the other end cannot hear anything. >=20 > Kevin >=20 >=20 > _____ >=20 > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf = Of > Raphael Tryster > Sent: Tuesday, June 14, 2005 10:35 AM > To: megaco@ietf.org > Subject: [Megaco] order of descriptors in remote ringback scenario >=20 >=20 >=20 > "Descriptors may appear as parameters to commands in any order. The > descriptors SHALL be processed in the order in which they appear". >=20 > When remote ringback is required, the MGC adds an ephemeral termination t= o > the context containing the called party, with signal descriptor cg/rt, an= d > remote descriptor giving the address of the calling party who should hear > the ringback tone. If the called party's MG processes the signal descrip= tor > before the remote descriptor, it will not know where to send the ringback > signal. Therefore, the MGC must place the ephemeral termination's media > descriptor before the signal descriptor. Is this correct? >=20 > Raphael Tryster >=20 >=20 >=20 >=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 From megaco-bounces@ietf.org Thu Jun 16 22:53:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj6yd-0007yr-Iu; Thu, 16 Jun 2005 22:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj6yb-0007yi-5k for megaco@megatron.ietf.org; Thu, 16 Jun 2005 22:53:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07847 for ; Thu, 16 Jun 2005 22:52:55 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj7Lb-00011s-JG for megaco@ietf.org; Thu, 16 Jun 2005 23:16:48 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CB2E3AD2; Fri, 17 Jun 2005 04:52:41 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Jun 2005 04:52:41 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Jun 2005 04:52:40 +0200 Received: from [146.11.22.39] (EG2E500202DSEGL [146.11.22.39]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MLXTQTV4; Fri, 17 Jun 2005 12:52:35 +1000 Message-ID: <42B23B21.5040402@ericsson.com> Date: Fri, 17 Jun 2005 12:53:21 +1000 X-Sybari-Trust: f4b18f22 3280b041 a9842e33 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Steve Cipolli Subject: Re: [Megaco] Conformance tests question References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jun 2005 02:52:40.0645 (UTC) FILETIME=[A08BB750:01C572E7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b 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 G'Day Steve, Yes, it seems I got ahead of myself and read SEQUENCE when in fact the ASN.1 reads CHOICE... On the 2nd point I'm dsylexic when it comes to the use of ? and $. On the 3rd point: I was trying to thing laterally. Rather than trying to update syntax and causes problems I was thinking that perhaps we could had a warning to avoid transactions could cause this problem. Eg. those with optional flags and multiple c=$ in them or the c=$ not being first. As for returning c=$ (or 0xFFFFFFFE in binary) this is probably OK as it is only in the TransactionReply direction and the MGC can't send a reply to a reply. There's no argument for v3, this can be fixed syntactically. Regards, Christian Steve Cipolli wrote: > Christian, > > I agree that avoiding any incompatible change to v1 and v2 is the ideal > solution. However, I'm not sure I follow your alternative: > > First, the problem is not encoding specific. 8.2.2 applies to both > binary and text encoding (the ABNF also allows '$', but 8.2.2 prohibits > its use in replies). My reading of the ASN.1 does not allow action > replies and an action-level error in the same reply, just as the ABNF > does not. > > Second, I think you mean "... Implementors issue C=$ as the first action > in the transaction ", not "... Implementors issue C=? as the first > command in the transaction". > > Third, there maybe multiple actions with a context of '$'. How would an > MGC know which of these actions might fail? > > --Stephen > > >>-----Original Message----- >>From: Christian Groves [mailto:christian.groves@ericsson.com] >>Sent: Thursday, June 16, 2005 3:26 AM >>To: Steve Cipolli >>Cc: Kevin Boyle; Frank Reno; megaco@ietf.org >>Subject: Re: [Megaco] Conformance tests question >> >> >>Hello, >> >>I'm not really in favour of option 1 or 2. Relaxing 8.2.2 is >>still a protocol >>change. You may not be updating the syntax but something >>different will be sent >>in the protocol. Also by relaxing 8.2.2 you will also be >>making a change to the >>binary protocol. >> >>I think the only choice is to issue a note for V1 and V2 that >>for the text >>encoding that implementors issue the C=? as the first command >>in a transaction. >>In v3 update the syntax so that this is fixed properly. >> >>Regards, Christian >> >>Steve Cipolli wrote: >> >> >>>Kevin, >>> >>>I assume that v3 will have to support both choice #1 and #2 >> >>if we choose >> >>>choice #1 for v1 and v2. That said, I believe this will >> >>mean that most >> >>>implementations will use the form from choice #1 even for >> >>v3. I'm OK >> >>>with that, but it is something to consider. >>> >>>My preference would be to do choice #1 and choice #2 in all >> >>versions. >> >>>This way anyone who has to change their implementation because they >>>currently do not allow $ could as easily use the form from >> >>choice #2. >> >>>This will make it more likely that choice #2 is used in version 3. >>> >>>The downside to both choices is that they could create >> >>incompatibilies >> >>>between new implementations of v1 (or v2) vs old >> >>implementations of v1 >> >>>(or v2), but I see the risk the same for either choice. >>> >>>--Stephen >>> >>>-----Original Message----- >>>From: Kevin Boyle [mailto:kboyle@nortel.com] >>>Sent: Wednesday, June 15, 2005 9:40 AM >>>To: Steve Cipolli; Frank Reno; megaco@ietf.org >>>Subject: RE: [Megaco] Conformance tests question >>> >>> >>>Well, the two choices are: 1) lift this restriction in the text for >>>the particular case of an error response for a second action in a >>>transaction; or 2) change the ABNF syntax of the protocol. >> >>I believe >> >>>the better choice for V1 and V2 is to do the former, since >> >>no parsing >> >>>changes will be required. For V3 we should choose the >> >>latter, since >> >>>this appears to be an oversight in the grammar. >>> >>>Kevin >>> >>> >>> _____ >>> >>>From: Steve Cipolli [mailto:SCipolli@radvision.com] >>>Sent: Tuesday, June 14, 2005 5:41 PM >>>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org >>>Subject: RE: [Megaco] Conformance tests question >>> >>> >>> >>>As the original poster pointed out, 8.2.2 says: >>> >>>8.2.2 TransactionReply >>> >>>... >>>The ContextID parameter must specify a value to pertain to all >>>Responses for the action. The ContextID may be specific, >> >>all or null. >> >>> >>>--Stephen >>> >>>-----Original Message----- >>>From: Kevin Boyle [mailto:kboyle@nortel.com] >>>Sent: Tuesday, June 14, 2005 4:53 PM >>>To: Steve Cipolli; Frank Reno; megaco@ietf.org >>>Subject: RE: [Megaco] Conformance tests question >>> >>> >>> >>>Where do you see that restriction? >>> >>>Kevin >>> >>>-----Original Message----- >>>From: Steve Cipolli [mailto:SCipolli@radvision.com >>> ] >>>Sent: Tuesday, June 14, 2005 2:21 PM >>>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org >>>Subject: RE: [Megaco] Conformance tests question >>> >>>Kevin, >>> >>>Allowing '$' for context in replies also violates v1 and v2, so it >>>appears there is no solution at all for v1 and v2. Do you >> >>mean that >> >>>the IG for v1 and v2 should be updated to allow '$' for context in >>>replies? >>> >>>--Stephen >>> >>> >>> >>>>-----Original Message----- >>>>From: megaco-bounces@ietf.org >>>>[ >> >>mailto:megaco-bounces@ietf.org] On >> >>>Behalf Of Kevin Boyle >>> >>> >>>>Sent: Tuesday, June 14, 2005 12:36 PM >>>>To: Frank Reno; megaco@ietf.org >>>>Subject: RE: [Megaco] Conformance tests question >>>> >>>> >>>>This seems like a problem with the syntax of the protocol. >>>>Since we clearly allow error descriptors at the action >> >>level, and we >> >>>>allow following errors at the transaction and command levels, this >>>>appears to need fixing. It appears that the binary >> >>encoding allows an >> >>> >>>>error at the action level for the second (or subsequent) action in a >>>>transaction. >>>> >>>>The fix itself would be straightforward, though non-backwards >>>>compatible. This would mean that it would have to be in V3, and not >>>>made retroactive to V1 and V2. The fix would be: >>>> >>>>transactionReply = ReplyToken EQUAL TransactionID LBRKT >>>> [ImmAckRequiredToken COMMA](errorDescriptor / >>>> actionReplyList [COMMA errorDescriptor]) >> >>RBRKT Fix >> >>>>is here------------------------^^^^^^^^^^^^^^^^^^^^^^^ >>>> >>>>So, for V1 and V2, it would appear that your solution, though >>>>suboptimal in my view, is the only solution available within the >>>>syntax as defined. >>>> >>>>Kevin >>>> >>>> >>>>-----Original Message----- >>>>From: megaco-bounces@ietf.org >>>>[ >> >>mailto:megaco-bounces@ietf.org] On >> >>>Behalf Of Frank Reno >>> >>> >>>>Sent: Friday, June 10, 2005 3:49 PM >>>>To: megaco@ietf.org >>>>Subject: RE: [Megaco] Conformance tests question >>>> >>>>If an action fails with a context ID of CHOOSE and it is >> >>not the first >> >>> >>>>action in the transaction, then the error can't be placed at the >>>>action level, since the grammar does not permit action >> >>replies and an >> >>>>action level error descriptor in the same transaction reply. >>>> >>>>So it looks like CHOOSE should be allowed in the reply. >>>> >>>>Given >>>> >>>>T = 1 >>>>{ >>>> C = 1 { Add = t1 }, >>>> C = $ { Add = t2 } >>>>} >>>> >>>>This is not legal: >>>> >>>>Reply = 1 >>>>{ >>>> C = 1 { Add = t1 }, >>>> Error = 412 {} >>>>} >>>> >>>>So it would have to be: >>>> >>>>Reply = 1 >>>>{ >>>> C = 1 { Add = t1 }, >>>> C = $ { Error = 412 {}} >>>>} >>>> >>>>Frank >>>> >>>> >>>> >>>>--- Kevin Boyle wrote: >>>> >>>>In most cases, the MG knows it cannot allocate a context at the time >>>>the request is detected -- that is, once the action is >> >>parsed. If the >> >>> >>>>MG detects a problem, why would it continue to parse? >>>>The error descriptor >>>>ought to be placed at the action level, so there would not be a >>>>context indicated of any kind, let alone a CHOOSE wildcard. >>>> >>>>Remember, error detection occurs at the earliest possible time with >>>>the error descriptor occurring at the level of detection. >>>>If the MG was not >>>>able to detect that it was unable to allocate a context until the >>>>command or descriptor level, then the error descriptor >> >>would go at the >> >>> >>>>lower level. >>>> >>>>Kevin >>> >>> [SNIP...] >>> >>> >>> >>> >> >>---------------------------------------------------------------------- >> >>>-- >>> >>>_______________________________________________ >>>Megaco mailing 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 Fri Jun 17 14:37:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjLie-0002pP-Lh; Fri, 17 Jun 2005 14:37:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjLic-0002pK-Ju for megaco@megatron.ietf.org; Fri, 17 Jun 2005 14:37:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11445 for ; Fri, 17 Jun 2005 14:37:28 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjM5l-0001DV-Tm for megaco@ietf.org; Fri, 17 Jun 2005 15:01:26 -0400 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 Subject: RE: [Megaco] Conformance tests question Date: Fri, 17 Jun 2005 14:37:22 -0400 Message-ID: Thread-Topic: [Megaco] Conformance tests question Thread-Index: AcVy56OaK+hh/9cfQpm6MU6S3p0HxgAf8UIw From: "Steve Cipolli" To: "Christian Groves" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b 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 Christian/Kevin, I think we all agree that allowing $ for context in replies is the right thing to do in v1 and v2, and by compatibility rules also in v3. I think we all also agree that both action replies and action-level errors in a reply should be allowed in v3. =20 My argument is that if we are going to make what amounts to an incompatible change in v1 and v2 to allow $ to be specified for context in replies, then we may as well make the change to allow action replies and action-level errors in a single transaction reply as well. Both changes run the same risk and have the same ramifications when an incompatibility occurs. =20 The only difference between the two solutions is that the $ change is likely to be far easier to implement, since the parser should already allow it. If not for this difference I would argue that we should only support (in all versions) the change to allow action replies and action-level errors in the same transaction reply. --Stephen > -----Original Message----- > From: Christian Groves [mailto:christian.groves@ericsson.com]=20 > Sent: Thursday, June 16, 2005 10:53 PM > To: Steve Cipolli > Cc: Kevin Boyle; Frank Reno; megaco@ietf.org > Subject: Re: [Megaco] Conformance tests question >=20 >=20 > G'Day Steve, >=20 > Yes, it seems I got ahead of myself and read SEQUENCE when in=20 > fact the ASN.1=20 > reads CHOICE... On the 2nd point I'm dsylexic when it comes=20 > to the use of ? and $. >=20 > On the 3rd point: I was trying to thing laterally. Rather=20 > than trying to update=20 > syntax and causes problems I was thinking that perhaps we=20 > could had a warning to=20 > avoid transactions could cause this problem. Eg. those with=20 > optional flags and=20 > multiple c=3D$ in them or the c=3D$ not being first. >=20 > As for returning c=3D$ (or 0xFFFFFFFE in binary) this is=20 > probably OK as it is only=20 > in the TransactionReply direction and the MGC can't send a=20 > reply to a reply. >=20 > There's no argument for v3, this can be fixed syntactically. >=20 > Regards, Christian >=20 > Steve Cipolli wrote: >=20 > > Christian, > >=20 > > I agree that avoiding any incompatible change to v1 and v2 is the=20 > > ideal solution. However, I'm not sure I follow your alternative: > >=20 > > First, the problem is not encoding specific. 8.2.2 applies to both=20 > > binary and text encoding (the ABNF also allows '$', but 8.2.2=20 > > prohibits its use in replies). My reading of the ASN.1=20 > does not allow=20 > > action replies and an action-level error in the same reply, just as=20 > > the ABNF does not. > >=20 > > Second, I think you mean "... Implementors issue C=3D$ as the first=20 > > action in the transaction ", not "... Implementors issue C=3D? as = the=20 > > first command in the transaction". > >=20 > > Third, there maybe multiple actions with a context of '$'. =20 > How would=20 > > an MGC know which of these actions might fail? > >=20 > > --Stephen > >=20 > >=20 > >>-----Original Message----- > >>From: Christian Groves [mailto:christian.groves@ericsson.com] > >>Sent: Thursday, June 16, 2005 3:26 AM > >>To: Steve Cipolli > >>Cc: Kevin Boyle; Frank Reno; megaco@ietf.org > >>Subject: Re: [Megaco] Conformance tests question > >> > >> > >>Hello, > >> > >>I'm not really in favour of option 1 or 2. Relaxing 8.2.2 is > >>still a protocol=20 > >>change. You may not be updating the syntax but something=20 > >>different will be sent=20 > >>in the protocol. Also by relaxing 8.2.2 you will also be=20 > >>making a change to the=20 > >>binary protocol. > >> > >>I think the only choice is to issue a note for V1 and V2 that > >>for the text=20 > >>encoding that implementors issue the C=3D? as the first command=20 > >>in a transaction.=20 > >>In v3 update the syntax so that this is fixed properly. > >> > >>Regards, Christian > >> > >>Steve Cipolli wrote: > >> > >> > >>>Kevin, > >>>=20 > >>>I assume that v3 will have to support both choice #1 and #2 > >> > >>if we choose > >> > >>>choice #1 for v1 and v2. That said, I believe this will=20 > >> > >>mean that most > >> > >>>implementations will use the form from choice #1 even for > >> > >>v3. I'm OK > >> > >>>with that, but it is something to consider. > >>>=20 > >>>My preference would be to do choice #1 and choice #2 in all > >> > >>versions. > >> > >>>This way anyone who has to change their implementation because they > >>>currently do not allow $ could as easily use the form from=20 > >> > >>choice #2. > >> > >>>This will make it more likely that choice #2 is used in version 3. > >>>=20 > >>>The downside to both choices is that they could create > >> > >>incompatibilies > >> > >>>between new implementations of v1 (or v2) vs old > >> > >>implementations of v1 > >> > >>>(or v2), but I see the risk the same for either choice. > >>>=20 > >>>--Stephen > >>> > >>>-----Original Message----- > >>>From: Kevin Boyle [mailto:kboyle@nortel.com] > >>>Sent: Wednesday, June 15, 2005 9:40 AM > >>>To: Steve Cipolli; Frank Reno; megaco@ietf.org > >>>Subject: RE: [Megaco] Conformance tests question > >>> > >>> > >>>Well, the two choices are: 1) lift this restriction in the text for > >>>the particular case of an error response for a second action in a=20 > >>>transaction; or 2) change the ABNF syntax of the protocol. =20 > >> > >>I believe > >> > >>>the better choice for V1 and V2 is to do the former, since > >> > >>no parsing > >> > >>>changes will be required. For V3 we should choose the > >> > >>latter, since > >> > >>>this appears to be an oversight in the grammar. > >>>=20 > >>>Kevin > >>> > >>> > >>> _____ > >>> > >>>From: Steve Cipolli [mailto:SCipolli@radvision.com] > >>>Sent: Tuesday, June 14, 2005 5:41 PM > >>>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org > >>>Subject: RE: [Megaco] Conformance tests question > >>> > >>> > >>>=20 > >>>As the original poster pointed out, 8.2.2 says: > >>>=20 > >>>8.2.2 TransactionReply > >>>=20 > >>>... > >>>The ContextID parameter must specify a value to pertain to all > >>>Responses for the action. The ContextID may be specific,=20 > >> > >>all or null. > >> > >>>=20 > >>>--Stephen > >>> > >>>-----Original Message----- > >>>From: Kevin Boyle [mailto:kboyle@nortel.com] > >>>Sent: Tuesday, June 14, 2005 4:53 PM > >>>To: Steve Cipolli; Frank Reno; megaco@ietf.org > >>>Subject: RE: [Megaco] Conformance tests question > >>> > >>> > >>> > >>>Where do you see that restriction? > >>> > >>>Kevin > >>> > >>>-----Original Message----- > >>>From: Steve Cipolli [mailto:SCipolli@radvision.com=20 > >>> ] > >>>Sent: Tuesday, June 14, 2005 2:21 PM > >>>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org=20 > >>>Subject: RE: [Megaco] Conformance tests question=20 > >>> > >>>Kevin, > >>> > >>>Allowing '$' for context in replies also violates v1 and v2, so it > >>>appears there is no solution at all for v1 and v2. Do you=20 > >> > >>mean that > >> > >>>the IG for v1 and v2 should be updated to allow '$' for context in > >>>replies? > >>> > >>>--Stephen > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: megaco-bounces@ietf.org > >>>>[ =20 > >> > >>mailto:megaco-bounces@ietf.org] On > >> > >>>Behalf Of Kevin Boyle > >>> > >>> > >>>>Sent: Tuesday, June 14, 2005 12:36 PM > >>>>To: Frank Reno; megaco@ietf.org > >>>>Subject: RE: [Megaco] Conformance tests question=20 > >>>> > >>>> > >>>>This seems like a problem with the syntax of the=20 > protocol. Since we=20 > >>>>clearly allow error descriptors at the action > >> > >>level, and we > >> > >>>>allow following errors at the transaction and command levels, this > >>>>appears to need fixing. It appears that the binary=20 > >> > >>encoding allows an > >> > >>> > >>>>error at the action level for the second (or subsequent)=20 > action in a=20 > >>>>transaction. > >>>> > >>>>The fix itself would be straightforward, though non-backwards=20 > >>>>compatible. This would mean that it would have to be in=20 > V3, and not=20 > >>>>made retroactive to V1 and V2. The fix would be: > >>>> > >>>>transactionReply =3D ReplyToken EQUAL TransactionID LBRKT=20 > >>>> [ImmAckRequiredToken COMMA](errorDescriptor /=20 > >>>> actionReplyList [COMMA errorDescriptor]) > >> > >>RBRKT Fix > >> > >>>>is here------------------------^^^^^^^^^^^^^^^^^^^^^^^ > >>>> > >>>>So, for V1 and V2, it would appear that your solution, though=20 > >>>>suboptimal in my view, is the only solution available within the=20 > >>>>syntax as defined. > >>>> > >>>>Kevin > >>>> > >>>> > >>>>-----Original Message----- > >>>>From: megaco-bounces@ietf.org > >>>>[ =20 > >> > >>mailto:megaco-bounces@ietf.org] On > >> > >>>Behalf Of Frank Reno > >>> > >>> > >>>>Sent: Friday, June 10, 2005 3:49 PM > >>>>To: megaco@ietf.org > >>>>Subject: RE: [Megaco] Conformance tests question=20 > >>>> > >>>>If an action fails with a context ID of CHOOSE and it is > >> > >>not the first > >> > >>> > >>>>action in the transaction, then the error can't be placed at the=20 > >>>>action level, since the grammar does not permit action > >> > >>replies and an > >> > >>>>action level error descriptor in the same transaction reply. > >>>> > >>>>So it looks like CHOOSE should be allowed in the reply. > >>>> > >>>>Given > >>>> > >>>>T =3D 1 > >>>>{=20 > >>>> C =3D 1 { Add =3D t1 },=20 > >>>> C =3D $ { Add =3D t2 } > >>>>}=20 > >>>> > >>>>This is not legal: > >>>> > >>>>Reply =3D 1 > >>>>{=20 > >>>> C =3D 1 { Add =3D t1 },=20 > >>>> Error =3D 412 {} > >>>>}=20 > >>>> > >>>>So it would have to be: > >>>> > >>>>Reply =3D 1 > >>>>{=20 > >>>> C =3D 1 { Add =3D t1 },=20 > >>>> C =3D $ { Error =3D 412 {}} > >>>>}=20 > >>>> > >>>>Frank > >>>> > >>>> > >>>> > >>>>--- Kevin Boyle wrote: > >>>> > >>>>In most cases, the MG knows it cannot allocate a context=20 > at the time=20 > >>>>the request is detected -- that is, once the action is > >> > >>parsed. If the > >> > >>> > >>>>MG detects a problem, why would it continue to parse? > >>>>The error descriptor > >>>>ought to be placed at the action level, so there would not be a=20 > >>>>context indicated of any kind, let alone a CHOOSE wildcard.=20 > >>>> > >>>>Remember, error detection occurs at the earliest possible=20 > time with=20 > >>>>the error descriptor occurring at the level of detection.=20 > If the MG=20 > >>>>was not able to detect that it was unable to allocate a context=20 > >>>>until the command or descriptor level, then the error descriptor > >> > >>would go at the > >> > >>> > >>>>lower level. > >>>> > >>>>Kevin > >>> > >>> [SNIP...] > >>> > >>> > >>> > >>> > >> > >>------------------------------------------------------------ > ---------- > >> > >>>-- > >>> > >>>_______________________________________________ > >>>Megaco mailing list > >>>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >> > >> > >=20 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 17 19:03:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjPro-0003GR-1F; Fri, 17 Jun 2005 19:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjPrm-0003GM-LY for megaco@megatron.ietf.org; Fri, 17 Jun 2005 19:03:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00647 for ; Fri, 17 Jun 2005 19:03:10 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjQEx-0002zQ-M7 for megaco@ietf.org; Fri, 17 Jun 2005 19:27:12 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5HN2tf03807 for ; Fri, 17 Jun 2005 19:02:55 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jun 2005 19:02:56 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40292A7AA@zrtphxm2> From: "Kevin Boyle" To: Steve Cipolli , Christian Groves Subject: RE: [Megaco] Conformance tests question Date: Fri, 17 Jun 2005 19:02:52 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 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 I think we are all agree on the correction, too. Ideally, we would make the syntax change to allow a second CHOOSE action in a transaction return an action-level error. However, given that this requires a syntax change, it is only something that we can consider for V3. I am editing that into the document as a fix this weekend. As an informational note, we try not to change syntax definitions unless there is a critical need for a fix. A good example of this was the EnergencyOff flag to allow removal of the emergency designation from a context. If we can get around a syntax problem by altering the semantics and procedures of the protocol, that is more acceptable because it doesn't break everybody's parser. Kevin -----Original Message----- From: Steve Cipolli [mailto:SCipolli@radvision.com] Sent: Friday, June 17, 2005 2:37 PM To: Christian Groves Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org Subject: RE: [Megaco] Conformance tests question Christian/Kevin, I think we all agree that allowing $ for context in replies is the right thing to do in v1 and v2, and by compatibility rules also in v3. I think we all also agree that both action replies and action-level errors in a reply should be allowed in v3. My argument is that if we are going to make what amounts to an incompatible change in v1 and v2 to allow $ to be specified for context in replies, then we may as well make the change to allow action replies and action-level errors in a single transaction reply as well. Both changes run the same risk and have the same ramifications when an incompatibility occurs. The only difference between the two solutions is that the $ change is likely to be far easier to implement, since the parser should already allow it. If not for this difference I would argue that we should only support (in all versions) the change to allow action replies and action-level errors in the same transaction reply. --Stephen > -----Original Message----- > From: Christian Groves [mailto:christian.groves@ericsson.com] > Sent: Thursday, June 16, 2005 10:53 PM > To: Steve Cipolli > Cc: Kevin Boyle; Frank Reno; megaco@ietf.org > Subject: Re: [Megaco] Conformance tests question > > > G'Day Steve, > > Yes, it seems I got ahead of myself and read SEQUENCE when in fact the > ASN.1 reads CHOICE... On the 2nd point I'm dsylexic when it comes to > the use of ? and $. > > On the 3rd point: I was trying to thing laterally. Rather than trying > to update syntax and causes problems I was thinking that perhaps we > could had a warning to avoid transactions could cause this problem. > Eg. those with optional flags and multiple c=$ in them or the c=$ not > being first. > > As for returning c=$ (or 0xFFFFFFFE in binary) this is probably OK as > it is only in the TransactionReply direction and the MGC can't send a > reply to a reply. > > There's no argument for v3, this can be fixed syntactically. > > Regards, Christian > > Steve Cipolli wrote: > > > Christian, > > > > I agree that avoiding any incompatible change to v1 and v2 is the > > ideal solution. However, I'm not sure I follow your alternative: > > > > First, the problem is not encoding specific. 8.2.2 applies to both > > binary and text encoding (the ABNF also allows '$', but 8.2.2 > > prohibits its use in replies). My reading of the ASN.1 > does not allow > > action replies and an action-level error in the same reply, just as > > the ABNF does not. > > > > Second, I think you mean "... Implementors issue C=$ as the first > > action in the transaction ", not "... Implementors issue C=? as the > > first command in the transaction". > > > > Third, there maybe multiple actions with a context of '$'. > How would > > an MGC know which of these actions might fail? > > > > --Stephen > > > > > >>-----Original Message----- > >>From: Christian Groves [mailto:christian.groves@ericsson.com] > >>Sent: Thursday, June 16, 2005 3:26 AM > >>To: Steve Cipolli > >>Cc: Kevin Boyle; Frank Reno; megaco@ietf.org > >>Subject: Re: [Megaco] Conformance tests question > >> > >> > >>Hello, > >> > >>I'm not really in favour of option 1 or 2. Relaxing 8.2.2 is still a > >>protocol change. You may not be updating the syntax but something > >>different will be sent in the protocol. Also by relaxing 8.2.2 you > >>will also be making a change to the binary protocol. > >> > >>I think the only choice is to issue a note for V1 and V2 that for > >>the text encoding that implementors issue the C=? as the first > >>command in a transaction. > >>In v3 update the syntax so that this is fixed properly. > >> > >>Regards, Christian > >> > >>Steve Cipolli wrote: > >> > >> > >>>Kevin, > >>> > >>>I assume that v3 will have to support both choice #1 and #2 > >> > >>if we choose > >> > >>>choice #1 for v1 and v2. That said, I believe this will > >> > >>mean that most > >> > >>>implementations will use the form from choice #1 even for > >> > >>v3. I'm OK > >> > >>>with that, but it is something to consider. > >>> > >>>My preference would be to do choice #1 and choice #2 in all > >> > >>versions. > >> > >>>This way anyone who has to change their implementation because they > >>>currently do not allow $ could as easily use the form from > >> > >>choice #2. > >> > >>>This will make it more likely that choice #2 is used in version 3. > >>> > >>>The downside to both choices is that they could create > >> > >>incompatibilies > >> > >>>between new implementations of v1 (or v2) vs old > >> > >>implementations of v1 > >> > >>>(or v2), but I see the risk the same for either choice. > >>> > >>>--Stephen > >>> > >>>-----Original Message----- > >>>From: Kevin Boyle [mailto:kboyle@nortel.com] > >>>Sent: Wednesday, June 15, 2005 9:40 AM > >>>To: Steve Cipolli; Frank Reno; megaco@ietf.org > >>>Subject: RE: [Megaco] Conformance tests question > >>> > >>> > >>>Well, the two choices are: 1) lift this restriction in the text for > >>>the particular case of an error response for a second action in a > >>>transaction; or 2) change the ABNF syntax of the protocol. > >> > >>I believe > >> > >>>the better choice for V1 and V2 is to do the former, since > >> > >>no parsing > >> > >>>changes will be required. For V3 we should choose the > >> > >>latter, since > >> > >>>this appears to be an oversight in the grammar. > >>> > >>>Kevin > >>> > >>> > >>> _____ > >>> > >>>From: Steve Cipolli [mailto:SCipolli@radvision.com] > >>>Sent: Tuesday, June 14, 2005 5:41 PM > >>>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org > >>>Subject: RE: [Megaco] Conformance tests question > >>> > >>> > >>> > >>>As the original poster pointed out, 8.2.2 says: > >>> > >>>8.2.2 TransactionReply > >>> > >>>... > >>>The ContextID parameter must specify a value to pertain to all > >>>Responses for the action. The ContextID may be specific, > >> > >>all or null. > >> > >>> > >>>--Stephen > >>> > >>>-----Original Message----- > >>>From: Kevin Boyle [mailto:kboyle@nortel.com] > >>>Sent: Tuesday, June 14, 2005 4:53 PM > >>>To: Steve Cipolli; Frank Reno; megaco@ietf.org > >>>Subject: RE: [Megaco] Conformance tests question > >>> > >>> > >>> > >>>Where do you see that restriction? > >>> > >>>Kevin > >>> > >>>-----Original Message----- > >>>From: Steve Cipolli [mailto:SCipolli@radvision.com > >>> ] > >>>Sent: Tuesday, June 14, 2005 2:21 PM > >>>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; megaco@ietf.org > >>>Subject: RE: [Megaco] Conformance tests question > >>> > >>>Kevin, > >>> > >>>Allowing '$' for context in replies also violates v1 and v2, so it > >>>appears there is no solution at all for v1 and v2. Do you > >> > >>mean that > >> > >>>the IG for v1 and v2 should be updated to allow '$' for context in > >>>replies? > >>> > >>>--Stephen > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: megaco-bounces@ietf.org > >>>>[ > >> > >>mailto:megaco-bounces@ietf.org] On > >> > >>>Behalf Of Kevin Boyle > >>> > >>> > >>>>Sent: Tuesday, June 14, 2005 12:36 PM > >>>>To: Frank Reno; megaco@ietf.org > >>>>Subject: RE: [Megaco] Conformance tests question > >>>> > >>>> > >>>>This seems like a problem with the syntax of the > protocol. Since we > >>>>clearly allow error descriptors at the action > >> > >>level, and we > >> > >>>>allow following errors at the transaction and command levels, this > >>>>appears to need fixing. It appears that the binary > >> > >>encoding allows an > >> > >>> > >>>>error at the action level for the second (or subsequent) > action in a > >>>>transaction. > >>>> > >>>>The fix itself would be straightforward, though non-backwards > >>>>compatible. This would mean that it would have to be in > V3, and not > >>>>made retroactive to V1 and V2. The fix would be: > >>>> > >>>>transactionReply = ReplyToken EQUAL TransactionID LBRKT > >>>> [ImmAckRequiredToken COMMA](errorDescriptor / > >>>> actionReplyList [COMMA errorDescriptor]) > >> > >>RBRKT Fix > >> > >>>>is here------------------------^^^^^^^^^^^^^^^^^^^^^^^ > >>>> > >>>>So, for V1 and V2, it would appear that your solution, though > >>>>suboptimal in my view, is the only solution available within the > >>>>syntax as defined. > >>>> > >>>>Kevin > >>>> > >>>> > >>>>-----Original Message----- > >>>>From: megaco-bounces@ietf.org > >>>>[ > >> > >>mailto:megaco-bounces@ietf.org] On > >> > >>>Behalf Of Frank Reno > >>> > >>> > >>>>Sent: Friday, June 10, 2005 3:49 PM > >>>>To: megaco@ietf.org > >>>>Subject: RE: [Megaco] Conformance tests question > >>>> > >>>>If an action fails with a context ID of CHOOSE and it is > >> > >>not the first > >> > >>> > >>>>action in the transaction, then the error can't be placed at the > >>>>action level, since the grammar does not permit action > >> > >>replies and an > >> > >>>>action level error descriptor in the same transaction reply. > >>>> > >>>>So it looks like CHOOSE should be allowed in the reply. > >>>> > >>>>Given > >>>> > >>>>T = 1 > >>>>{ > >>>> C = 1 { Add = t1 }, > >>>> C = $ { Add = t2 } > >>>>} > >>>> > >>>>This is not legal: > >>>> > >>>>Reply = 1 > >>>>{ > >>>> C = 1 { Add = t1 }, > >>>> Error = 412 {} > >>>>} > >>>> > >>>>So it would have to be: > >>>> > >>>>Reply = 1 > >>>>{ > >>>> C = 1 { Add = t1 }, > >>>> C = $ { Error = 412 {}} > >>>>} > >>>> > >>>>Frank > >>>> > >>>> > >>>> > >>>>--- Kevin Boyle wrote: > >>>> > >>>>In most cases, the MG knows it cannot allocate a context > at the time > >>>>the request is detected -- that is, once the action is > >> > >>parsed. If the > >> > >>> > >>>>MG detects a problem, why would it continue to parse? > >>>>The error descriptor > >>>>ought to be placed at the action level, so there would not be a > >>>>context indicated of any kind, let alone a CHOOSE wildcard. > >>>> > >>>>Remember, error detection occurs at the earliest possible > time with > >>>>the error descriptor occurring at the level of detection. > If the MG > >>>>was not able to detect that it was unable to allocate a context > >>>>until the command or descriptor level, then the error descriptor > >> > >>would go at the > >> > >>> > >>>>lower level. > >>>> > >>>>Kevin > >>> > >>> [SNIP...] > >>> > >>> > >>> > >>> > >> > >>------------------------------------------------------------ > ---------- > >> > >>>-- > >>> > >>>_______________________________________________ > >>>Megaco mailing 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 Sun Jun 19 11:07:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk1O8-0001vk-Iv; Sun, 19 Jun 2005 11:07:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk1O6-0001vc-O1 for megaco@megatron.ietf.org; Sun, 19 Jun 2005 11:07:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12096 for ; Sun, 19 Jun 2005 11:07:04 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dk1lc-0006lq-8O for megaco@ietf.org; Sun, 19 Jun 2005 11:31:26 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1119194003; Sun Jun 19 18:07:27 2005 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Sun, 19 Jun 2005 18:10:15 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D3131@MAILSERVER> From: Raphael Tryster To: "'megaco@ietf.org'" Subject: RE: [Megaco] even H.248.2 has typos Date: Sun, 19 Jun 2005 18:10:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 4da339c42fe5be09fa120bb0fcc4a575 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="===============1991575820==" 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. --===============1991575820== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C574E9.5F0EBAD0" 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_01C574E9.5F0EBAD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Kevin and Gunnar, =20 Now I have seen the new version and see that all the typos I found were already addressed there. Sorry to have troubled you about obsolete thing= s. There remains only the question of whether more than one entity (event, signal, property or statistic) in a package can and should have the same numerical identifier. I seem to remember seeing, a long time ago, a statement to the effect that events and signals are similar in nature, ju= st the direction is different. According to that statement, which I can't f= ind now, it made sense that in the basic packages, different values were chos= en for all the entities in a package. Since this practice was not followed = in H.248.2, my question is, why the inconsistency? =20 Regards, =20 Raphael Tryster =20 =20 -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Thursday, June 16, 2005 11:16 PM To: Gunnar Hellstrom; Raphael Tryster; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos =20 Yes, there were a significant number of typographical errors in H.248.2 t= hat were resolved by IG items. All these IG items were incorporated into the revision of H.248.2. I would suggest having a look at the more recent document and seeing if the problems still exist. =20 Kevin =20 _____ =20 From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf = Of Gunnar Hellstrom Sent: Thursday, June 16, 2005 3:56 PM To: Raphael Tryster; megaco@ietf.org Subject: RE: [Megaco] even H.248.2 has typos Raphael, =20 I checked the November draft that was for Consent in SG16, and it had at least the conflict of ctyp/dtone, parameter dtt values DTMF and Sig resolved. A lot of other cleaning and adding good functionality for more automonous call type discrimination. =20 So, you should have the latest approved ITU version before you start detailed review. =20 Regards =20 Gunnar Hellstr=F6m ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- ------_=_NextPart_001_01C574E9.5F0EBAD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable order of descriptors in remote ringback scenario

Kevin and Gunnar,

 =

Now I have seen the new version and see that al= l the typos I found were already addressed there.  Sorry to have troubled you about obsolete things.  There remains only the question= of whether more than one entity (event, signal, property or statistic) in a package can and should have the same numerical identifier.  I seem to remember seeing, a lo= ng time ago, a statement to the effect that events and signals are similar in nat= ure, just the direction is different.  According to that statement, which I can’t find now, it made= sense that in the basic packages, different values were chosen for all the entities = in a package.  Since this practi= ce was not followed in H.248.2, my question is, why the inconsistency?

 =

Regards,

 =

Raphael Tryster<= /o:p>

 

 =

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortel.com]
Sent: Thursday, June 16, 2= 005 11:16 PM
To: Gunnar Hellstrom; Raph= ael Tryster; megaco@ietf.org
Subject: RE: [Megaco] even= H.248.2 has typos

 <= /o:p>

Yes, there were a significant number of typographical errors in H.248.2 that w= ere resolved by IG items.  All these IG items were incorporated into the revision of H.248.2.  I would suggest having a look at the more rece= nt document and seeing if the problems still exist.<= /o:p>

&nb= sp;<= /o:p>

Kevin<= /o:p>

 <= /o:p>

From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Gunnar Hellstrom
Sent: Thursday, June 16, 2= 005 3:56 PM
To: Raphael Tryster; megaco@ietf.org
Subject: RE: [Megaco] even= H.248.2 has typos

Raphael,<= /p>

I checked the November draft that w= as for Consent in SG16, and it had at least  the conflict <= /font>of ct= yp/dtone, parameter dtt values DTMF and Sig resolved.<= /p>

----------------------------------= ---------
Gunnar Hellstr=F6m
Omnitor AB
Renathv=E4gen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
Gunnar.Hellstrom@Omnitor.se
--------------------------------------------

------_=_NextPart_001_01C574E9.5F0EBAD0-- --===============1991575820== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1991575820==-- From megaco-bounces@ietf.org Sun Jun 19 22:27:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkC0D-00019G-SE; Sun, 19 Jun 2005 22:27:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkC0B-00019B-RR for megaco@megatron.ietf.org; Sun, 19 Jun 2005 22:27:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24439 for ; Sun, 19 Jun 2005 22:27:05 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkCNo-0003dv-I1 for megaco@ietf.org; Sun, 19 Jun 2005 22:51:33 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DFE5BBB1; Mon, 20 Jun 2005 04:26:39 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Jun 2005 04:26:39 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Jun 2005 04:26:38 +0200 Received: from [146.11.22.58] (EG2E500202DSEGL [146.11.22.58]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MLXTSKQ2; Mon, 20 Jun 2005 12:26:23 +1000 Message-ID: <42B6297A.2020002@ericsson.com> Date: Mon, 20 Jun 2005 12:27:06 +1000 X-Sybari-Trust: e665398d 3280b041 64c3be19 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Raphael Tryster Subject: Re: [Megaco] even H.248.2 has typos References: <9A64A99CD3F2BD4582BE4FB63FC1F381010D3131@MAILSERVER> In-Reply-To: <9A64A99CD3F2BD4582BE4FB63FC1F381010D3131@MAILSERVER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 20 Jun 2005 02:26:39.0101 (UTC) FILETIME=[7D0842D0:01C5753F] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: "'megaco@ietf.org'" , Gunnar Hellstrom X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello Raphael, I think you have to take into account that H.248.2 was the very first set= of=20 stand alone packages that were developed and they were being developed at= the=20 same time as we were finalising H.248.1. So there are things like the ord= ering=20 of identifiers that could have been done better. I think todays convention is that events, signals, properties or statisti= cs in a=20 packages DO have the same numerical identifiers (eg. starting at 0x0001).= They=20 are made unique by the fact that they always appear in different descript= ors.=20 However this is not a hard rule. The main thing is to be able to uniquely= =20 identify each signal,event,statistics,property. However an event can't ha= ve the=20 same ID as another event. A signal can't have the same ID as another sign= al etc... Regards, Christian Raphael Tryster wrote: > Kevin and Gunnar, > =20 > Now I have seen the new version and see that all the typos I found were > already addressed there. Sorry to have troubled you about obsolete > things. There remains only the question of whether more than one entit= y > (event, signal, property or statistic) in a package can and should have > the same numerical identifier. I seem to remember seeing, a long time > ago, a statement to the effect that events and signals are similar in > nature, just the direction is different. According to that statement, > which I can't find now, it made sense that in the basic packages, > different values were chosen for all the entities in a package. Since > this practice was not followed in H.248.2, my question is, why the > inconsistency? > =20 > Regards, > =20 > Raphael Tryster > =20 > =20 > -----Original Message----- > From: Kevin Boyle [mailto:kboyle@nortel.com] > Sent: Thursday, June 16, 2005 11:16 PM > To: Gunnar Hellstrom; Raphael Tryster; megaco@ietf.org > Subject: RE: [Megaco] even H.248.2 has typos > =20 > Yes, there were a significant number of typographical errors in H.248.2 > that were resolved by IG items. All these IG items were incorporated > into the revision of H.248.2. I would suggest having a look at the mor= e > recent document and seeing if the problems still exist. > =20 > Kevin > =20 > _____ =20 >=20 > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behal= f > Of Gunnar Hellstrom > Sent: Thursday, June 16, 2005 3:56 PM > To: Raphael Tryster; megaco@ietf.org > Subject: RE: [Megaco] even H.248.2 has typos > Raphael, > =20 > I checked the November draft that was for Consent in SG16, and it had a= t > least the conflict of ctyp/dtone, parameter dtt values DTMF and Sig > resolved. > A lot of other cleaning and adding good functionality for more > automonous call type discrimination. > =20 > So, you should have the latest approved ITU version before you start > detailed review. > =20 > Regards > =20 > Gunnar Hellstr=F6m > ------------------------------------------- > Gunnar Hellstr=F6m > Omnitor AB > Renathv=E4gen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=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 From megaco-bounces@ietf.org Mon Jun 20 05:09:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkII0-0004rf-DZ; Mon, 20 Jun 2005 05:09:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkIHz-0004rY-4v for megaco@megatron.ietf.org; Mon, 20 Jun 2005 05:09:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07298 for ; Mon, 20 Jun 2005 05:09:52 -0400 (EDT) Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkIfe-0003HV-9p for megaco@ietf.org; Mon, 20 Jun 2005 05:34:23 -0400 Received: from spark.hss.co.in (localhost [127.0.0.1]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j5K94hff003097 for ; Mon, 20 Jun 2005 14:35:00 +0530 (IST) Received: from webmail.hss.hns.com (webmail.hss.hns.com [10.203.158.17]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j5K93uGO002864; Mon, 20 Jun 2005 14:33:57 +0530 (IST) In-Reply-To: <7397E98E3B94C544BB0485F2283EF8BD10C880@enfimail1.datcon.co.uk> Subject: RE: [Megaco] Audit on Wildcarded Context and ROOT Termination issue- To: megaco@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "B Venkat S.R Swamy" Date: Mon, 20 Jun 2005 14:33:18 +0530 X-MIMETrack: Serialize by Router on WebMail/HSS(Release 6.5.1|January 21, 2004) at 06/20/2005 02:33:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 3.1 (+++) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: Jon Rowland 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 The problem with the option 1 below is that for large gateways there is lot of redundant information mainly the "{AV=ROOT}" getting repeated unnecessarly for each action, therefore the suggested solution is quite optimized, repeated here with short token. MG1 to MGC: !/1 [124.124.124.222]:55555 p=9999{ C=*{AV = ROOT {1, 2} } Also with the growing interest in H248 and more and more vendors asking for compliance with the only available test suite defined by ETSI, there is need to address the problems that have been reported in the ETSI test suite(ETSI TS 101 889-2) in megaco mailinglist. Are there any plans to define a similiar test suite in ITU-T . B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.flextronicssoftware.com "Jon Rowland" To B Venkat S.R Swamy/HSS@HSS 06/16/2005 03:24 cc PM Subject RE: [Megaco] Audit on Wildcarded Context and ROOT Termination issue- Option 1 is correct. Options 2 and 3 are responses to a wildcard termination audit of wildcarded context IDs as you correctly point out. This suggests that the ETSI spec is erroneous. Your suggested compressed scheme doesn't really add very much over the short-text encoding of the transaction response: !/1 [124.124.124.124]:55555 P=9999{ C=1{AV=ROOT}, C=2{AV=ROOT} } Hence, I'm not sure it is justifiable given it is not back-compatible. The general problem with this type of command, when used in conjunction with large gateways, is that the response size can get quite large, which can be a problem when using TCP or UDP transports. This has been addressed in V3 by the introduction of a scheme for segmenting responses. Jon. -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of B Venkat S.R Swamy Sent: 16 June 2005 04:57 To: megaco@ietf.org Subject: [Megaco] Audit on Wildcarded Context and ROOT Termination issue- Hi, H.248.1 V1 and V2 section 7.2.5 say Auditvalue on Termination ID Root with context ID All should return list of all ContextIds (the ContextID list should be returned by using multiple action replies, each containing a ContextID from the list). Now the question is: How will the reply for the following scenario look like? Audit on termination ROOT with context * and empty audit descriptor MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 { Context = * { AuditValue = ROOT { Audit {}} } } There are currently three options: Option 1: Audit on ROOT termination returning only context information: MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = 1 {Auditvalue = ROOT}, Context = 2 {Auditvalue = ROOT} } Option 2: As per ETSI TS 101 889-2 section 5.1.9.1 "TP/MG/AV/BV-05" MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = 1 {Auditvalue = A4444 , Auditvalue = A4445}, Context = 2 {Auditvalue = A5444 , Auditvalue = A5445} } Option 3: condensed form of option 2 above : MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = 1 {Auditvalue = Context {A4444 , A4445} }, Context = 2 {Auditvalue = Context {A5444 , A5445} }, } However the option2 and option3 can be obtained through- Audit on Wildcarded context and Wildcarded termination with Empty Audit Descriptor. MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 { Context = * { AuditValue = * { Audit {}} } } Now considering the fact that the basic objective of Audit on ROOT termination and Context * is to get the list of context IDs only without any termination information, an optimized solution is suggested below. This however requires changes in the protocol grammar. MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = * {Auditvalue = ROOT {1, 2} } Request mailing list comments on the above issue, on either accepting the above solution or discontinuing the option of sending Audit on ROOT Termination and Context *. Regards, B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.flextronicssoftware.com *********************** FSS-Restricted *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco *********************** FSS-Restricted *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Jun 20 13:18:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPuO-00054D-6q; Mon, 20 Jun 2005 13:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPuK-00052v-Vm for megaco@megatron.ietf.org; Mon, 20 Jun 2005 13:18:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20061 for ; Mon, 20 Jun 2005 13:17:57 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkQI3-0007TI-9n for megaco@ietf.org; Mon, 20 Jun 2005 13:42:33 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5KHHbs18845 for ; Mon, 20 Jun 2005 13:17:38 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Jun 2005 13:17:22 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40292B211@zrtphxm2> From: "Kevin Boyle" To: Christian Groves , Raphael Tryster Subject: RE: [Megaco] even H.248.2 has typos Date: Mon, 20 Jun 2005 13:17:14 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: "'megaco@ietf.org'" , Gunnar Hellstrom 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 is stated in the base spec (clause 6.2.3, third paragraph) that each of the package item types (properties, events, signals, statistics) exists in its own namespace, so the binary IDs (and the text IDs) are allowed to be reused across types. Within a signal type, however, the IDs must be unique within the package and its extensions. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Christian Groves Sent: Sunday, June 19, 2005 10:27 PM To: Raphael Tryster Cc: 'megaco@ietf.org'; Gunnar Hellstrom Subject: Re: [Megaco] even H.248.2 has typos Hello Raphael, I think you have to take into account that H.248.2 was the very first set of stand alone packages that were developed and they were being developed at the same time as we were finalising H.248.1. So there are things like the ordering of identifiers that could have been done better. I think todays convention is that events, signals, properties or statistics in a packages DO have the same numerical identifiers (eg. starting at 0x0001). They are made unique by the fact that they always appear in different descriptors. However this is not a hard rule. The main thing is to be able to uniquely identify each signal,event,statistics,property. However an event can't have the same ID as another event. A signal can't have the same ID as another signal etc... Regards, Christian Raphael Tryster wrote: > Kevin and Gunnar, > > Now I have seen the new version and see that all the typos I found > were already addressed there. Sorry to have troubled you about > obsolete things. There remains only the question of whether more than > one entity (event, signal, property or statistic) in a package can and > should have the same numerical identifier. I seem to remember seeing, > a long time ago, a statement to the effect that events and signals are > similar in nature, just the direction is different. According to that > statement, which I can't find now, it made sense that in the basic > packages, different values were chosen for all the entities in a > package. Since this practice was not followed in H.248.2, my question > is, why the inconsistency? > > Regards, > > Raphael Tryster > > > -----Original Message----- > From: Kevin Boyle [mailto:kboyle@nortel.com] > Sent: Thursday, June 16, 2005 11:16 PM > To: Gunnar Hellstrom; Raphael Tryster; megaco@ietf.org > Subject: RE: [Megaco] even H.248.2 has typos > > Yes, there were a significant number of typographical errors in > H.248.2 that were resolved by IG items. All these IG items were > incorporated into the revision of H.248.2. I would suggest having a > look at the more recent document and seeing if the problems still exist. > > Kevin > > _____ > > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On > Behalf Of Gunnar Hellstrom > Sent: Thursday, June 16, 2005 3:56 PM > To: Raphael Tryster; megaco@ietf.org > Subject: RE: [Megaco] even H.248.2 has typos Raphael, > > I checked the November draft that was for Consent in SG16, and it had > at least the conflict of ctyp/dtone, parameter dtt values DTMF and > Sig resolved. > A lot of other cleaning and adding good functionality for more > automonous call type discrimination. > > So, you should have the latest approved ITU version before you start > detailed review. > > Regards > > Gunnar Hellström > ------------------------------------------- > Gunnar Hellström > Omnitor AB > Renathvägen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Megaco mailing 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 Jun 20 14:30:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkR25-0005dM-Qn; Mon, 20 Jun 2005 14:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkR24-0005ck-QQ for megaco@megatron.ietf.org; Mon, 20 Jun 2005 14:30:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26454 for ; Mon, 20 Jun 2005 14:30:03 -0400 (EDT) Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkRPo-0000yt-Nm for Megaco@ietf.org; Mon, 20 Jun 2005 14:54:38 -0400 Received: from SChiduruppa1 [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-8.20) id AAF4045C; Mon, 20 Jun 2005 14:29:08 -0400 From: "Sreenivas" To: Date: Mon, 20 Jun 2005 14:31:47 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcV1xlDbtE00OBjsR2+YgksGkJpaVw== Message-Id: <200506201429343.SM01584@SChiduruppa1> X-Spam-Score: 3.1 (+++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Subject: [Megaco] Can MGC send RESTART after FORCED 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="===============0452456720==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0452456720== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C2_01C575A4.C9E8A300" This is a multi-part message in MIME format. ------=_NextPart_000_00C2_01C575A4.C9E8A300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, After an MGC sends a FORCED method for ROOT termination to an MG indicating that it is being taken out of service, would it be right for the MGC to subsequently send a RESTART to the MG. My understanding it that after that after the FORCED has been received by the MG, the association between the MGC and MG is over, at which point a new association should be initiated by the MG through re-registration starting with the Primary MGC and then the Secondary MGC and so on. Thx, Sreenivas ------=_NextPart_000_00C2_01C575A4.C9E8A300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

    After an MGC sends a FORCED method = for ROOT termination to an MG indicating that it is being taken out of = service, would it be right for the MGC to subsequently send a RESTART to the MG. = My understanding it that after that after the FORCED has been received by = the MG, the association between the MGC and MG is over, at which point a new association should be initiated by the MG through re-registration = starting with the Primary MGC and then the Secondary MGC and so = on.

 

Thx,

Sreenivas

------=_NextPart_000_00C2_01C575A4.C9E8A300-- --===============0452456720== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0452456720==-- From megaco-bounces@ietf.org Mon Jun 20 17:14:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkTao-00056y-L2; Mon, 20 Jun 2005 17:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkTan-00056q-Ad for megaco@megatron.ietf.org; Mon, 20 Jun 2005 17:14:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10973 for ; Mon, 20 Jun 2005 17:14:03 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkTya-0005oW-4Q for megaco@ietf.org; Mon, 20 Jun 2005 17:38:40 -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 j5KLDjh22688 for ; Mon, 20 Jun 2005 17:13:45 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Jun 2005 17:13:45 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4029AD916@zrtphxm2> From: "Kevin Boyle" To: "B Venkat S.R Swamy" , megaco@ietf.org Subject: RE: [Megaco] Audit on Wildcarded Context and ROOT Termination iss ue- Date: Mon, 20 Jun 2005 17:13:22 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.2 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: Jon Rowland 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 There has already been a proposal for a "context list" construct to return a shorter message for those commands that are just interested in getting a list of contexts. Similarly, there is a construct to allow the return of a list of TermIDs in a command or response. These are being worked into V3. The construct proposed does not keep with the way the existing constructs are built. That list of "numbers" could be anything, and only by convention would one know that they are supposed to be some kind of list of ContextIDs. This level is where descriptors are placed, but this isn't a descriptor -- it's just an arbitrary list. I believe the construct being pursued by SG16 for V3 is much better aligned with the look and feel of H.248 message construction. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of B Venkat S.R Swamy Sent: Monday, June 20, 2005 5:03 AM To: megaco@ietf.org Cc: Jon Rowland Subject: RE: [Megaco] Audit on Wildcarded Context and ROOT Termination issue- Hi The problem with the option 1 below is that for large gateways there is lot of redundant information mainly the "{AV=ROOT}" getting repeated unnecessarly for each action, therefore the suggested solution is quite optimized, repeated here with short token. MG1 to MGC: !/1 [124.124.124.222]:55555 p=9999{ C=*{AV = ROOT {1, 2} } Also with the growing interest in H248 and more and more vendors asking for compliance with the only available test suite defined by ETSI, there is need to address the problems that have been reported in the ETSI test suite(ETSI TS 101 889-2) in megaco mailinglist. Are there any plans to define a similiar test suite in ITU-T . B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.flextronicssoftware.com "Jon Rowland" To B Venkat S.R Swamy/HSS@HSS 06/16/2005 03:24 cc PM Subject RE: [Megaco] Audit on Wildcarded Context and ROOT Termination issue- Option 1 is correct. Options 2 and 3 are responses to a wildcard termination audit of wildcarded context IDs as you correctly point out. This suggests that the ETSI spec is erroneous. Your suggested compressed scheme doesn't really add very much over the short-text encoding of the transaction response: !/1 [124.124.124.124]:55555 P=9999{ C=1{AV=ROOT}, C=2{AV=ROOT} } Hence, I'm not sure it is justifiable given it is not back-compatible. The general problem with this type of command, when used in conjunction with large gateways, is that the response size can get quite large, which can be a problem when using TCP or UDP transports. This has been addressed in V3 by the introduction of a scheme for segmenting responses. Jon. -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of B Venkat S.R Swamy Sent: 16 June 2005 04:57 To: megaco@ietf.org Subject: [Megaco] Audit on Wildcarded Context and ROOT Termination issue- Hi, H.248.1 V1 and V2 section 7.2.5 say Auditvalue on Termination ID Root with context ID All should return list of all ContextIds (the ContextID list should be returned by using multiple action replies, each containing a ContextID from the list). Now the question is: How will the reply for the following scenario look like? Audit on termination ROOT with context * and empty audit descriptor MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 { Context = * { AuditValue = ROOT { Audit {}} } } There are currently three options: Option 1: Audit on ROOT termination returning only context information: MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = 1 {Auditvalue = ROOT}, Context = 2 {Auditvalue = ROOT} } Option 2: As per ETSI TS 101 889-2 section 5.1.9.1 "TP/MG/AV/BV-05" MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = 1 {Auditvalue = A4444 , Auditvalue = A4445}, Context = 2 {Auditvalue = A5444 , Auditvalue = A5445} } Option 3: condensed form of option 2 above : MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = 1 {Auditvalue = Context {A4444 , A4445} }, Context = 2 {Auditvalue = Context {A5444 , A5445} }, } However the option2 and option3 can be obtained through- Audit on Wildcarded context and Wildcarded termination with Empty Audit Descriptor. MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 { Context = * { AuditValue = * { Audit {}} } } Now considering the fact that the basic objective of Audit on ROOT termination and Context * is to get the list of context IDs only without any termination information, an optimized solution is suggested below. This however requires changes in the protocol grammar. MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = * {Auditvalue = ROOT {1, 2} } Request mailing list comments on the above issue, on either accepting the above solution or discontinuing the option of sending Audit on ROOT Termination and Context *. Regards, B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.flextronicssoftware.com *********************** FSS-Restricted *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco *********************** FSS-Restricted *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 21 00:41:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkaa4-0002LR-Rl; Tue, 21 Jun 2005 00:41:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkaa2-0002LH-9w for megaco@megatron.ietf.org; Tue, 21 Jun 2005 00:41:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15801 for ; Tue, 21 Jun 2005 00:41:42 -0400 (EDT) Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkaxq-0000Bb-Iu for megaco@ietf.org; Tue, 21 Jun 2005 01:06:25 -0400 Received: from spark.hss.co.in (localhost [127.0.0.1]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j5L4a9fd010763 for ; Tue, 21 Jun 2005 10:06:40 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j5L4YmGO010444 for ; Tue, 21 Jun 2005 10:05:34 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id j5L4eKc07045 for ; Tue, 21 Jun 2005 10:10:20 +0530 (IST) To: megaco@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Anjana Arora Date: Tue, 21 Jun 2005 10:06:28 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 21/06/2005 10:09:17 AM, Serialize complete at 21/06/2005 10:09:18 AM, Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 21/06/2005 10:09:18 AM X-Spam-Score: 0.6 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Megaco] DigitMap Completion Event 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="===============0968621170==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multipart message in MIME format. --===============0968621170== Content-Type: multipart/alternative; boundary="=_alternative 001A06B665257027_=" This is a multipart message in MIME format. --=_alternative 001A06B665257027_= Content-Type: text/plain; charset="US-ASCII" If MGC sends a digitmap as { 8xxxxxxx | 8x. } to MG for Local Number. In this scenario, when a MG shall report DigitMap Completion Event: (i) The moment user dials 8xxxxxxx or (ii) MG shall apply a short timer(S) and shall wait for an extra digit after 8xxxxxxx as per dialplan "8x." If user dials an extra digit within this time, then what Digit String shall an MG send in dd/ce event : 8xxxxxxx or 8xxxxxxxx? Regards, Anjana *********************** FSS-Unclassified *********************** *********************** FSS-Unclassified *********************** "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." --=_alternative 001A06B665257027_= Content-Type: text/html; charset="US-ASCII"
If MGC sends a digitmap as { 8xxxxxxx | 8x. } to MG for Local Number.

In this scenario, when a MG shall report DigitMap Completion Event:
(i) The moment user dials 8xxxxxxx   or
(ii) MG shall apply a short timer(S) and shall wait for an extra digit after 8xxxxxxx as per dialplan "8x."

If user dials an extra digit within this time, then what Digit String shall an MG send in dd/ce event : 8xxxxxxx or 8xxxxxxxx?

Regards,
Anjana

***********************  FSS-Unclassified   ***********************

***********************  FSS-Unclassified   *********************** 
"DISCLAIMER: This message is proprietary to Flextronics Software 
Systems Limited (FSS) and is intended solely for the use of the  
individual to whom it is addressed. It may contain  privileged or 
confidential information and should not be circulated or used for 
any purpose other than for what it is intended. If you have received 
this message in  error, please notify the originator immediately. 
If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing
the contents of this message.  FSS  accepts no  responsibility  for
loss or damage arising from the use of  the information transmitted
by this email including damage from virus."
--=_alternative 001A06B665257027_=-- --===============0968621170== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0968621170==-- From megaco-bounces@ietf.org Tue Jun 21 02:22:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkc9b-0001M7-Fz; Tue, 21 Jun 2005 02:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkc9a-0001Jn-0h for megaco@megatron.ietf.org; Tue, 21 Jun 2005 02:22:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14462 for ; Tue, 21 Jun 2005 02:22:32 -0400 (EDT) Received: from [62.90.58.229] (helo=tparelay.telradnetworks.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkcXG-0002ZA-QQ for megaco@ietf.org; Tue, 21 Jun 2005 02:47:13 -0400 Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j5L6IAas014311 for ; Tue, 21 Jun 2005 09:18:11 +0300 (IDT) Received: from tpa-mail1.Telrad.co.il ([141.226.76.57]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j5L6IAkm014306 for ; Tue, 21 Jun 2005 09:18:10 +0300 (IDT) Received: by tpa-mail1.telrad.co.il with Internet Mail Service (5.5.2657.72) id ; Tue, 21 Jun 2005 09:23:21 +0300 Message-ID: From: Tamar Nemet To: "'megaco@ietf.org'" Date: Tue, 21 Jun 2005 09:23:19 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Megaco] Megaco commands with Wildcard 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="===============1923326478==" 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. --===============1923326478== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57628.FCA67E0A" 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_01C57628.FCA67E0A Content-Type: text/plain; charset="windows-1255" Hello, If I get Modify command with wildcard (asking off hook detection), and I have 500 termination IDs that fits this wildcard, how should I send the reply ? Do I have to send a reply for each termination ID ? If some of the termination IDs are already off hook, do I have to send error for those part of termination IDs and positive ack for the others ? Best Regards, Tamar ------_=_NextPart_001_01C57628.FCA67E0A Content-Type: text/html; charset="windows-1255"
Hello,
 
If I get Modify command with wildcard (asking off hook detection), and I have 500 termination IDs that fits this wildcard,
how should I send the reply ? Do I have to send a reply for each termination ID ? If some of the termination IDs are already off hook,
do I have to send error for those part of termination IDs and positive ack for the others ?
 
Best Regards,
Tamar
------_=_NextPart_001_01C57628.FCA67E0A-- --===============1923326478== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1923326478==-- From megaco-bounces@ietf.org Tue Jun 21 02:36:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkcMt-0003To-Kt; Tue, 21 Jun 2005 02:36:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkcMp-0003Tc-9C for megaco@megatron.ietf.org; Tue, 21 Jun 2005 02:36:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15998 for ; Tue, 21 Jun 2005 02:36:13 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkckg-0002tX-J8 for megaco@ietf.org; Tue, 21 Jun 2005 03:00:55 -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/ICT TSC MAIL 2005) with ESMTP id j5L6NZVa025831; Tue, 21 Jun 2005 08:23:35 +0200 In-Reply-To: <14CBB76EE1B7824481814205E429C869533B2E@srvchber1210.ch.keymile.net> To: itu-sg16@external.cisco.com, "Binz, Walter" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Tue, 21 Jun 2005 08:23:33 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF141 | May 13, 2005) at 06/21/2005 08:23:34 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.3 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Content-Transfer-Encoding: quoted-printable Cc: megaco@ietf.org Subject: [Megaco] H.248.1 V3 Week 5 - RE: Statistics:nt/os, nt/or; 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 For information only: I've mentioned in our "Week 5" comments that ALCATEL will submitt a contribution to next SG16 on "H.248.1 Annex E.11 Network Package - Recommendations for Statistics Usage". An initial proposal (file Alcatelx1 T05-SG16-050726-D H.248.1v3 nt Package_Ed01.doc , Alcatelx1 T05-SG16-050726-D H.248.1v3 nt Package_Ed01.pdf) is ready and uploaded in /av-arch/avc-site/Incoming. Prof. Okuba, could you please move the files in directory http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/ Thoughts, comments? Regards Albrecht PS Walter, I did cover your mentioned relation in clause "E.11.5.3.2.2.1".= But I didn't consider the correlation of statistics from different Terminations of the same Context so far in the proposal. Perhaps I'll a= dd a subsection on that item ("which is questionable in general for statisti= cs without any time information, like start/end time, or time stamps per p= robe etc; ... and I'm not aware of the existence of such kind of H.248 statistics so far ..") = =20 "Binz, Walter" = =20 =20 mile.com> cc: = =20 Sent by: Subject: RE: Statistics:= nt/os, nt/or; Re: [Megaco] Call Flow Example in =20 megaco-bounces@i H.248.1Corrigendum1 (03/= 2004) =20 etf.org = =20 = =20 = =20 23.05.2005 15:37 = =20 = =20 Albrecht et al., my understanding is that nt/or & nt/os for a 64kbps physical terminatio= n (such as in the H.248.1 call flow example) should be about 8 times nt/d= ur (8 PCM samples per ms), independent of the chosen RTP/AVP (I assume tha= t codec and silence suppression functions are part of the ephemeral termination). Therefore in the H.248.1 Call Flow Example below, nt/or for the ephemer= al termination should be about 10 times lower than nt/os for the physical termination (and NOT the same), as a G.723.1 codec was used for the cal= l. I would appreciate if some guidance text can be added to the nt package= . Regards, Walter >-----Original Message----- >From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Beha= lf Of >Albrecht.Schwarz@alcatel.de >Sent: Friday, May 20, 2005 9:12 AM >To: megaco@ietf.org >Subject: Statistics:nt/os, nt/or; Re: [Megaco] Call Flow Example in >H.248.1Corrigendum1 (03/2004) > > >Hello Alberto et al., > >I think the question was not the *unit* of the time-based statistic nt= /dur >versus the unit-less statistics nt/or & nt/os. >Looking from a high-level perspective on the traffic volume related >statistics nt/or & nt/os on circuit- and packet-side on the H.248 Cont= ext >(MG) in this example, it looks like that the conservation law is inval= id >("traffic volume increase from C2P direction, whereas the volume is >constant in the opposite direction P2C":-) >Of course, whether the conservation law is applicable at all depends o= n >codec type, silence suppression mode, RTP FEC mode, and other >configurations. > >The crucial point is rather, which protocol layers have to be consider= ed >for these volume-based statistics? This basic question becomes more op= en >due to the "generic scope" of these statistics: they are defined for A= LL >type of H.248 Terminations (physical T.: ALN, TDM; ephemeral T.: RTP, = UDP, >IP, AAL2, AAL1, ATM, etc etc). > >This issue was frequently discussed in the past, also in last SG16 meeting. > >Just the note therefore that I'm currently working on a contribution o= n >that subject for next SG16. >The intent aren't any technical changes to the nt Package, I rather do= see >a need to provide some guidance on statistics usage. Such recommendati= ons >may be covered in the procedural section (clause =A7 E.11.5 >"Procedures"/H.248.1). > >regards >Albrecht > > > > > > Christian Groves > > icsson.com> cc: >megaco@ietf..org > Sent by: Subject: Re: [Megac= o] >Call Flow Example in H.248.1 Corrigendum1 (03/2004) > megaco-bounces@ietf. > org > > > 12.05.2005 05:47 > > > > > >Hello Puglisi, > >I'm not sure if I understand your question correctly. nt/dur shouldn't= have >the >same value as nt/os, nt/or because Duration is in Milliseconds and Oct= ets >Sent >and Received are in numbers of Octets. > >Regards, Christian > >Puglisi Alberto wrote: > >> 22) The MGC now sends both MGs a Subtract to take down the call. Onl= y >> the subtracts to MG2 are shown here. Each termination has its own se= t of >> statistics that it gathers. An MGC may not need to request both to b= e >> returned. A5555 is a physical termination, and A5556 is an RTP >> termination. >> >>>From MGC to MG2: >> >> MEGACO/1 2 [123.123.123.4]:55555 >> Transaction =3D 50009 { >> Context =3D 5000 { >> Subtract =3D A5555 {Audit{Statistics}}, >> Subtract =3D A5556 {Audit{Statistics}} >> } >> } >> >>>From MG2 to MGC: >> >> MEGACO/1 2 [125.125.125.111]:55555 >> Reply =3D 50009 { >> Context =3D 5000 { >> Subtract =3D A5555 { >> Statistics { >> nt/os=3D45123, ; Octets Sent >> nt/or=3D45123, ; Octets Received >> nt/dur=3D40000 ; in milliseconds >> } >> }, >> Subtract =3D A5556 { >> Statistics { >> rtp/ps=3D1245, ; packets sent >> nt/os=3D62345, ; octets sent >> rtp/pr=3D780, ; packets received >> nt/or=3D45123, ; octets received >> rtp/pl=3D10, ; % packets lost >> rtp/jit=3D27, >> rtp/delay=3D48, ; average latency >> nt/dur=3D38000 ; in millisec >> } >> } >> } >> } >> >> I understand that nt/os, nt/or, and nt/dur should have the same val= ues, >> am I correct ? >> >> >> --------------------------------------------------------------------= ---- >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Jun 22 02:13:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkyR8-000187-Rd; Wed, 22 Jun 2005 02:10:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkyR3-000176-RL for megaco@megatron.ietf.org; Wed, 22 Jun 2005 02:10:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05559 for ; Wed, 22 Jun 2005 02:10:00 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkyp2-0003xG-Vg for Megaco@ietf.org; Wed, 22 Jun 2005 02:34:54 -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/ICT TSC MAIL 2005) with ESMTP id j5M69TVa025328; Wed, 22 Jun 2005 08:09:29 +0200 In-Reply-To: <200506201429343.SM01584@SChiduruppa1> Subject: Re: [Megaco] Can MGC send RESTART after FORCED To: "Sreenivas" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Wed, 22 Jun 2005 08:09:27 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF141 | May 13, 2005) at 06/22/2005 08:09:29 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.3 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Hello Sreenivas, following logic applies in my understanding: 1) MGC->MG: SC {Forced, Root, 905} =3D> =A7 F.3.10.1/H.248.1 =3D> triggers =A7 F.4.1.1/H.248.1 for MGC 2) =A7 F.4.1.1, (2), MGC: "When sent by the MGC, the MG shall take itself Out-of-Service, and terminate the control association after sending the command reply. = Note that an MGC cannot bring an MG back into service, even though it may= request it to go Out-of-Service. The MG initiates registration to t= he MGC to establish a new control association and indicate service restoration, just as it would for any other registration. ..." I think that Annex F is here pretty clear that a subsequent Restart of = the MGC is not possible. The next step is up to the MG as indicated in =A7 F.4.1.1. Best regards, Albrecht ALCATEL = =20 "Sreenivas" = =20 =20 packet.com> cc: = =20 Sent by: Subject: [Megaco] Can M= GC send RESTART after FORCED =20 megaco-bounces@ie = =20 tf.org = =20 = =20 = =20 20.06.2005 20:31 = =20 = =20 Hi, After an MGC sends a FORCED method for ROOT termination to an MG indicating that it is being taken out of service, would it be right for= the MGC to subsequently send a RESTART to the MG. My understanding it that after that after the FORCED has been received by the MG, the associatio= n between the MGC and MG is over, at which point a new association should= be initiated by the MG through re-registration starting with the Primary M= GC and then the Secondary MGC and so on. Thx, Sreenivas_______________________________________________ Megaco mailing 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 Jun 22 07:20:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl3Hl-0006Fc-2Z; Wed, 22 Jun 2005 07:20:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl3Hk-0006EL-20 for megaco@megatron.ietf.org; Wed, 22 Jun 2005 07:20:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26144 for ; Wed, 22 Jun 2005 07:20:46 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl3fo-0003VS-RV for megaco@ietf.org; Wed, 22 Jun 2005 07:45:43 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9A083D45; Wed, 22 Jun 2005 13:20:08 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 13:20:08 +0200 Received: from ehrzgmw300.eemea.ericsson.se ([159.107.224.60]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 13:20:07 +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 Subject: RE: [Megaco] andisp/dwa and Hook State Change Race Date: Wed, 22 Jun 2005 11:31:01 +0200 Message-ID: Thread-Topic: [Megaco] andisp/dwa and Hook State Change Race Thread-Index: AcVyhn3FHgFjbsZNRsemyLeRMDpCKwEeb0ag From: "Jan Lindquist (AL/EAB)" To: "Kevin Boyle" , "Christian Groves (BR/EPA)" , "Stephen Mell" X-OriginalArrivalTime: 22 Jun 2005 11:20:07.0755 (UTC) FILETIME=[5880C1B0:01C5771C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 Hello, Even if the situation of a cross over is rare there are requirements in legacy systems that dictate which end wins the race condition. Some countries require that the originating end wins the race condition so the off-hook will give you a dialtone and not somebody calling you. Other countries require the terminating end to win so if you lift up the off-hook the terminating call should come through so no dialtone, etc. There is a liaison from TISPAN requesting that dwa signal indicates clearly the expected state of the line in order to apply the ringing or call waiting. If this change is not provided then the MG has to be provisioned differently in different countries. This is what we want to avoid. Regards, JanL -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Kevin Boyle Sent: den 16 juni 2005 17:15 To: Christian Groves (BR/EPA); Stephen Mell Cc: megaco@ietf.org Subject: RE: [Megaco] andisp/dwa and Hook State Change Race This race condition, in practice, occurs extremely rarely and does not seem to cause confusion to the end-user. In more than 5 years of active deployment across literally millions of lines of service there has never been a single compliant. There are two possible scenarios: 1. User picks up and listens for dialtone, intending to place a call but discovering that there is already a connection. They hear Call Wait tone and potentially get the number delivered (if the Signals descriptor isn't canceled fast enough). 2. User hangs up the phone from an existing call, and instantly gets ringing and number delivery. Scenario one is a weird case anyway. People don't generally enjoy picking up the phone and finding a connection present when they are expecting dialtone. This does happen on rare occasions, and the inclusion of a call wait tone at that moment does not seem to create any additional discomfort or problem over the already existing "twilight zone" connection. (The creepiest of these is when the person on the other end of the connection happens to be the person you were intending to call!) Scenario 2 is OK, because the call was going to present anyway -- this actually saves a NACK from the MG and a potential call loss. So, I think the issue here is being made out to be much bigger than it really is. In fact, given that scenario 2 saves a NACK, there is some beneficial economy to the methodology that exists. Kevin=20 -----Original Message----- From: Christian Groves [mailto:christian.groves@ericsson.com]=20 Sent: Thursday, June 16, 2005 3:32 AM To: Stephen Mell Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: Re: [Megaco] andisp/dwa and Hook State Change Race Hello Stephen, I believe this issue as been discussed at a recent Tispan meeting. I expect to see a liaison come into the July SG16 meeting on enhancements to H.248.23. So this will be discussed then. Regards, Christian Stephen Mell wrote: > Hello Kevin, >=20 > We have experienced a situation which highlights a slight drawback > with the current definition of andisp/dwa in H248.23, and thought it=20 > might be worth pointing it out now, should an "xandisp" ever materialise. >=20 > With most signals that my MG needs to apply, the nature of the signal > implies whether or not it is sensible or not to apply that signal in=20 > the face of a given hook state. This is good as it helps greatly to=20 > mitigate the effect of network crossover situations. For example I can > choose to fail ringing if the line is now off-hook and send the=20 > required Notify to indicate failure if g/sc is armed. >=20 > andisp/dwa is constructed in such an economical way that that the on > and off hook signalling messages are syntactically the same, but are=20 > interpreted differently at the Gateway, dependant on the actual Hook=20 > state - However the MGC's anticipated hook state when it requested the > signal is not conveyed to the Gateway. >=20 > When there is a crossover between an OFF/ON-HOOK notification from the > MG and a anddisp/dwa Signal from the MGC, the MG may end up=20 > inadvertantly applying inappropraite signalling to the line. Where=20 > there is packet loss this Crossover window is naturally opened further. >=20 > Another optional signal parameter, identifying the MGC's anticipated > hook state, which the MG is required to match before attempting to=20 > apply the signal, would help to shut this window. >=20 >=20 > Regards, >=20 > Steve >=20 >=20 > ---------------------------------------------------------------------- > -- >=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 Wed Jun 22 11:04:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl6m2-00058z-0i; Wed, 22 Jun 2005 11:04:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl6lz-00058N-N8 for megaco@megatron.ietf.org; Wed, 22 Jun 2005 11:04:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20819 for ; Wed, 22 Jun 2005 11:04:10 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl7A4-00038s-Mn for megaco@ietf.org; Wed, 22 Jun 2005 11:29:11 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5MF3p309667 for ; Wed, 22 Jun 2005 11:03:51 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jun 2005 11:03:13 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402A1282C@zrtphxm2> From: "Kevin Boyle" To: "Jan Lindquist (AL/EAB)" , "Christian Groves (BR/EPA)" , Stephen Mell Subject: RE: [Megaco] andisp/dwa and Hook State Change Race Date: Wed, 22 Jun 2005 11:03:04 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 Why wouldn't we want the MG to be provisioned differently in different countries? It has to be already for the toneset... It seems to me that the problem you describe wouldn't exist anyway. The call will not be connected completely until the terminator's termination is in the context with the ephemeral for the bearer and is set to SendRecv. This would either happen as an Add Command to add the terminator to the context, or as a Modify Command to set the Mode to SendRecv for the terminator if the term is already in the context. Either way, cut through of the voice path will require MGC intervention. So there is time for the MGC to decide whether to connect the call or apply dialtone. Again, I believe the overwhelming focus on this race condition is making a mountain out of a molehill. Kevin -----Original Message----- From: Jan Lindquist (AL/EAB) [mailto:jan.lindquist@ericsson.com] Sent: Wednesday, June 22, 2005 5:31 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Christian Groves (BR/EPA); Stephen Mell Cc: megaco@ietf.org Subject: RE: [Megaco] andisp/dwa and Hook State Change Race Hello, Even if the situation of a cross over is rare there are requirements in legacy systems that dictate which end wins the race condition. Some countries require that the originating end wins the race condition so the off-hook will give you a dialtone and not somebody calling you. Other countries require the terminating end to win so if you lift up the off-hook the terminating call should come through so no dialtone, etc. There is a liaison from TISPAN requesting that dwa signal indicates clearly the expected state of the line in order to apply the ringing or call waiting. If this change is not provided then the MG has to be provisioned differently in different countries. This is what we want to avoid. Regards, JanL -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Kevin Boyle Sent: den 16 juni 2005 17:15 To: Christian Groves (BR/EPA); Stephen Mell Cc: megaco@ietf.org Subject: RE: [Megaco] andisp/dwa and Hook State Change Race This race condition, in practice, occurs extremely rarely and does not seem to cause confusion to the end-user. In more than 5 years of active deployment across literally millions of lines of service there has never been a single compliant. There are two possible scenarios: 1. User picks up and listens for dialtone, intending to place a call but discovering that there is already a connection. They hear Call Wait tone and potentially get the number delivered (if the Signals descriptor isn't canceled fast enough). 2. User hangs up the phone from an existing call, and instantly gets ringing and number delivery. Scenario one is a weird case anyway. People don't generally enjoy picking up the phone and finding a connection present when they are expecting dialtone. This does happen on rare occasions, and the inclusion of a call wait tone at that moment does not seem to create any additional discomfort or problem over the already existing "twilight zone" connection. (The creepiest of these is when the person on the other end of the connection happens to be the person you were intending to call!) Scenario 2 is OK, because the call was going to present anyway -- this actually saves a NACK from the MG and a potential call loss. So, I think the issue here is being made out to be much bigger than it really is. In fact, given that scenario 2 saves a NACK, there is some beneficial economy to the methodology that exists. Kevin -----Original Message----- From: Christian Groves [mailto:christian.groves@ericsson.com] Sent: Thursday, June 16, 2005 3:32 AM To: Stephen Mell Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: Re: [Megaco] andisp/dwa and Hook State Change Race Hello Stephen, I believe this issue as been discussed at a recent Tispan meeting. I expect to see a liaison come into the July SG16 meeting on enhancements to H.248.23. So this will be discussed then. Regards, Christian Stephen Mell wrote: > Hello Kevin, > > We have experienced a situation which highlights a slight drawback > with the current definition of andisp/dwa in H248.23, and thought it > might be worth pointing it out now, should an "xandisp" ever materialise. > > With most signals that my MG needs to apply, the nature of the signal > implies whether or not it is sensible or not to apply that signal in > the face of a given hook state. This is good as it helps greatly to > mitigate the effect of network crossover situations. For example I can > choose to fail ringing if the line is now off-hook and send the > required Notify to indicate failure if g/sc is armed. > > andisp/dwa is constructed in such an economical way that that the on > and off hook signalling messages are syntactically the same, but are > interpreted differently at the Gateway, dependant on the actual Hook > state - However the MGC's anticipated hook state when it requested the > signal is not conveyed to the Gateway. > > When there is a crossover between an OFF/ON-HOOK notification from the > MG and a anddisp/dwa Signal from the MGC, the MG may end up > inadvertantly applying inappropraite signalling to the line. Where > there is packet loss this Crossover window is naturally opened further. > > Another optional signal parameter, identifying the MGC's anticipated > hook state, which the MG is required to match before attempting to > apply the signal, would help to shut this window. > > > Regards, > > Steve > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Megaco mailing 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 Jun 22 16:38:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBz7-0006cw-FV; Wed, 22 Jun 2005 16:38:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBz3-0006ZX-Q2 for megaco@megatron.ietf.org; Wed, 22 Jun 2005 16:38:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02121 for ; Wed, 22 Jun 2005 16:38:02 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlCJs-0000CL-BB for megaco@ietf.org; Wed, 22 Jun 2005 16:59:40 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E3A2C4F0002; Wed, 22 Jun 2005 22:34:11 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 22:34:11 +0200 Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 22:34:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] andisp/dwa and Hook State Change Race Date: Wed, 22 Jun 2005 22:33:49 +0200 Message-ID: Thread-Topic: [Megaco] andisp/dwa and Hook State Change Race Thread-Index: AcV3O6U+r3d6zC/oRge1slqRn5Te9AAI4vLg From: "Jan Lindquist (AL/EAB)" To: "Kevin Boyle" , "Christian Groves (BR/EPA)" , "Stephen Mell" X-OriginalArrivalTime: 22 Jun 2005 20:34:10.0627 (UTC) FILETIME=[BECC7930:01C57769] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.6 (/) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff 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="===============0405185740==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0405185740== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57769.B1FF46DB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57769.B1FF46DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Kevin, =20 It does not have to do with the ADD commands. It has to do with the Notify command with the off-hook and the Modify command with the andisp/dwa. Note that when the Modify command is sent the streammode is set to sendreceive so any event will cause the connection to through connect. The question is what do with when they cross over and the andisp/dwa is misinterpreted and through connection occurs. If I make a direct comparison with V5 this scenario may occur and the LE behaves differently depending on the country. It seems very logical to avoid any misinterpretations of the andisp/dwa and through connection by keeping the logic of accepting or not the off-hook in the MGC. Then the MG does not need to be provisioned and the MGC can be configured accordingly. =20 Regards, JanL =20 -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com]=20 Sent: den 22 juni 2005 17:03 To: Jan Lindquist (AL/EAB); Christian Groves (BR/EPA); Stephen Mell Cc: megaco@ietf.org Subject: RE: [Megaco] andisp/dwa and Hook State Change Race Why wouldn't we want the MG to be provisioned differently in different countries? It has to be already for the toneset... It seems to me that the problem you describe wouldn't exist anyway. The call will not be connected completely until the terminator's termination is in the context with the ephemeral for the bearer and is set to SendRecv. This would either happen as an Add Command to add the terminator to the context, or as a Modify Command to set the Mode to SendRecv for the terminator if the term is already in the context. Either way, cut through of the voice path will require MGC intervention. So there is time for the MGC to decide whether to connect the call or apply dialtone. Again, I believe the overwhelming focus on this race condition is making a mountain out of a molehill.=20 Kevin=20 -----Original Message-----=20 From: Jan Lindquist (AL/EAB) [mailto:jan.lindquist@ericsson.com]=20 Sent: Wednesday, June 22, 2005 5:31 AM=20 To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Christian Groves (BR/EPA); Stephen Mell=20 Cc: megaco@ietf.org=20 Subject: RE: [Megaco] andisp/dwa and Hook State Change Race=20 Hello,=20 Even if the situation of a cross over is rare there are requirements in legacy systems that dictate which end wins the race condition. Some countries require that the originating end wins the race condition so the off-hook will give you a dialtone and not somebody calling you. Other countries require the terminating end to win so if you lift up the off-hook the terminating call should come through so no dialtone, etc. There is a liaison from TISPAN requesting that dwa signal indicates clearly the expected state of the line in order to apply the ringing or call waiting. If this change is not provided then the MG has to be provisioned differently in different countries. This is what we want to avoid. Regards,=20 JanL=20 -----Original Message-----=20 From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Kevin Boyle=20 Sent: den 16 juni 2005 17:15=20 To: Christian Groves (BR/EPA); Stephen Mell=20 Cc: megaco@ietf.org=20 Subject: RE: [Megaco] andisp/dwa and Hook State Change Race=20 This race condition, in practice, occurs extremely rarely and does not seem to cause confusion to the end-user. In more than 5 years of active deployment across literally millions of lines of service there has never been a single compliant. There are two possible scenarios:=20 1. User picks up and listens for dialtone, intending to place a call but discovering that there is already a connection. They hear Call Wait tone and potentially get the number delivered (if the Signals descriptor isn't canceled fast enough). 2. User hangs up the phone from an existing call, and instantly gets ringing and number delivery. Scenario one is a weird case anyway. People don't generally enjoy picking up the phone and finding a connection present when they are expecting dialtone. This does happen on rare occasions, and the inclusion of a call wait tone at that moment does not seem to create any additional discomfort or problem over the already existing "twilight zone" connection. (The creepiest of these is when the person on the other end of the connection happens to be the person you were intending to call!) Scenario 2 is OK, because the call was going to present anyway -- this actually saves a NACK from the MG and a potential call loss. So, I think the issue here is being made out to be much bigger than it really is. In fact, given that scenario 2 saves a NACK, there is some beneficial economy to the methodology that exists. Kevin=20 -----Original Message-----=20 From: Christian Groves [mailto:christian.groves@ericsson.com]=20 Sent: Thursday, June 16, 2005 3:32 AM=20 To: Stephen Mell=20 Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org=20 Subject: Re: [Megaco] andisp/dwa and Hook State Change Race=20 Hello Stephen,=20 I believe this issue as been discussed at a recent Tispan meeting. I expect to see a liaison come into the July SG16 meeting on enhancements to H.248.23. So this will be discussed then. Regards, Christian=20 Stephen Mell wrote:=20 > Hello Kevin,=20 >=20 > We have experienced a situation which highlights a slight drawback=20 > with the current definition of andisp/dwa in H248.23, and thought it=20 > might be worth pointing it out now, should an "xandisp" ever=20 materialise.=20 >=20 > With most signals that my MG needs to apply, the nature of the signal=20 > implies whether or not it is sensible or not to apply that signal in=20 > the face of a given hook state. This is good as it helps greatly to=20 > mitigate the effect of network crossover situations. For example I can > choose to fail ringing if the line is now off-hook and send the=20 > required Notify to indicate failure if g/sc is armed.=20 >=20 > andisp/dwa is constructed in such an economical way that that the on=20 > and off hook signalling messages are syntactically the same, but are=20 > interpreted differently at the Gateway, dependant on the actual Hook=20 > state - However the MGC's anticipated hook state when it requested the > signal is not conveyed to the Gateway.=20 >=20 > When there is a crossover between an OFF/ON-HOOK notification from the > MG and a anddisp/dwa Signal from the MGC, the MG may end up=20 > inadvertantly applying inappropraite signalling to the line. Where=20 > there is packet loss this Crossover window is naturally opened=20 further.=20 >=20 > Another optional signal parameter, identifying the MGC's anticipated=20 > hook state, which the MG is required to match before attempting to=20 > apply the signal, would help to shut this window.=20 >=20 >=20 > Regards,=20 >=20 > Steve=20 >=20 >=20 > ---------------------------------------------------------------------- > --=20 >=20 > _______________________________________________=20 > Megaco mailing list=20 > Megaco@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/megaco=20 _______________________________________________=20 Megaco mailing list=20 Megaco@ietf.org=20 https://www1.ietf.org/mailman/listinfo/megaco=20 ------_=_NextPart_001_01C57769.B1FF46DB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hello=20 Kevin,
 
It=20 does not have to do with the ADD commands.  It has to do with the = Notify=20 command with the off-hook and the Modify command with the = andisp/dwa.  Note=20 that when the Modify command is sent the streammode is set to = sendreceive so any=20 event will cause the connection to through connect.  The question = is what=20 do with when they cross over and the andisp/dwa is misinterpreted and = through=20 connection occurs.  If I make a direct comparison with V5 this = scenario may=20 occur and the LE behaves differently depending on the country.  It = seems=20 very logical to avoid any misinterpretations of the andisp/dwa and = through=20 connection by keeping the logic of accepting or not the off-hook in the=20 MGC.  Then the MG does not need to be provisioned and the MGC can = be=20 configured accordingly.
 
Regards,
JanL
 
-----Original Message-----
From: Kevin Boyle=20 [mailto:kboyle@nortel.com]
Sent: den 22 juni 2005 = 17:03
To:=20 Jan Lindquist (AL/EAB); Christian Groves (BR/EPA); Stephen = Mell
Cc:=20 megaco@ietf.org
Subject: RE: [Megaco] andisp/dwa and Hook = State Change=20 Race

Why wouldn't we want the MG to be provisioned = differently in=20 different countries?  It has to be already for the = toneset...

It seems to me that the problem you describe wouldn't = exist=20 anyway.  The call will not be connected completely until the = terminator's=20 termination is in the context with the ephemeral for the bearer and is = set to=20 SendRecv.  This would either happen as an Add Command to add the = terminator=20 to the context, or as a Modify Command to set the Mode to SendRecv for = the=20 terminator if the term is already in the context.  Either way, cut = through=20 of the voice path will require MGC intervention.  So there is time = for the=20 MGC to decide whether to connect the call or apply dialtone.

Again, I believe the overwhelming focus on this race = condition=20 is making a mountain out of a molehill.

Kevin

-----Original Message-----
From: Jan=20 Lindquist (AL/EAB) [mailto:jan.lindquist@ericsson.= com]=20
Sent: Wednesday, June 22, 2005 5:31 AM =
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Christian Groves (BR/EPA); = Stephen=20 Mell
Cc: megaco@ietf.org
Subject: RE: [Megaco] andisp/dwa and Hook State Change = Race

Hello,

Even if the situation of a cross over is rare there = are=20 requirements in legacy systems that dictate which end wins the race=20 condition.  Some countries require that the originating end wins = the race=20 condition so the off-hook will give you a dialtone and not somebody = calling=20 you.

Other countries require the terminating end to win so = if you=20 lift up the off-hook the terminating call should come through so no = dialtone,=20 etc.

There is a liaison from TISPAN requesting that dwa = signal=20 indicates clearly the expected state of the line in order to apply the = ringing=20 or call waiting.  If this change is not provided then the MG has to = be=20 provisioned differently in different countries.  This is what we = want to=20 avoid.

Regards,
JanL

-----Original Message-----
From:=20 megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On=20 Behalf Of Kevin Boyle
Sent: den 16 juni 2005=20 17:15
To: Christian Groves (BR/EPA); Stephen = Mell=20
Cc: megaco@ietf.org
Subject: RE:=20 [Megaco] andisp/dwa and Hook State Change Race


This race condition, in practice, occurs extremely = rarely and=20 does not seem to cause confusion to the end-user.  In more than 5 = years of=20 active deployment across literally millions of lines of service there = has never=20 been a single compliant.

There are two possible scenarios:
1.=20 User picks up and listens for dialtone, intending to place a call but=20 discovering that there is already a connection. They hear Call Wait tone = and=20 potentially get the number delivered (if the Signals descriptor isn't = canceled=20 fast enough). 2. User hangs up the phone from an existing call, and = instantly=20 gets ringing and number delivery.

Scenario one is a weird case anyway.  People = don't=20 generally enjoy picking up the phone and finding a connection present = when they=20 are expecting dialtone.  This does happen on rare occasions, and = the=20 inclusion of a call wait tone at that moment does not seem to create any = additional discomfort or problem over the already existing "twilight = zone"=20 connection. (The creepiest of these is when the person on the other end = of the=20 connection happens to be the person you were intending to = call!)

Scenario 2 is OK, because the call was going to = present anyway=20 -- this actually saves a NACK from the MG and a potential call = loss.

So, I think the issue here is being made out to be = much bigger=20 than it really is.  In fact, given that scenario 2 saves a NACK, = there is=20 some beneficial economy to the methodology that exists.

Kevin

-----Original Message-----
From:=20 Christian Groves [mailto:christian.groves@eri= csson.com]=20
Sent: Thursday, June 16, 2005 3:32 AM =
To: Stephen Mell
Cc: Boyle, Kevin=20 [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: = Re: [Megaco]=20 andisp/dwa and Hook State Change Race

Hello Stephen,

I believe this issue as been discussed at a recent = Tispan=20 meeting. I expect to see a liaison come into the July SG16 meeting on=20 enhancements to H.248.23. So this will be discussed then.

Regards, Christian

Stephen Mell wrote:

> Hello Kevin,
> =
> We have experienced a situation which highlights a slight = drawback=20
> with the current definition of andisp/dwa = in=20 H248.23, and thought it
> might be worth = pointing it=20 out now, should an "xandisp" ever
materialise.=20
>
> With most signals = that my MG=20 needs to apply, the nature of the signal
> = implies=20 whether or not it is sensible or not to apply that signal in =
> the face of a given hook state. This is good as it helps = greatly to=20
> mitigate the effect of network crossover=20 situations. For example I can

> choose to fail ringing if the line is now = off-hook and send=20 the
> required Notify to indicate failure = if g/sc is=20 armed.
>
> = andisp/dwa is=20 constructed in such an economical way that that the on
> and off hook signalling messages are syntactically the = same, but are=20
> interpreted differently at the Gateway, = dependant=20 on the actual Hook
> state - However the = MGC's=20 anticipated hook state when it requested the

> signal is not conveyed to the Gateway. =
>
> When there is a crossover = between an=20 OFF/ON-HOOK notification from the
> MG and = a=20 anddisp/dwa Signal from the MGC, the MG may end up
>=20 inadvertantly applying inappropraite signalling to the line. Where=20
> there is packet loss this Crossover = window is=20 naturally opened
further.
>=20
> Another optional signal parameter, = identifying the=20 MGC's anticipated
> hook state, which the = MG is=20 required to match before attempting to
> = apply the=20 signal, would help to shut this window.
>=20
>
> = Regards,=20
>
> Steve =
>
>
>=20 ----------------------------------------------------------------------=20
> --
> =
> _______________________________________________ =
> Megaco mailing list
>=20 Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco =



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

=00 ------_=_NextPart_001_01C57769.B1FF46DB-- --===============0405185740== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0405185740==-- From megaco-bounces@ietf.org Wed Jun 22 19:05:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlEHH-0005Q6-9w; Wed, 22 Jun 2005 19:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlEHF-0005NT-Ob for megaco@megatron.ietf.org; Wed, 22 Jun 2005 19:05:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15859 for ; Wed, 22 Jun 2005 19:04:58 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlEfS-0007iN-7i for megaco@ietf.org; Wed, 22 Jun 2005 19:30:03 -0400 Received: by zproxy.gmail.com with SMTP id 9so668469nzo for ; Wed, 22 Jun 2005 16:04:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Q+c8ZvhbzskOW+WkdxvkM1eUHfUUlyzBTL7FjVbPzBLYXw3ykXEmeS/B72o8FSWggIA6URto+bJmot2Si2Gtix7+Jo0FZFcoPf1BGsw6oW49c/zrGPctl30YMUlxvWNagIKn5IiBO4ZEjQynZ364hKzMcVUAjhuRkHm/3JgFW9M= Received: by 10.36.129.6 with SMTP id b6mr894481nzd; Wed, 22 Jun 2005 16:04:50 -0700 (PDT) Received: by 10.36.49.10 with HTTP; Wed, 22 Jun 2005 16:04:50 -0700 (PDT) Message-ID: Date: Thu, 23 Jun 2005 01:04:50 +0200 From: Vijay Iyengar To: megaco@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] H.248.36 hangterm X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vijay Iyengar 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 , Can anyone explain how hangterm/timerx works? Meaningful configuration parameters for Timer X are basically a result of a trade-off decision between the contradicting requirements of "fast detection of hanging terminations" and "minimization of traffic load from unnecessary event notifications". Can we use for a periodic garbage cleanup in the MG, because having a very small timer could lead lots of traffic due to the event notification= s. (May be Albrecht can throw more light on this :-) ) Regards Vijay Vidyuth-Fix Engg _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Jun 22 22:15:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlHFH-0001YN-9P; Wed, 22 Jun 2005 22:15:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlHFF-0001YH-Ll for megaco@megatron.ietf.org; Wed, 22 Jun 2005 22:15:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02247 for ; Wed, 22 Jun 2005 22:15:07 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlHdT-0007QA-H9 for megaco@ietf.org; Wed, 22 Jun 2005 22:40:13 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 07FD1C81; Thu, 23 Jun 2005 04:14:47 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 04:14:46 +0200 Received: from [146.11.22.2] ([146.11.22.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 04:14:44 +0200 Message-ID: <42B9FFDE.9090707@ericsson.com> Date: Thu, 23 Jun 2005 10:18:38 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Vijay Iyengar Subject: Re: [Megaco] H.248.36 hangterm References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2005 02:14:45.0548 (UTC) FILETIME=[52F5F6C0:01C57799] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Hello Vijay, Yes the idea is that the hangterm/timerx is used for a periodic garbage cleanup. It is not advisable to set the timer to a very small period as will generate lots of messages (if you have a very unreliable MG/MGC you may want to though :) ) Regards, Christian Vijay Iyengar wrote: > Hi , > > Can anyone explain how hangterm/timerx works? > > Meaningful configuration parameters for Timer X are basically a result > of a trade-off decision between the contradicting requirements of > "fast detection of hanging terminations" and "minimization of traffic > load from unnecessary event notifications". > > Can we use for a periodic garbage cleanup in the MG, because having > a very small timer could lead lots of traffic due to the event > notifications. > > (May be Albrecht can throw more light on this :-) ) > > Regards > Vijay > > Vidyuth-Fix Engg > > _______________________________________________ > Megaco mailing 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 Jun 23 15:09:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlX4j-0005Rb-FT; Thu, 23 Jun 2005 15:09:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlX4i-0005RW-0x for megaco@megatron.ietf.org; Thu, 23 Jun 2005 15:09:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17273 for ; Thu, 23 Jun 2005 15:09:18 -0400 (EDT) Received: from web61311.mail.yahoo.com ([209.73.179.80]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DlXT4-0004SA-DH for megaco@ietf.org; Thu, 23 Jun 2005 15:34:32 -0400 Received: (qmail 30980 invoked by uid 60001); 23 Jun 2005 19:09:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KxSgzoXJAXCBZ+U5rLG4xzHGtNergp1PX3X1a5MKedW/ChxfPgn59xNEIpD4bGIORBc/bb4CWIS80JFnTjIptHOYWTwPD46mFVOmbSTKvginLmwMTUwM4c42Ln/MGloP5Il8h5r+M9DEwYgB8MOPIhsDqntPzdwoJnvQCQdHvoo= ; Message-ID: <20050623190908.30976.qmail@web61311.mail.yahoo.com> Received: from [216.223.9.2] by web61311.mail.yahoo.com via HTTP; Thu, 23 Jun 2005 12:09:08 PDT Date: Thu, 23 Jun 2005 12:09:08 -0700 (PDT) From: Frank Reno Subject: Re: [Megaco] Topology Questions To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: 8bit X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello, Any more thoughts on my question 2 below? Version 1 of the protocol apparently allows per stream topology to exist, but there doesn't seem to be a way to report it in a topology audit. Given Transaction = 1 { Context = 1 { Topology {t1, t2, oneway}, Add = t1 {Media {Stream = 1{...}}}, Add = t2 {Media {Stream = 1{...}}} } } Transaction = 2 { Context = 1 { Modify = t1 {Media {Stream = 2{...}}}, Modify = t2 {Media {Stream = 2{...}}} } } Transaction = 3 { Context = 1 { ContextAudit{Topology} } } In version 2, the reply to transaction 3 would look like Reply = 3 { Context = 1 { Topology { t1, t2, Oneway, Stream=1, t1, t2, Bothway, Stream=2 } } } How should a version 1 MG reply? - Same as version 2 (would need the IG to allow stream IDs in the reply) - Some error code - Multiple triples for the same pair of terminations ("t1, t2, Oneway, t1, t2, Bothway") - One triple per pair, merging the modes somehow ("t1, t2, Bothway") Some more questions on the topology audit... 4. How should the MG reply to a topology audit when there is only one termination in the context? In the text encoding, it is impossible to encode an empty topology descriptor. Can we change the grammar to allow this, or should the MG use some dummy triple such as "t1, t1, bothway" or "*, *, bothway"? 5. What topology association should be reported for terminations that are in the same context but do not share any streams with the same streamID? Should it be oneway or bothway or should no association be reported? No association seems best to me, but we would need to allow the empty topology descriptor (in case there are no other associations to report). 6. It looks like the Topology Descriptor is being moved inside the contextAttrDescriptor in the version 3 ABNF. Won't this break compatibility? Regards, Frank --- Frank Reno wrote: Thanks for the reply, Kevin. 2. Your rule seems to make good sense for version 2. Does this mean, however, that a version 1 MG should support per-stream topology even though the MGC cannot control it directly? For my example, I'm assuming that you mean that the topology regarding stream 1 is unchanged by the addition of stream 2, regardless of protocol version. This would leave stream 1 oneway and stream 2 bothways. A version 1 MG would have no way to describe this in a topology audit. Thanks --- Kevin Boyle wrote: > 1. Only those currently in the context. In your > example, flow is bothway > between a/2 and b/1. > 2. Only to existing streams. In your example, flow > on stream 2 is bothway. > The answer is the same in all version of the > protocol. > 3. The correct response is the one that lists all > the associations, though I > can see the utility of the one immediately below > that which uses wildcards > to reduce the message size. > > Kevin > > -----Original Message----- > From: megaco-bounces at ietf.org > [mailto:megaco-bounces at ietf.org] On Behalf Of > Frank Reno > Sent: Thursday, June 02, 2005 5:16 PM > To: megaco at ietf.org > Subject: [Megaco] Topology Questions > > Hello List, > > 1. Does a topology association with wildcarded > termination IDs apply to > terminations added to the context in the future or > only to those currently > in the context? > > Transaction = 1 > { > Context = 1 > { > Topology {a/*, b/*, oneway}, > Add = a/1, Add = b/1 > } > } > Transaction = 2 > { > Context = 1 > { > Add = a/2 > } > } > > What is the media flow between a/2 and b/1? > > 2. Does a topology association between two > terminations apply to new streams > created on the terminations? > > Transaction = 1 > { > Context = 1 > { > Topology {t1, t2, oneway}, > Add = t1 {Media {Stream = 1{...}}}, > Add = t2 {Media {Stream = 1{...}}} > } > } > Transaction = 2 > { > Context = 1 > { > Modify = t1 {Media {Stream = 2{...}}}, > Modify = t2 {Media {Stream = 2{...}}} > } > } > > What is the media flow between t1 and t2 for stream > 2? > Is the answer different between protocol version 1 > and 2? > > > 3. What does the reply to an audit of the topology > descriptor look like? I > assume it's valid to include an association for > every pair of terminations > (or > streams) but this may lead to large message. Is it > valid to only describe > the links that are missing? > > > Transaction = 1 > { > Context = 1 > { > Topology {t1, t2, oneway}, > Add = t1, Add = t2, Add = t3, Add = t4 > } > } > Transaction = 2 > { > Context = 1 > { > ContextAudit {Topology} > } > } > > > Is this valid? > > Reply = 2 > { > Context = 1 > { > Topology { > t1, t2, oneway > } > } > } > > Or must all links be specified like one of these: > > > Reply = 2 > { > Context = 1 > { > Topology { > t1, t2, oneway, > t1, t3, bothway, > t1, t4, bothway, > t2, t3, bothway, > t2, t4, bothway, > t3, t4, bothway > } > } > } > > Reply = 2 > { > Context = 1 > { > Topology { > t1, t2, oneway, > t3, *, bothway, > t4, *, bothway > } > } > } > > > cheers, > frank > ____________________________________________________ Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 23 22:06:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DldZy-00064i-Od; Thu, 23 Jun 2005 22:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DldZw-00064d-Nu for megaco@megatron.ietf.org; Thu, 23 Jun 2005 22:06:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26009 for ; Thu, 23 Jun 2005 22:05:59 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DldyN-0002s0-Ks for megaco@ietf.org; Thu, 23 Jun 2005 22:31:16 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CE969A15; Fri, 24 Jun 2005 04:05:41 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Jun 2005 04:05:41 +0200 Received: from [146.11.22.120] ([146.11.22.120]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Jun 2005 04:05:39 +0200 Message-ID: <42BB6A6F.3010007@ericsson.com> Date: Fri, 24 Jun 2005 12:05:35 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Frank Reno Subject: Re: [Megaco] Topology Questions References: <20050623190908.30976.qmail@web61311.mail.yahoo.com> In-Reply-To: <20050623190908.30976.qmail@web61311.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jun 2005 02:05:39.0626 (UTC) FILETIME=[37FAA0A0:01C57861] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 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 Hello Frank, Version 1 does not allow topology per stream at least by setting the topology descriptor or by audit. This was only added in Version 2. The problem you highlight was one of the reasons for adding streams in v2. For version 2 the return to the audit should be bothway because the terminations are bothway connected. (Remember v1 has no concept of streams for topology). Please see my responses below. Regards, Christian Frank Reno wrote: > Hello, > > Any more thoughts on my question 2 below? Version 1 of > the protocol apparently allows per stream topology to > exist, but there doesn't seem to be a way to report it > in a topology audit. > > Given > > Transaction = 1 > { > Context = 1 > { > Topology {t1, t2, oneway}, > Add = t1 {Media {Stream = 1{...}}}, > Add = t2 {Media {Stream = 1{...}}} > } > } > Transaction = 2 > { > Context = 1 > { > Modify = t1 {Media {Stream = 2{...}}}, > Modify = t2 {Media {Stream = 2{...}}} > } > } > Transaction = 3 > { > Context = 1 > { > ContextAudit{Topology} > } > } > > In version 2, the reply to transaction 3 would look > like > > Reply = 3 > { > Context = 1 > { > Topology > { > t1, t2, Oneway, Stream=1, > t1, t2, Bothway, Stream=2 > } > } > } > > How should a version 1 MG reply? > > - Same as version 2 (would need the IG to allow stream > IDs in the reply) > - Some error code > - Multiple triples for the same pair of terminations > ("t1, t2, Oneway, t1, t2, Bothway") > - One triple per pair, merging the modes somehow ("t1, > t2, Bothway") > > > Some more questions on the topology audit... > > 4. How should the MG reply to a topology audit when > there is only one termination in the context? In the > text encoding, it is impossible to encode an empty > topology descriptor. Can we change the grammar to > allow this, or should the MG use some dummy triple > such as "t1, t1, bothway" or "*, *, bothway"? [CHG] If a context contains a termination I'm not sure an empty descriptor is best. A triple to indicate may be better e.g. t1,*,isolate. Its the topology you would use to isolate a single termination which effectively is what a termination in a context by itself is. I don't think *,*,bothway is appropriate as it doesn't even return the name of the one termination. > > 5. What topology association should be reported for > terminations that are in the same context but do not > share any streams with the same streamID? Should it be > oneway or bothway or should no association be > reported? No association seems best to me, but we > would need to allow the empty topology descriptor (in > case there are no other associations to report). [CHG] If the termination has no association with any other report [T1,*,isolate]. This would be the triple that sets the associated. > > 6. It looks like the Topology Descriptor is being > moved inside the contextAttrDescriptor in the version > 3 ABNF. Won't this break compatibility? [CHG] The coding on the line shouldn't change. So you are correct this shouldn't be moved. Kevin can you fix this in your editing updates? > > Regards, > Frank > > --- Frank Reno wrote: > > Thanks for the reply, Kevin. > > 2. Your rule seems to make good sense for version 2. > Does this mean, however, that a version 1 MG should > support per-stream topology even though the MGC cannot > control it directly? > > For my example, I'm assuming that you mean that the > topology regarding stream 1 is unchanged by the > addition of stream 2, regardless of protocol version. > This would leave stream 1 oneway and stream 2 > bothways. A version 1 MG would have no way to describe > this in a topology audit. > > Thanks > > --- Kevin Boyle wrote: > > >>1. Only those currently in the context. In your >>example, flow is bothway >>between a/2 and b/1. >>2. Only to existing streams. In your example, flow >>on stream 2 is bothway. >>The answer is the same in all version of the >>protocol. >>3. The correct response is the one that lists all >>the associations, though I >>can see the utility of the one immediately below >>that which uses wildcards >>to reduce the message size. >> >>Kevin >> >>-----Original Message----- >>From: megaco-bounces at ietf.org >>[mailto:megaco-bounces at ietf.org] On Behalf Of >>Frank Reno >>Sent: Thursday, June 02, 2005 5:16 PM >>To: megaco at ietf.org >>Subject: [Megaco] Topology Questions >> >>Hello List, >> >>1. Does a topology association with wildcarded >>termination IDs apply to >>terminations added to the context in the future or >>only to those currently >>in the context? >> >> Transaction = 1 >> { >> Context = 1 >> { >> Topology {a/*, b/*, oneway}, >> Add = a/1, Add = b/1 >> } >> } >> Transaction = 2 >> { >> Context = 1 >> { >> Add = a/2 >> } >> } >> >> What is the media flow between a/2 and b/1? >> >>2. Does a topology association between two >>terminations apply to new streams >>created on the terminations? >> >> Transaction = 1 >> { >> Context = 1 >> { >> Topology {t1, t2, oneway}, >> Add = t1 {Media {Stream = 1{...}}}, >> Add = t2 {Media {Stream = 1{...}}} >> } >> } >> Transaction = 2 >> { >> Context = 1 >> { >> Modify = t1 {Media {Stream = 2{...}}}, >> Modify = t2 {Media {Stream = 2{...}}} >> } >> } >> >> What is the media flow between t1 and t2 for stream >>2? >> Is the answer different between protocol version 1 >>and 2? >> >> >>3. What does the reply to an audit of the topology >>descriptor look like? I >>assume it's valid to include an association for >>every pair of terminations >>(or >>streams) but this may lead to large message. Is it >>valid to only describe >>the links that are missing? >> >> >> Transaction = 1 >> { >> Context = 1 >> { >> Topology {t1, t2, oneway}, >> Add = t1, Add = t2, Add = t3, Add = t4 >> } >> } >> Transaction = 2 >> { >> Context = 1 >> { >> ContextAudit {Topology} >> } >> } >> >> >> Is this valid? >> >> Reply = 2 >> { >> Context = 1 >> { >> Topology { >> t1, t2, oneway >> } >> } >> } >> >> Or must all links be specified like one of these: >> >> >> Reply = 2 >> { >> Context = 1 >> { >> Topology { >> t1, t2, oneway, >> t1, t3, bothway, >> t1, t4, bothway, >> t2, t3, bothway, >> t2, t4, bothway, >> t3, t4, bothway >> } >> } >> } >> >> Reply = 2 >> { >> Context = 1 >> { >> Topology { >> t1, t2, oneway, >> t3, *, bothway, >> t4, *, bothway >> } >> } >> } >> >> >>cheers, >>frank >> > > > > > ____________________________________________________ > Yahoo! Sports > Rekindle the Rivalries. Sign up for Fantasy Football > http://football.fantasysports.yahoo.com > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 24 11:21:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlq00-0006MR-4G; Fri, 24 Jun 2005 11:21:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlpzy-0006MJ-D0 for megaco@megatron.ietf.org; Fri, 24 Jun 2005 11:21:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17225 for ; Fri, 24 Jun 2005 11:21:40 -0400 (EDT) Received: from web61315.mail.yahoo.com ([209.73.179.84]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DlqOT-0005fl-D0 for megaco@ietf.org; Fri, 24 Jun 2005 11:47:05 -0400 Received: (qmail 97136 invoked by uid 60001); 24 Jun 2005 15:21:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=w5BMSFcNH5OmsJd/hXbiCgR1G+AOC7eVAvQbzjPzwddPQJzSZ4lLDAkanO4TtwUrXEhGro1YDeHLtRfsKhUH+R2JMmR0AFkpa7P8FwquiGofSzEPoyZ24a3UGVESYIijnigHkcKM517/WuzibIKYHlSPykA/mEB3C2EICgn9M/U= ; Message-ID: <20050624152126.97134.qmail@web61315.mail.yahoo.com> Received: from [216.223.9.2] by web61315.mail.yahoo.com via HTTP; Fri, 24 Jun 2005 08:21:26 PDT Date: Fri, 24 Jun 2005 08:21:26 -0700 (PDT) From: Frank Reno Subject: Re: [Megaco] Topology Questions To: Christian Groves In-Reply-To: <42BB6A6F.3010007@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Content-Transfer-Encoding: 8bit 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 Thanks for the reply. Did you mean "For version 1 the return to the audit should be bothway"? So can we say that if flow exists in a given direction for any stream, then flow is reported for that direction at the termination level? For example t1, t2, oneway, stream=1 t2, t1, oneway, stream=2 is reported in version 1 as t1, t2, bothway Here's another one... 7. Section 7.1.18 states that "It is possible to have an action containing only a Topology descriptor". In the text encoding, what should the response be to such an action? The ABNF requires something in the actionReply - at least one context property, command reply or error descriptor. --- Christian Groves wrote: > Hello Frank, > > Version 1 does not allow topology per stream at > least by setting the topology > descriptor or by audit. This was only added in > Version 2. The problem you > highlight was one of the reasons for adding streams > in v2. > > For version 2 the return to the audit should be > bothway because the terminations > are bothway connected. (Remember v1 has no concept > of streams for topology). > > Please see my responses below. > > Regards, Christian > > Frank Reno wrote: > > > Hello, > > > > Any more thoughts on my question 2 below? Version > 1 of > > the protocol apparently allows per stream topology > to > > exist, but there doesn't seem to be a way to > report it > > in a topology audit. > > > > Given > > > > Transaction = 1 > > { > > Context = 1 > > { > > Topology {t1, t2, oneway}, > > Add = t1 {Media {Stream = 1{...}}}, > > Add = t2 {Media {Stream = 1{...}}} > > } > > } > > Transaction = 2 > > { > > Context = 1 > > { > > Modify = t1 {Media {Stream = 2{...}}}, > > Modify = t2 {Media {Stream = 2{...}}} > > } > > } > > Transaction = 3 > > { > > Context = 1 > > { > > ContextAudit{Topology} > > } > > } > > > > In version 2, the reply to transaction 3 would > look > > like > > > > Reply = 3 > > { > > Context = 1 > > { > > Topology > > { > > t1, t2, Oneway, Stream=1, > > t1, t2, Bothway, Stream=2 > > } > > } > > } > > > > How should a version 1 MG reply? > > > > - Same as version 2 (would need the IG to allow > stream > > IDs in the reply) > > - Some error code > > - Multiple triples for the same pair of > terminations > > ("t1, t2, Oneway, t1, t2, Bothway") > > - One triple per pair, merging the modes somehow > ("t1, > > t2, Bothway") > > > > > > Some more questions on the topology audit... > > > > 4. How should the MG reply to a topology audit > when > > there is only one termination in the context? In > the > > text encoding, it is impossible to encode an empty > > topology descriptor. Can we change the grammar to > > allow this, or should the MG use some dummy triple > > such as "t1, t1, bothway" or "*, *, bothway"? > > [CHG] If a context contains a termination I'm not > sure an empty descriptor is > best. A triple to indicate may be better e.g. > t1,*,isolate. Its the topology you > would use to isolate a single termination which > effectively is what a > termination in a context by itself is. I don't think > *,*,bothway is appropriate > as it doesn't even return the name of the one > termination. > > > > > 5. What topology association should be reported > for > > terminations that are in the same context but do > not > > share any streams with the same streamID? Should > it be > > oneway or bothway or should no association be > > reported? No association seems best to me, but we > > would need to allow the empty topology descriptor > (in > > case there are no other associations to report). > > [CHG] If the termination has no association with any > other report > [T1,*,isolate]. This would be the triple that sets > the associated. > > > > > 6. It looks like the Topology Descriptor is being > > moved inside the contextAttrDescriptor in the > version > > 3 ABNF. Won't this break compatibility? > > [CHG] The coding on the line shouldn't change. So > you are correct this shouldn't > be moved. Kevin can you fix this in your editing > updates? > > > > > Regards, > > Frank > > > > --- Frank Reno wrote: > > > > Thanks for the reply, Kevin. > > > > 2. Your rule seems to make good sense for version > 2. > > Does this mean, however, that a version 1 MG > should > > support per-stream topology even though the MGC > cannot > > control it directly? > > > > For my example, I'm assuming that you mean that > the > > topology regarding stream 1 is unchanged by the > > addition of stream 2, regardless of protocol > version. > > This would leave stream 1 oneway and stream 2 > > bothways. A version 1 MG would have no way to > describe > > this in a topology audit. > > > > Thanks > > > > --- Kevin Boyle wrote: > > > > > >>1. Only those currently in the context. In your > >>example, flow is bothway > >>between a/2 and b/1. > >>2. Only to existing streams. In your example, flow > >>on stream 2 is bothway. > >>The answer is the same in all version of the > >>protocol. > >>3. The correct response is the one that lists all > >>the associations, though I > >>can see the utility of the one immediately below > >>that which uses wildcards > >>to reduce the message size. > >> > >>Kevin > >> > >>-----Original Message----- > >>From: megaco-bounces at ietf.org > >>[mailto:megaco-bounces at ietf.org] On Behalf Of > >>Frank Reno > >>Sent: Thursday, June 02, 2005 5:16 PM > >>To: megaco at ietf.org > >>Subject: [Megaco] Topology Questions > >> > >>Hello List, > >> > >>1. Does a topology association with wildcarded > >>termination IDs apply to > >>terminations added to the context in the future or > >>only to those currently > >>in the context? > >> > >> Transaction = 1 > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 24 11:34:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlqCP-0008LN-KU; Fri, 24 Jun 2005 11:34:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlqCN-0008L4-De for megaco@megatron.ietf.org; Fri, 24 Jun 2005 11:34:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18083 for ; Fri, 24 Jun 2005 11:34:29 -0400 (EDT) Received: from mercurio.italtel.it ([138.132.53.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlqau-0006GU-RK for megaco@ietf.org; Fri, 24 Jun 2005 11:59:54 -0400 Received: from mercurio.italtel.it (localhost [127.0.0.1]) by mercurio.italtel.it (8.12.11/8.12.11) with ESMTP id j5OFY5cm011160 for ; Fri, 24 Jun 2005 17:34:06 +0200 (MEST) Received: from ICSSW035.corp.dom (icssw035.settimo.italtel.it [138.132.90.72]) by mercurio.italtel.it (8.12.11/8.12.11) with ESMTP id j5OFXxD2011132; Fri, 24 Jun 2005 17:34:04 +0200 (MEST) X-Spam-Filter: made by mercurio.italtel.it Received: from BESONE.corp.dom ([138.132.89.14]) by ICSSW035.corp.dom with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Jun 2005 17:33:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Date: Fri, 24 Jun 2005 17:33:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <8E6DA0ECC9F8EE4483CBF31602B1537E81D321@BESONE.corp.dom> Thread-Topic: The ABNF coding of VALUE doesn't allow to represent a generic UTF-8 string/char Thread-Index: AcV41ar3KYXWbLv4TqiNr/fLEr9TMg== From: "Contardi Angelo" To: "Megaco IETF - Mail List \(E-mail\)" X-OriginalArrivalTime: 24 Jun 2005 15:33:55.0609 (UTC) FILETIME=[21D66090:01C578D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: "Christian Groves \(E-mail\)" Subject: [Megaco] The ABNF coding of VALUE doesn't allow to represent a generic UTF-8 string/char X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello, from my previous private discussion with Christian Groves, i have = deduce this: The ABNF coding of VALUE doesn't allow to represent a generic UTF-8 = string or char (RFC 3629) because of: 1) The FIRST byte of an UTF-8 char may be ANY ASCII char in the range = 0x00-0x7E and, for instance, the ASCII 0x00-0x07 and 0x22 (") are not = allowed in ANY ABNF form of VALUE. =20 2) Furthermore, UTF-8 chars "greater than 0x7E", need "ASCII chars" = (to better say, Octets) in the range 0x80-0xFF (not ALL), not allowed in ANY = ABNF form of VALUE. So, to "correct" this problem, i can suggest two possible solutions: 1) The simple one, code the UTF-8 string/char in "Octect Mode", as = described in ANNEX B.3. This is a BAD solution from the efficiency transmission = point of view because of it "halve the TX band": to TX one UTF-8 char (max = 4 Octet) i must TX max 2 x 4 =3D 8 Octet (ASCII chars). 2) The difficult one, allow the ABNF quoted form of VALUE to TX ALL = ASCII chars 0x01-0xFF (the range 0x80-0xFF are more properly named OCTET in = RFC2234 ), except 0x22 ("), that should be ESCAPED with "\", as already done = for ABNF Local and Remote Descriptor (see SDP). Note that '\0' (0x00) is NOT = ALLOWED in this new quoted string form as in the present one, but it's not a = problem because in UTF-8 the char '\0' (0x00) is same as in ASCII (string = terminator) and is NOT used to code "non ASCII" UTF-8 chars, all those chars > = 0x7F that require more than one ASCII chars to be encoded (from 2 to 4 ASCII = chars). In fact the "extra chars" needed to code an UTF-8 char are all above = 0x7F. While the 1st mode doesn't require any modification of ABNF syntax = (but is it applicable in any case ?), the 2nd one require this ABNF modification: quotedString =3D DQUOTE *(quotedChar) DQUOTE =09 ; %x22 (") is allowed just if "escaped" with "\" quotedChar =3D ( %x01-21 / "\" DQUOTE / %x23-FF ) In a parser implementation, i think, this is not a "terrible = complication" and can be solved in the same way of "octetString" of Local and = RemoteDescriptor. It require also to implement an ESCAPE "strip(rx)/padding(tx)" = mechanism, as=20 already required for SDP. P.S.: I suppose NO ONE need to send the "string terminator" '\0' = (0x00) in an UTF-8 string or char. If my assertion is false, in the "solution = 2)" the %x00 should also be "escaped". Viceversa, the "solution 1)" can = already "transport" %x00 octet. Best regards o o o o o o o . . . ___________________________________ o _____ || Angelo Contardi | .][__n_n_|DD[ =3D=3D=3D=3D_____ | angelo.contardi@italtel.it = | >(________|__|_[_________]_|________________________________| _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o` _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 24 12:00:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlqbv-0004C1-NB; Fri, 24 Jun 2005 12:00:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlqbt-0004Bp-GK for megaco@megatron.ietf.org; Fri, 24 Jun 2005 12:00:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19974 for ; Fri, 24 Jun 2005 12:00:51 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlr0P-0007Ny-6u for megaco@ietf.org; Fri, 24 Jun 2005 12:26:16 -0400 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 Subject: RE: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Date: Fri, 24 Jun 2005 12:00:41 -0400 Message-ID: Thread-Topic: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Thread-Index: AcV41ar3KYXWbLv4TqiNr/fLEr9TMgAAg3Ew From: "Steve Cipolli" To: "Contardi Angelo" , "Megaco IETF - Mail List \(E-mail\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Cc: "Christian Groves \(E-mail\)" 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 Two points: 1. It is not necessary to quote the UTF-8 characters as you define in your second solution. VALUE can be extended to accept characters (quoted and unquoted) in the range 0x80-0xFF. =20 2. Providing a mechanism to allow double quotes (") in a (double) quotedstring is essentially a separate issue, since addition of UTF-8 chars does not motivate the need for this mechanism nor complicate its addition. --Stephen > -----Original Message----- > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org] On Behalf Of Contardi Angelo > Sent: Friday, June 24, 2005 11:34 AM > To: Megaco IETF - Mail List (E-mail) > Cc: Christian Groves (E-mail) > Subject: [Megaco] The ABNF coding of VALUE doesn't allow to=20 > represent ageneric UTF-8 string/char >=20 >=20 > Hello, >=20 > from my previous private discussion with Christian Groves,=20 > i have deduce this: >=20 > The ABNF coding of VALUE doesn't allow to represent a=20 > generic UTF-8 string or char (RFC 3629) because of: >=20 > 1) The FIRST byte of an UTF-8 char may be ANY ASCII char in=20 > the range 0x00-0x7E > and, for instance, the ASCII 0x00-0x07 and 0x22 (") are=20 > not allowed in ANY > ABNF form of VALUE. > =20 > 2) Furthermore, UTF-8 chars "greater than 0x7E", need "ASCII=20 > chars" (to better > say, Octets) in the range 0x80-0xFF (not ALL), not allowed=20 > in ANY ABNF form > of VALUE. >=20 > So, to "correct" this problem, i can suggest two possible solutions: >=20 > 1) The simple one, code the UTF-8 string/char in "Octect=20 > Mode", as described in > ANNEX B.3. This is a BAD solution from the efficiency =20 > transmission point of > view because of it "halve the TX band": to TX one UTF-8 =20 > char (max 4 Octet) > i must TX max 2 x 4 =3D 8 Octet (ASCII chars). >=20 > 2) The difficult one, allow the ABNF quoted form of VALUE to =20 > TX ALL ASCII chars > 0x01-0xFF (the range 0x80-0xFF are more properly named =20 > OCTET in RFC2234 ), > except 0x22 ("), that should be ESCAPED with "\", as =20 > already done for ABNF > Local and Remote Descriptor (see SDP). Note that '\0'=20 > (0x00) is NOT ALLOWED > in this new quoted string form as in the present one, but=20 > it's not a problem > because in UTF-8 the char '\0' (0x00) is same as in ASCII=20 > (string terminator) > and is NOT used to code "non ASCII" UTF-8 chars, all=20 > those chars > 0x7F that > require more than one ASCII chars to be encoded (from 2 to=20 > 4 ASCII chars). In > fact the "extra chars" needed to code an UTF-8 char are=20 > all above 0x7F. >=20 > While the 1st mode doesn't require any modification of=20 > ABNF syntax (but is it applicable in any case ?), the 2nd one=20 > require this ABNF modification: >=20 > quotedString =3D DQUOTE *(quotedChar) DQUOTE > =09 > ; %x22 (") is allowed just if "escaped" with "\" > quotedChar =3D ( %x01-21 / "\" DQUOTE / %x23-FF ) >=20 > In a parser implementation, i think, this is not a =20 > "terrible complication" and can be solved in the same way of=20 > "octetString" of Local and RemoteDescriptor. It require also=20 > to implement an ESCAPE "strip(rx)/padding(tx)" mechanism, as=20 > already required for SDP. >=20 > P.S.: I suppose NO ONE need to send the "string terminator"=20 > '\0' (0x00) in an > UTF-8 string or char. If my assertion is false, in=20 > the "solution 2)" the > %x00 should also be "escaped". Viceversa, the=20 > "solution 1)" can already > "transport" %x00 octet. >=20 > Best regards >=20 > o o o o o o o . . . ___________________________________ > o _____ || Angelo Contardi | > .][__n_n_|DD[ =3D=3D=3D=3D_____ | angelo.contardi@italtel.it = | > >(________|__|_[_________]_|________________________________| > _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o` >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 24 12:06:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlqhc-00053L-RG; Fri, 24 Jun 2005 12:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlqhb-00052i-1M for megaco@megatron.ietf.org; Fri, 24 Jun 2005 12:06:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20422 for ; Fri, 24 Jun 2005 12:06:44 -0400 (EDT) Received: from ns.italtel.it ([138.132.53.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlr68-0007fd-TT for megaco@ietf.org; Fri, 24 Jun 2005 12:32:10 -0400 Received: from ns.italtel.it (localhost [127.0.0.1]) by ns.italtel.it (8.12.11/8.12.11) with ESMTP id j5OG6Z9Y027403 for ; Fri, 24 Jun 2005 18:06:36 +0200 (MEST) Received: from ICSSW035.corp.dom (icssw035.settimo.italtel.it [138.132.90.72]) by ns.italtel.it (8.12.11/8.12.11) with ESMTP id j5OG6Yv0027397; Fri, 24 Jun 2005 18:06:34 +0200 (MEST) X-Spam-Filter: made by ns.italtel.it Received: from BESONE.corp.dom ([138.132.89.14]) by ICSSW035.corp.dom with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Jun 2005 18:06:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Date: Fri, 24 Jun 2005 18:06:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <8E6DA0ECC9F8EE4483CBF31602B1537E81D322@BESONE.corp.dom> Thread-Topic: ABNF VALUE "unsigned integer" not allowed as Packages Type. Thread-Index: AcV42jeArJ4OaN4cQjSMLIl8iDqnUQ== From: "Contardi Angelo" To: "Megaco IETF - Mail List \(E-mail\)" X-OriginalArrivalTime: 24 Jun 2005 16:06:29.0353 (UTC) FILETIME=[AE5C0D90:01C578D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: "Christian Groves \(E-mail\)" Subject: [Megaco] ABNF VALUE "unsigned integer" not allowed as Packages Type. X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello, from my previous private discussion with Christian Groves, i have = deduce this: The "General Description" of Packages allow "just" 32 or 64 bit SIGNED = "Integer" while the ABNF notation allow 32 bit UNSIGNED "Integer" too, as = described in the comment in annex B.2: ; Integer, Double, and Unsigned Integer: Decimal values can be = encoded ; using characters 0-9. Hexadecimal values must be prefixed with = '0x' ; and can use characters 0-9,a-f,A-F. An octal format is not = supported. ; Negative integers start with '-' and MUST be Decimal. The SafeChar ; form of VALUE MUST be used. >From "implementation point of view" signed and unsigned 32 bit = integer aren't the same things because of: - The signed 32 bit integer range is form -2147483648 to 2147483647, 0 = included while: - The unsigned 32 bit integer range is from 0 to 4294967295. So the maximum positive unsigned 32 bit integer is (about) 2 time the = maximum positive 32 bit signed integer (one bit is used for sign). So, in ABNF, if 32 bit unsigned integer are allowed, one can send = the VALUE corresponding to the ASCII string "4294967295", while if only 32 = bit signed integer are allowed, one can't send the string "4294967295" because = it's out of range! There are two possible solutions to this problem: 1) In a Package, as already stated in the "general description" of = packages, allow "just" SIGNED number. The case of integer number > = 2147483647 may be covered by Long type (64 bit signed integer). 2) In a Package, allow 32 bit unsigned integer TOO, as described in = above ABNF comment. This imply the modification of the "general description of = packages". Please NOTE that the 2nd solution have impact on implementation and so = should be avoided if no one really need unsigned 32 bit integer type. =20 Cordiali saluti o o o o o o o . . . ___________________________________ o _____ || Angelo Contardi | .][__n_n_|DD[ =3D=3D=3D=3D_____ | angelo.contardi@italtel.it = | >(________|__|_[_________]_|________________________________| _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o` _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 24 12:27:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlr1Q-0002Qx-5l; Fri, 24 Jun 2005 12:27:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlr1O-0002Qs-Ud for megaco@megatron.ietf.org; Fri, 24 Jun 2005 12:27:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22236 for ; Fri, 24 Jun 2005 12:27:12 -0400 (EDT) Received: from ns.italtel.it ([138.132.53.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlrPx-00006o-Ua for megaco@ietf.org; Fri, 24 Jun 2005 12:52:38 -0400 Received: from ns.italtel.it (localhost [127.0.0.1]) by ns.italtel.it (8.12.11/8.12.11) with ESMTP id j5OGR4Vl027873 for ; Fri, 24 Jun 2005 18:27:05 +0200 (MEST) Received: from ICSSW035.corp.dom (icssw035.settimo.italtel.it [138.132.90.72]) by ns.italtel.it (8.12.11/8.12.11) with ESMTP id j5OGR4ub027869 for ; Fri, 24 Jun 2005 18:27:04 +0200 (MEST) X-Spam-Filter: made by ns.italtel.it Received: from BESONE.corp.dom ([138.132.89.14]) by ICSSW035.corp.dom with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Jun 2005 18:26:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Subject: I: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Date: Fri, 24 Jun 2005 18:26:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <8E6DA0ECC9F8EE4483CBF31602B1537E81D324@BESONE.corp.dom> Thread-Topic: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Thread-Index: AcV41eNom/a9YiDwS5CurS1ihZuFAQABXoDwAABqSKA= From: "Contardi Angelo" To: "Megaco IETF - Mail List \(E-mail\)" X-OriginalArrivalTime: 24 Jun 2005 16:26:59.0314 (UTC) FILETIME=[8B793520:01C578D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 -----Messaggio originale----- Da: Contardi Angelo=20 Inviato: venerd=EC 24 giugno 2005 18.25 A: 'Steve Cipolli' Oggetto: R: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char -----Messaggio originale----- Da: Steve Cipolli [mailto:SCipolli@radvision.com] Inviato: venerd=EC 24 giugno 2005 18.01 A: Contardi Angelo; Megaco IETF - Mail List (E-mail) Cc: Christian Groves (E-mail) Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Two points: 1. It is not necessary to quote the UTF-8 characters as you define in your second solution. VALUE can be extended to accept characters (quoted and unquoted) in the range 0x80-0xFF. =20 The problem is that VALUE don't allow to "carry" ALL ASCII (0x00-0x7F) too, NEEDED to code UTF-8 characters < 0x80. So the only "extension" = 0x80-0xFF is NOT enough to allow the TX of ALL UTF-8 with ABNF. The quotation is NEEDED becaue of if you "scan" an input sequence and = allow a VALUE as "any sequence of ono or more 0x00-0xFF", all "tokens" = identified as VALUEs. The extension of quoted form of VALUE i propose don't = increment the number of the forms of VALUE, just EXEND the actual Quoted form of = VALUE 2. Providing a mechanism to allow double quotes (") in a (double) quotedstring is essentially a separate issue, since addition of UTF-8 chars does not motivate the need for this mechanism nor complicate its addition. See point 1. --Stephen > -----Original Message----- > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org] On Behalf Of Contardi Angelo > Sent: Friday, June 24, 2005 11:34 AM > To: Megaco IETF - Mail List (E-mail) > Cc: Christian Groves (E-mail) > Subject: [Megaco] The ABNF coding of VALUE doesn't allow to=20 > represent ageneric UTF-8 string/char >=20 >=20 > Hello, >=20 > from my previous private discussion with Christian Groves,=20 > i have deduce this: >=20 > The ABNF coding of VALUE doesn't allow to represent a=20 > generic UTF-8 string or char (RFC 3629) because of: >=20 > 1) The FIRST byte of an UTF-8 char may be ANY ASCII char in=20 > the range 0x00-0x7E > and, for instance, the ASCII 0x00-0x07 and 0x22 (") are=20 > not allowed in ANY > ABNF form of VALUE. > =20 > 2) Furthermore, UTF-8 chars "greater than 0x7E", need "ASCII=20 > chars" (to better > say, Octets) in the range 0x80-0xFF (not ALL), not allowed=20 > in ANY ABNF form > of VALUE. >=20 > So, to "correct" this problem, i can suggest two possible solutions: >=20 > 1) The simple one, code the UTF-8 string/char in "Octect=20 > Mode", as described in > ANNEX B.3. This is a BAD solution from the efficiency =20 > transmission point of > view because of it "halve the TX band": to TX one UTF-8 =20 > char (max 4 Octet) > i must TX max 2 x 4 =3D 8 Octet (ASCII chars). >=20 > 2) The difficult one, allow the ABNF quoted form of VALUE to =20 > TX ALL ASCII chars > 0x01-0xFF (the range 0x80-0xFF are more properly named =20 > OCTET in RFC2234 ), > except 0x22 ("), that should be ESCAPED with "\", as =20 > already done for ABNF > Local and Remote Descriptor (see SDP). Note that '\0'=20 > (0x00) is NOT ALLOWED > in this new quoted string form as in the present one, but=20 > it's not a problem > because in UTF-8 the char '\0' (0x00) is same as in ASCII=20 > (string terminator) > and is NOT used to code "non ASCII" UTF-8 chars, all=20 > those chars > 0x7F that > require more than one ASCII chars to be encoded (from 2 to=20 > 4 ASCII chars). In > fact the "extra chars" needed to code an UTF-8 char are=20 > all above 0x7F. >=20 > While the 1st mode doesn't require any modification of=20 > ABNF syntax (but is it applicable in any case ?), the 2nd one=20 > require this ABNF modification: >=20 > quotedString =3D DQUOTE *(quotedChar) DQUOTE > =09 > ; %x22 (") is allowed just if "escaped" with "\" > quotedChar =3D ( %x01-21 / "\" DQUOTE / %x23-FF ) >=20 > In a parser implementation, i think, this is not a =20 > "terrible complication" and can be solved in the same way of=20 > "octetString" of Local and RemoteDescriptor. It require also=20 > to implement an ESCAPE "strip(rx)/padding(tx)" mechanism, as=20 > already required for SDP. >=20 > P.S.: I suppose NO ONE need to send the "string terminator"=20 > '\0' (0x00) in an > UTF-8 string or char. If my assertion is false, in=20 > the "solution 2)" the > %x00 should also be "escaped". Viceversa, the=20 > "solution 1)" can already > "transport" %x00 octet. >=20 > Best regards >=20 > o o o o o o o . . . ___________________________________ > o _____ || Angelo Contardi | > .][__n_n_|DD[ =3D=3D=3D=3D_____ | angelo.contardi@italtel.it = | > >(________|__|_[_________]_|________________________________| > _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o` >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 24 15:11:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DltaJ-0006ZI-8w; Fri, 24 Jun 2005 15:11:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DltaI-0006ZD-Cr for megaco@megatron.ietf.org; Fri, 24 Jun 2005 15:11:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05091 for ; Fri, 24 Jun 2005 15:11:24 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dltyq-0006XZ-KV for megaco@ietf.org; Fri, 24 Jun 2005 15:36:51 -0400 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Date: Fri, 24 Jun 2005 15:11:15 -0400 Message-ID: Thread-Topic: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Thread-Index: AcV41eNom/a9YiDwS5CurS1ihZuFAQABXoDwAABT3vA= From: "Steve Cipolli" To: "Contardi Angelo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: quoted-printable Cc: Sasha Ruditsky , Christian Groves , itu-sg16@external.cisco.com, 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 Angelo, Today all ASCII characters except double quotes can be specified by the = VALUE production (some of the characters need to be in the quotedstring = form). Adding UTF-8 does not change this. The part of UTF-8 that is < = 0x80 is exactly ASCII and does not change or need to change the way in = which VALUE is encoded. =20 UTF-8 characters above 0x7F are encoded as multiple bytes in which each = byte of the character is guaranteed to be > 0x7F. So UTF-8 characters = are either < 0x80 and are simply the equivalent of ASCII or they are = encoded into multiple bytes in which every byte of the character is > = 0x7F. There will never be a circumstance where a byte of a UTF-8 = multibyte character collides with _any_ ASCII character. Perhaps the table below will help clarify Scalar Value 1st Byte 2nd Byte 3rd Byte 4th Byte 00000000 0xxxxxxx 0xxxxxxx 00000yyy yyxxxxxx 110yyyyy 10xxxxxx zzzzyyyy yyxxxxxx 1110zzzz 10yyyyyy 10xxxxxx 000uuuuu zzzzyyyy yyxxxxxx 11110uuu 10uuzzzz 10yyyyyy 10xxxxxx Notice that "one byte" UTF-8 characters have their high order bit = cleared (0) and that all bytes of all multi-byte UTF-8 encodings have = the high-order bit set (1). In other words all multi-byte character's = bytes are > 0x7F. So changing the productions to: VALUE =3D quotedString / 1*(SafeChar / %x80-F7) quotedString =3D DQUOTE *(SafeChar / %x80-F7 / RestChar / WSP) = DQUOTE as Sasha Ruditsky suggests will allow UTF-8 characters to be used in = VALUEs. ASCII characters (and UTF-8 equvialents < 0x80) that are in the = RestChar set will need to be quoted just as they have always been. = UTF-8 characters above 0x7F may or may not be quoted, just as all the = ASCII characters in the SafeChar set. --Stephen =09 > -----Original Message----- > From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it]=20 > Sent: Friday, June 24, 2005 12:25 PM > To: Steve Cipolli > Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow=20 > to represent ageneric UTF-8 string/char >=20 >=20 >=20 >=20 > -----Messaggio originale----- > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > Inviato: venerd=EC 24 giugno 2005 18.01 > A: Contardi Angelo; Megaco IETF - Mail List (E-mail) > Cc: Christian Groves (E-mail) > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow=20 > to represent ageneric UTF-8 string/char >=20 >=20 >=20 > Two points: >=20 > 1. It is not necessary to quote the UTF-8 characters as you=20 > define in your second solution. VALUE can be extended to=20 > accept characters (quoted and unquoted) in the range 0x80-0xFF. =20 >=20 > The problem is that VALUE don't allow to "carry" ALL ASCII=20 > (0x00-0x7F) too, NEEDED to code UTF-8 characters < 0x80. So=20 > the only "extension" 0x80-0xFF is NOT enough to allow the TX=20 > of ALL UTF-8 with ABNF. The quotation is NEEDED becaue of if=20 > you "scan" an input sequence and allow a VALUE as "any=20 > sequence of ono or more 0x00-0xFF", all "tokens" identified=20 > as VALUEs. The extension of quoted form of VALUE i propose=20 > don't increment the number of the forms of VALUE, just EXEND=20 > the actual Quoted form of VALUE >=20 > 2. Providing a mechanism to allow double quotes (") in a=20 > (double) quotedstring is essentially a separate issue, since=20 > addition of UTF-8 chars does not motivate the need for this=20 > mechanism nor complicate its addition. >=20 > See point 1. >=20 > --Stephen >=20 > > -----Original Message----- > > From: megaco-bounces@ietf.org > > [mailto:megaco-bounces@ietf.org] On Behalf Of Contardi Angelo > > Sent: Friday, June 24, 2005 11:34 AM > > To: Megaco IETF - Mail List (E-mail) > > Cc: Christian Groves (E-mail) > > Subject: [Megaco] The ABNF coding of VALUE doesn't allow to=20 > > represent ageneric UTF-8 string/char > >=20 > >=20 > > Hello, > >=20 > > from my previous private discussion with Christian Groves, > > i have deduce this: > >=20 > > The ABNF coding of VALUE doesn't allow to represent a > > generic UTF-8 string or char (RFC 3629) because of: > >=20 > > 1) The FIRST byte of an UTF-8 char may be ANY ASCII char in > > the range 0x00-0x7E > > and, for instance, the ASCII 0x00-0x07 and 0x22 (") are=20 > > not allowed in ANY > > ABNF form of VALUE. > > =20 > > 2) Furthermore, UTF-8 chars "greater than 0x7E", need "ASCII > > chars" (to better > > say, Octets) in the range 0x80-0xFF (not ALL), not allowed=20 > > in ANY ABNF form > > of VALUE. > >=20 > > So, to "correct" this problem, i can suggest two possible solutions: > >=20 > > 1) The simple one, code the UTF-8 string/char in "Octect > > Mode", as described in > > ANNEX B.3. This is a BAD solution from the efficiency =20 > > transmission point of > > view because of it "halve the TX band": to TX one UTF-8 =20 > > char (max 4 Octet) > > i must TX max 2 x 4 =3D 8 Octet (ASCII chars). > >=20 > > 2) The difficult one, allow the ABNF quoted form of VALUE to > > TX ALL ASCII chars > > 0x01-0xFF (the range 0x80-0xFF are more properly named =20 > > OCTET in RFC2234 ), > > except 0x22 ("), that should be ESCAPED with "\", as =20 > > already done for ABNF > > Local and Remote Descriptor (see SDP). Note that '\0'=20 > > (0x00) is NOT ALLOWED > > in this new quoted string form as in the present one, but=20 > > it's not a problem > > because in UTF-8 the char '\0' (0x00) is same as in ASCII=20 > > (string terminator) > > and is NOT used to code "non ASCII" UTF-8 chars, all=20 > > those chars > 0x7F that > > require more than one ASCII chars to be encoded (from 2 to=20 > > 4 ASCII chars). In > > fact the "extra chars" needed to code an UTF-8 char are=20 > > all above 0x7F. > >=20 > > While the 1st mode doesn't require any modification of > > ABNF syntax (but is it applicable in any case ?), the 2nd one=20 > > require this ABNF modification: > >=20 > > quotedString =3D DQUOTE *(quotedChar) DQUOTE > > =09 > > ; %x22 (") is allowed just if "escaped" with "\" > > quotedChar =3D ( %x01-21 / "\" DQUOTE / %x23-FF ) > >=20 > > In a parser implementation, i think, this is not a > > "terrible complication" and can be solved in the same way of=20 > > "octetString" of Local and RemoteDescriptor. It require also=20 > > to implement an ESCAPE "strip(rx)/padding(tx)" mechanism, as=20 > > already required for SDP. > >=20 > > P.S.: I suppose NO ONE need to send the "string terminator" > > '\0' (0x00) in an > > UTF-8 string or char. If my assertion is false, in=20 > > the "solution 2)" the > > %x00 should also be "escaped". Viceversa, the=20 > > "solution 1)" can already > > "transport" %x00 octet. > >=20 > > Best regards > >=20 > > o o o o o o o . . . ___________________________________ > > o _____ || Angelo Contardi | > > .][__n_n_|DD[ =3D=3D=3D=3D_____ | = angelo.contardi@italtel.it | > > >(________|__|_[_________]_|________________________________| > > _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o` > >=20 > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Sun Jun 26 20:50:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmhph-00034J-7i; Sun, 26 Jun 2005 20:50:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmhpg-00034E-JR for megaco@megatron.ietf.org; Sun, 26 Jun 2005 20:50:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29406 for ; Sun, 26 Jun 2005 20:50:38 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmiEi-0002pG-Ti for megaco@ietf.org; Sun, 26 Jun 2005 21:16:33 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BA363C4E; Mon, 27 Jun 2005 02:50:27 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 02:50:27 +0200 Received: from [146.11.22.102] ([146.11.22.102]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 02:50:25 +0200 Message-ID: <42BF4D4D.3060204@ericsson.com> Date: Mon, 27 Jun 2005 10:50:21 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Frank Reno Subject: Re: [Megaco] Topology Questions References: <20050624152126.97134.qmail@web61315.mail.yahoo.com> In-Reply-To: <20050624152126.97134.qmail@web61315.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2005 00:50:25.0876 (UTC) FILETIME=[34D04940:01C57AB2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 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 Hello Frank, Please see my replies below. Regards, Christian Frank Reno wrote: > Thanks for the reply. Did you mean "For version 1 the > return to the audit should be bothway"? [CHG] Yes I meant version 1...seems to be a disconnect between the brain and the fingers lately :). So can we say > that if flow exists in a given direction for any > stream, then flow is reported for that direction at > the termination level? For example > > t1, t2, oneway, stream=1 > t2, t1, oneway, stream=2 > > is reported in version 1 as > > t1, t2, bothway [CHG] Yes. If the example was t1,t2,oneway, stream=1 t1,t2,oneway, stream=2 it will be reported as t1,t2,oneway. > > > Here's another one... > > 7. Section 7.1.18 states that "It is possible to have > an action containing only a Topology descriptor". In > the text encoding, what should the response be to such > an action? The ABNF requires something in the > actionReply - at least one context property, command > reply or error descriptor. [CHG] Another ABNF quirk to fix in v3. I would say that for v1 and v2 you should echo back what was sent. If CHOOSE $ was indicated you should send back the chosen terminationId. In terms of a fix to be equivalent with the ASN.1 you probably want to make the command reply optional ie. actionReply = CtxToken EQUAL ContextID LBRKT [ (errorDescriptor / commandReply /(commandReply COMMA errorDescriptor)) ] RBRKT > > > > > --- Christian Groves > wrote: > > >>Hello Frank, >> >>Version 1 does not allow topology per stream at >>least by setting the topology >>descriptor or by audit. This was only added in >>Version 2. The problem you >>highlight was one of the reasons for adding streams >>in v2. >> >>For version 2 the return to the audit should be >>bothway because the terminations >>are bothway connected. (Remember v1 has no concept >>of streams for topology). >> >>Please see my responses below. >> >>Regards, Christian >> >>Frank Reno wrote: >> >> >>>Hello, >>> >>>Any more thoughts on my question 2 below? Version >> >>1 of >> >>>the protocol apparently allows per stream topology >> >>to >> >>>exist, but there doesn't seem to be a way to >> >>report it >> >>>in a topology audit. >>> >>>Given >>> >>>Transaction = 1 >>>{ >>> Context = 1 >>> { >>> Topology {t1, t2, oneway}, >>> Add = t1 {Media {Stream = 1{...}}}, >>> Add = t2 {Media {Stream = 1{...}}} >>> } >>>} >>>Transaction = 2 >>>{ >>> Context = 1 >>> { >>> Modify = t1 {Media {Stream = 2{...}}}, >>> Modify = t2 {Media {Stream = 2{...}}} >>> } >>>} >>>Transaction = 3 >>>{ >>> Context = 1 >>> { >>> ContextAudit{Topology} >>> } >>>} >>> >>>In version 2, the reply to transaction 3 would >> >>look >> >>>like >>> >>>Reply = 3 >>>{ >>> Context = 1 >>> { >>> Topology >>> { >>> t1, t2, Oneway, Stream=1, >>> t1, t2, Bothway, Stream=2 >>> } >>> } >>>} >>> >>>How should a version 1 MG reply? >>> >>>- Same as version 2 (would need the IG to allow >> >>stream >> >>>IDs in the reply) >>>- Some error code >>>- Multiple triples for the same pair of >> >>terminations >> >>>("t1, t2, Oneway, t1, t2, Bothway") >>>- One triple per pair, merging the modes somehow >> >>("t1, >> >>>t2, Bothway") >>> >>> >>>Some more questions on the topology audit... >>> >>>4. How should the MG reply to a topology audit >> >>when >> >>>there is only one termination in the context? In >> >>the >> >>>text encoding, it is impossible to encode an empty >>>topology descriptor. Can we change the grammar to >>>allow this, or should the MG use some dummy triple >>>such as "t1, t1, bothway" or "*, *, bothway"? >> >>[CHG] If a context contains a termination I'm not >>sure an empty descriptor is >>best. A triple to indicate may be better e.g. >>t1,*,isolate. Its the topology you >>would use to isolate a single termination which >>effectively is what a >>termination in a context by itself is. I don't think >>*,*,bothway is appropriate >>as it doesn't even return the name of the one >>termination. >> >> >>>5. What topology association should be reported >> >>for >> >>>terminations that are in the same context but do >> >>not >> >>>share any streams with the same streamID? Should >> >>it be >> >>>oneway or bothway or should no association be >>>reported? No association seems best to me, but we >>>would need to allow the empty topology descriptor >> >>(in >> >>>case there are no other associations to report). >> >>[CHG] If the termination has no association with any >>other report >>[T1,*,isolate]. This would be the triple that sets >>the associated. >> >> >>>6. It looks like the Topology Descriptor is being >>>moved inside the contextAttrDescriptor in the >> >>version >> >>>3 ABNF. Won't this break compatibility? >> >>[CHG] The coding on the line shouldn't change. So >>you are correct this shouldn't >>be moved. Kevin can you fix this in your editing >>updates? >> >> >>>Regards, >>>Frank >>> >>>--- Frank Reno wrote: >>> >>>Thanks for the reply, Kevin. >>> >>>2. Your rule seems to make good sense for version >> >>2. >> >>>Does this mean, however, that a version 1 MG >> >>should >> >>>support per-stream topology even though the MGC >> >>cannot >> >>>control it directly? >>> >>>For my example, I'm assuming that you mean that >> >>the >> >>>topology regarding stream 1 is unchanged by the >>>addition of stream 2, regardless of protocol >> >>version. >> >>>This would leave stream 1 oneway and stream 2 >>>bothways. A version 1 MG would have no way to >> >>describe >> >>>this in a topology audit. >>> >>>Thanks >>> >>>--- Kevin Boyle wrote: >>> >>> >>> >>>>1. Only those currently in the context. In your >>>>example, flow is bothway >>>>between a/2 and b/1. >>>>2. Only to existing streams. In your example, flow >>>>on stream 2 is bothway. >>>>The answer is the same in all version of the >>>>protocol. >>>>3. The correct response is the one that lists all >>>>the associations, though I >>>>can see the utility of the one immediately below >>>>that which uses wildcards >>>>to reduce the message size. >>>> >>>>Kevin >>>> >>>>-----Original Message----- >>>>From: megaco-bounces at ietf.org >>>>[mailto:megaco-bounces at ietf.org] On Behalf Of >>>>Frank Reno >>>>Sent: Thursday, June 02, 2005 5:16 PM >>>>To: megaco at ietf.org >>>>Subject: [Megaco] Topology Questions >>>> >>>>Hello List, >>>> >>>>1. Does a topology association with wildcarded >>>>termination IDs apply to >>>>terminations added to the context in the future or >>>>only to those currently >>>>in the context? >>>> >>>> Transaction = 1 >> > === message truncated === > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Jun 27 05:00:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmpTx-0007mR-Ti; Mon, 27 Jun 2005 05:00:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmpTv-0007mM-Np for megaco@megatron.ietf.org; Mon, 27 Jun 2005 05:00:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26607 for ; Mon, 27 Jun 2005 05:00:40 -0400 (EDT) Received: from [62.90.58.229] (helo=tparelay.telradnetworks.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmpsp-0006aP-0J for megaco@ietf.org; Mon, 27 Jun 2005 05:26:40 -0400 Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j5R8u11u003380 for ; Mon, 27 Jun 2005 11:56:01 +0300 (IDT) Received: from mail3.telradnetworks.co.il ([141.226.76.66]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j5R8u1qC003374 for ; Mon, 27 Jun 2005 11:56:01 +0300 (IDT) Received: by mail3.telrad.co.il with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Jun 2005 12:02:40 +0300 Message-ID: <7388365BE5E4D411A3810002A509155804866983@mail3.telrad.co.il> From: Michael Putter To: "'megaco@ietf.org'" Date: Mon, 27 Jun 2005 12:02:32 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="windows-1255" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Megaco] Digit Map Completion event without digits? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello, In "7.1.14.5 DigitMap procedures" there is the following piece in the item 5): "If exactly one candidate remains and it has been fully matched, a completion event is generated indicating an unambiguous match. If no candidates remain, the latest event is removed from the current dial string and a completion event is generated indicating full match if one of the candidates from the previous step was fully satisfied before the latest event was detected, or partial match otherwise." What happens if the 1st dialed digit does not satisfy any candidate? Is completion event is generated with partial match and without digits? Thanks, Michael. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Jun 27 05:54:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmqJw-0006rS-Rh; Mon, 27 Jun 2005 05:54:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmqJv-0006rH-DT for megaco@megatron.ietf.org; Mon, 27 Jun 2005 05:54:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00732 for ; Mon, 27 Jun 2005 05:54:24 -0400 (EDT) Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmqiv-0008Kh-QP for megaco@ietf.org; Mon, 27 Jun 2005 06:20:25 -0400 Received: from spark.hss.co.in (localhost [127.0.0.1]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j5R9nOZN001528 for ; Mon, 27 Jun 2005 15:19:24 +0530 (IST) Received: from webmail.hss.hns.com (webmail.hss.hns.com [10.203.158.17]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j5R9nD4f001461; Mon, 27 Jun 2005 15:19:24 +0530 (IST) In-Reply-To: <7388365BE5E4D411A3810002A509155804866983@mail3.telrad.co.il> Subject: Re: [Megaco] Digit Map Completion event without digits? To: Michael Putter X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "B Venkat S.R Swamy" Date: Mon, 27 Jun 2005 15:30:36 +0530 X-MIMETrack: Serialize by Router on WebMail/HSS(Release 6.5.1|January 21, 2004) at 06/27/2005 03:17:54 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 3.1 (+++) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 Yes, you are right, Notify for digit completion will be generated with Method as PartialMatch and without any digits. regards B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.flextronicssoftware.com Michael Putter To Sent by: "'megaco@ietf.org'" megaco-bounces@ie tf.org cc Subject 06/27/2005 02:32 [Megaco] Digit Map Completion event PM without digits? Hello, In "7.1.14.5 DigitMap procedures" there is the following piece in the item 5): "If exactly one candidate remains and it has been fully matched, a completion event is generated indicating an unambiguous match. If no candidates remain, the latest event is removed from the current dial string and a completion event is generated indicating full match if one of the candidates from the previous step was fully satisfied before the latest event was detected, or partial match otherwise." What happens if the 1st dialed digit does not satisfy any candidate? Is completion event is generated with partial match and without digits? Thanks, Michael. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco *********************** FSS-Restricted *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Jun 27 05:59:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmqPE-0007Ru-G3; Mon, 27 Jun 2005 05:59:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmqPD-0007Qe-16 for megaco@megatron.ietf.org; Mon, 27 Jun 2005 05:59:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01267 for ; Mon, 27 Jun 2005 05:59:52 -0400 (EDT) Received: from mercurio.italtel.it ([138.132.53.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmqoK-0008V0-04 for megaco@ietf.org; Mon, 27 Jun 2005 06:25:53 -0400 Received: from mercurio.italtel.it (localhost [127.0.0.1]) by mercurio.italtel.it (8.12.11/8.12.11) with ESMTP id j5R9xU57028826 for ; Mon, 27 Jun 2005 11:59:31 +0200 (MEST) Received: from ICSSW035.corp.dom (icssw035.settimo.italtel.it [138.132.90.72]) by mercurio.italtel.it (8.12.11/8.12.11) with ESMTP id j5R9xPHn028804; Mon, 27 Jun 2005 11:59:26 +0200 (MEST) X-Spam-Filter: made by mercurio.italtel.it Received: from BESONE.corp.dom ([138.132.89.14]) by ICSSW035.corp.dom with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 11:59:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Date: Mon, 27 Jun 2005 11:59:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <8E6DA0ECC9F8EE4483CBF31602B1537E81D325@BESONE.corp.dom> Thread-Topic: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Thread-Index: AcV48IIZVMaJF4lEQsyG4IrmRqfc3QCDTCGw From: "Contardi Angelo" To: "Steve Cipolli" , "Megaco IETF - Mail List \(E-mail\)" X-OriginalArrivalTime: 27 Jun 2005 09:59:25.0755 (UTC) FILETIME=[E682F0B0:01C57AFE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: quoted-printable Cc: "Christian Groves \(E-mail\)" 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 He Steve, i don't understand these points: 1) Where are included non printing chars from 0x01-0x31 and 0x127 in = VALUE? Note that the "general definition of packages" (pargraphs 12.x.x of H.248.1) allow those = chars too. Otherwise it should be stated somewhere the opposite. 2) Why %x80-F7 should be included in both "quoted" and "non quoted" = form of value. Isn't it enought to include them just in quoted form of VALUE ? =20 3) How to TX 0x22 (")? It's a NEED, not an optional to tx 0x22 too, = because of, for instance, the package "Text telephone package", described in the specification = H.248.2, need to tx ANY UTF-8 string, 0x22 included. I tink this package is used to tx a text = writed by users and so it may include 0x22 too. And actually 0x22 can't be tx in ANY VALUE = form. So how do you solve this problem?=20 -----Messaggio originale----- Da: Steve Cipolli [mailto:SCipolli@radvision.com] Inviato: venerd=EC 24 giugno 2005 21.11 A: Contardi Angelo Cc: Sasha Ruditsky; Christian Groves; itu-sg16@external.cisco.com; megaco@ietf.org Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Angelo, Today all ASCII characters except double quotes can be specified by the = VALUE production (some of the characters need to be in the quotedstring = form). Adding UTF-8 does not change this. The part of UTF-8 that is < = 0x80 is exactly ASCII and does not change or need to change the way in = which VALUE is encoded. =20 UTF-8 characters above 0x7F are encoded as multiple bytes in which each = byte of the character is guaranteed to be > 0x7F. So UTF-8 characters = are either < 0x80 and are simply the equivalent of ASCII or they are = encoded into multiple bytes in which every byte of the character is > = 0x7F. There will never be a circumstance where a byte of a UTF-8 = multibyte character collides with _any_ ASCII character. Perhaps the table below will help clarify Scalar Value 1st Byte 2nd Byte 3rd Byte 4th Byte 00000000 0xxxxxxx 0xxxxxxx 00000yyy yyxxxxxx 110yyyyy 10xxxxxx zzzzyyyy yyxxxxxx 1110zzzz 10yyyyyy 10xxxxxx 000uuuuu zzzzyyyy yyxxxxxx 11110uuu 10uuzzzz 10yyyyyy 10xxxxxx Notice that "one byte" UTF-8 characters have their high order bit = cleared (0) and that all bytes of all multi-byte UTF-8 encodings have = the high-order bit set (1). In other words all multi-byte character's = bytes are > 0x7F. So changing the productions to: VALUE =3D quotedString / 1*(SafeChar / %x80-F7) quotedString =3D DQUOTE *(SafeChar / %x80-F7 / RestChar / WSP) = DQUOTE as Sasha Ruditsky suggests will allow UTF-8 characters to be used in = VALUEs. ASCII characters (and UTF-8 equvialents < 0x80) that are in the = RestChar set will need to be quoted just as they have always been. = UTF-8 characters above 0x7F may or may not be quoted, just as all the = ASCII characters in the SafeChar set. --Stephen =09 > -----Original Message----- > From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it]=20 > Sent: Friday, June 24, 2005 12:25 PM > To: Steve Cipolli > Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow=20 > to represent ageneric UTF-8 string/char >=20 >=20 >=20 >=20 > -----Messaggio originale----- > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > Inviato: venerd=EC 24 giugno 2005 18.01 > A: Contardi Angelo; Megaco IETF - Mail List (E-mail) > Cc: Christian Groves (E-mail) > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow=20 > to represent ageneric UTF-8 string/char >=20 >=20 >=20 > Two points: >=20 > 1. It is not necessary to quote the UTF-8 characters as you=20 > define in your second solution. VALUE can be extended to=20 > accept characters (quoted and unquoted) in the range 0x80-0xFF. =20 >=20 > The problem is that VALUE don't allow to "carry" ALL ASCII=20 > (0x00-0x7F) too, NEEDED to code UTF-8 characters < 0x80. So=20 > the only "extension" 0x80-0xFF is NOT enough to allow the TX=20 > of ALL UTF-8 with ABNF. The quotation is NEEDED becaue of if=20 > you "scan" an input sequence and allow a VALUE as "any=20 > sequence of ono or more 0x00-0xFF", all "tokens" identified=20 > as VALUEs. The extension of quoted form of VALUE i propose=20 > don't increment the number of the forms of VALUE, just EXEND=20 > the actual Quoted form of VALUE >=20 > 2. Providing a mechanism to allow double quotes (") in a=20 > (double) quotedstring is essentially a separate issue, since=20 > addition of UTF-8 chars does not motivate the need for this=20 > mechanism nor complicate its addition. >=20 > See point 1. >=20 > --Stephen >=20 > > -----Original Message----- > > From: megaco-bounces@ietf.org > > [mailto:megaco-bounces@ietf.org] On Behalf Of Contardi Angelo > > Sent: Friday, June 24, 2005 11:34 AM > > To: Megaco IETF - Mail List (E-mail) > > Cc: Christian Groves (E-mail) > > Subject: [Megaco] The ABNF coding of VALUE doesn't allow to=20 > > represent ageneric UTF-8 string/char > >=20 > >=20 > > Hello, > >=20 > > from my previous private discussion with Christian Groves, > > i have deduce this: > >=20 > > The ABNF coding of VALUE doesn't allow to represent a > > generic UTF-8 string or char (RFC 3629) because of: > >=20 > > 1) The FIRST byte of an UTF-8 char may be ANY ASCII char in > > the range 0x00-0x7E > > and, for instance, the ASCII 0x00-0x07 and 0x22 (") are=20 > > not allowed in ANY > > ABNF form of VALUE. > > =20 > > 2) Furthermore, UTF-8 chars "greater than 0x7E", need "ASCII > > chars" (to better > > say, Octets) in the range 0x80-0xFF (not ALL), not allowed=20 > > in ANY ABNF form > > of VALUE. > >=20 > > So, to "correct" this problem, i can suggest two possible solutions: > >=20 > > 1) The simple one, code the UTF-8 string/char in "Octect > > Mode", as described in > > ANNEX B.3. This is a BAD solution from the efficiency =20 > > transmission point of > > view because of it "halve the TX band": to TX one UTF-8 =20 > > char (max 4 Octet) > > i must TX max 2 x 4 =3D 8 Octet (ASCII chars). > >=20 > > 2) The difficult one, allow the ABNF quoted form of VALUE to > > TX ALL ASCII chars > > 0x01-0xFF (the range 0x80-0xFF are more properly named =20 > > OCTET in RFC2234 ), > > except 0x22 ("), that should be ESCAPED with "\", as =20 > > already done for ABNF > > Local and Remote Descriptor (see SDP). Note that '\0'=20 > > (0x00) is NOT ALLOWED > > in this new quoted string form as in the present one, but=20 > > it's not a problem > > because in UTF-8 the char '\0' (0x00) is same as in ASCII=20 > > (string terminator) > > and is NOT used to code "non ASCII" UTF-8 chars, all=20 > > those chars > 0x7F that > > require more than one ASCII chars to be encoded (from 2 to=20 > > 4 ASCII chars). In > > fact the "extra chars" needed to code an UTF-8 char are=20 > > all above 0x7F. > >=20 > > While the 1st mode doesn't require any modification of > > ABNF syntax (but is it applicable in any case ?), the 2nd one=20 > > require this ABNF modification: > >=20 > > quotedString =3D DQUOTE *(quotedChar) DQUOTE > > =09 > > ; %x22 (") is allowed just if "escaped" with "\" > > quotedChar =3D ( %x01-21 / "\" DQUOTE / %x23-FF ) > >=20 > > In a parser implementation, i think, this is not a > > "terrible complication" and can be solved in the same way of=20 > > "octetString" of Local and RemoteDescriptor. It require also=20 > > to implement an ESCAPE "strip(rx)/padding(tx)" mechanism, as=20 > > already required for SDP. > >=20 > > P.S.: I suppose NO ONE need to send the "string terminator" > > '\0' (0x00) in an > > UTF-8 string or char. If my assertion is false, in=20 > > the "solution 2)" the > > %x00 should also be "escaped". Viceversa, the=20 > > "solution 1)" can already > > "transport" %x00 octet. > >=20 > > Best regards > >=20 > > o o o o o o o . . . ___________________________________ > > o _____ || Angelo Contardi | > > .][__n_n_|DD[ =3D=3D=3D=3D_____ | = angelo.contardi@italtel.it | > > >(________|__|_[_________]_|________________________________| > > _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o` > >=20 > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Jun 27 09:03:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmtGc-0004vP-VI; Mon, 27 Jun 2005 09:03:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmtGX-0004vK-Vj for megaco@megatron.ietf.org; Mon, 27 Jun 2005 09:03:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17887 for ; Mon, 27 Jun 2005 09:03:07 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmtfe-0005is-1u for megaco@ietf.org; Mon, 27 Jun 2005 09:29:09 -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 j5RD2RP06993; Mon, 27 Jun 2005 09:02:28 -0400 (EDT) Received: from [127.0.0.1] (acart210.ca.nortel.com [47.130.17.79]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MRAFPRYN; Mon, 27 Jun 2005 09:02:13 -0400 Message-ID: <42BFF8D0.8080900@nortel.com> Date: Mon, 27 Jun 2005 09:02:08 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Contardi Angelo Subject: Re: R: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char References: <8E6DA0ECC9F8EE4483CBF31602B1537E81D325@BESONE.corp.dom> In-Reply-To: <8E6DA0ECC9F8EE4483CBF31602B1537E81D325@BESONE.corp.dom> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04f.nortelnetworks.com id j5RD2RP06993 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: Steve Cipolli , "Megaco IETF - Mail List \(E-mail\)" , "Christian Groves \(E-mail\)" 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 dealt with the issue of non-printable characters when putting together=20 the Advance Audio Server packages (H.248.9). Please see clause=20 6.2.5.1.2/H.248.9 for a discussion of the matter. Contardi Angelo wrote: > He Steve, >=20 > i don't understand these points: >=20 > 1) Where are included non printing chars from 0x01-0x31 and 0x127 in VA= LUE? Note that the "general > definition of packages" (pargraphs 12.x.x of H.248.1) allow those ch= ars too. Otherwise it should > be stated somewhere the opposite. >=20 > 2) Why %x80-F7 should be included in both "quoted" and "non quoted" fo= rm of value. Isn't it enought > to include them just in quoted form of VALUE ? =20 >=20 > 3) How to TX 0x22 (")? It's a NEED, not an optional to tx 0x22 too, bec= ause of, for instance, > the package "Text telephone package", described in the specification= H.248.2, need to tx ANY > UTF-8 string, 0x22 included. I tink this package is used to tx a tex= t writed by users and so > it may include 0x22 too. And actually 0x22 can't be tx in ANY VALUE = form. So how do you > solve this problem?=20 >=20 > -----Messaggio originale----- > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > Inviato: venerd=EC 24 giugno 2005 21.11 > A: Contardi Angelo > Cc: Sasha Ruditsky; Christian Groves; itu-sg16@external.cisco.com; > megaco@ietf.org > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow to > represent ageneric UTF-8 string/char >=20 >=20 > Angelo, >=20 > Today all ASCII characters except double quotes can be specified by the= VALUE production (some of the characters need to be in the quotedstring = form). Adding UTF-8 does not change this. The part of UTF-8 that is < 0= x80 is exactly ASCII and does not change or need to change the way in whi= ch VALUE is encoded. =20 >=20 > UTF-8 characters above 0x7F are encoded as multiple bytes in which each= byte of the character is guaranteed to be > 0x7F. So UTF-8 characters a= re either < 0x80 and are simply the equivalent of ASCII or they are encod= ed into multiple bytes in which every byte of the character is > 0x7F. T= here will never be a circumstance where a byte of a UTF-8 multibyte chara= cter collides with _any_ ASCII character. >=20 > Perhaps the table below will help clarify >=20 > Scalar Value 1st Byte 2nd Byte 3rd Byte 4th Byte > 00000000 0xxxxxxx 0xxxxxxx > 00000yyy yyxxxxxx 110yyyyy 10xxxxxx > zzzzyyyy yyxxxxxx 1110zzzz 10yyyyyy 10xxxxxx > 000uuuuu zzzzyyyy yyxxxxxx 11110uuu 10uuzzzz 10yyyyyy 10xxxxxx >=20 > Notice that "one byte" UTF-8 characters have their high order bit clear= ed (0) and that all bytes of all multi-byte UTF-8 encodings have the high= -order bit set (1). In other words all multi-byte character's bytes are = > 0x7F. >=20 > So changing the productions to: > VALUE =3D quotedString / 1*(SafeChar / %x80-F7) > quotedString =3D DQUOTE *(SafeChar / %x80-F7 / RestChar / WSP= ) DQUOTE >=20 > as Sasha Ruditsky suggests will allow UTF-8 characters to be used in VA= LUEs. ASCII characters (and UTF-8 equvialents < 0x80) that are in the Re= stChar set will need to be quoted just as they have always been. UTF-8 c= haracters above 0x7F may or may not be quoted, just as all the ASCII char= acters in the SafeChar set. >=20 > --Stephen > =09 >=20 >=20 >>-----Original Message----- >>From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it]=20 >>Sent: Friday, June 24, 2005 12:25 PM >>To: Steve Cipolli >>Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow=20 >>to represent ageneric UTF-8 string/char >> >> >> ... _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Jun 27 11:29:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvYE-0002WW-G8; Mon, 27 Jun 2005 11:29:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvYA-0002WO-UZ for megaco@megatron.ietf.org; Mon, 27 Jun 2005 11:29:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03285 for ; Mon, 27 Jun 2005 11:29:28 -0400 (EDT) Received: from ns.italtel.it ([138.132.53.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmvxK-0007um-FN for megaco@ietf.org; Mon, 27 Jun 2005 11:55:32 -0400 Received: from ns.italtel.it (localhost [127.0.0.1]) by ns.italtel.it (8.12.11/8.12.11) with ESMTP id j5RFTIB6021601 for ; Mon, 27 Jun 2005 17:29:19 +0200 (MEST) Received: from ICSSW035.corp.dom (icssw035.settimo.italtel.it [138.132.90.72]) by ns.italtel.it (8.12.11/8.12.11) with ESMTP id j5RFTG3L021589; Mon, 27 Jun 2005 17:29:18 +0200 (MEST) X-Spam-Filter: made by ns.italtel.it Received: from BESONE.corp.dom ([138.132.89.14]) by ICSSW035.corp.dom with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 17:29:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Subject: R: R: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Date: Mon, 27 Jun 2005 17:29:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <8E6DA0ECC9F8EE4483CBF31602B1537E81D327@BESONE.corp.dom> Thread-Topic: R: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Thread-Index: AcV7GIM1bTlbGH7aQ1WAKYWnuekKiwAEed8w From: "Contardi Angelo" To: "Tom Taylor" , "Megaco IETF - Mail List \(E-mail\)" X-OriginalArrivalTime: 27 Jun 2005 15:29:13.0365 (UTC) FILETIME=[F8D89C50:01C57B2C] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable Cc: "Christian Groves \(E-mail\)" 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 Tom, your solution is interesting as a "work-around" to avoid the constrains = of actual ABNF but i think the discussion here is focused on "how to EXTEND the actual = ABNF syntax" to allow ANY UTF-8 string/char and use this extension in the incoming = H.248.1 V3, not how to carry with the actual syntax a special "message format" that = include ANY ABNF syntax. If i'm not wrong, H.248.9 use a structured message to carry ANY (?) UTF-8 string/char, whith some "TAGs" to mark UTF-8 chars that can't be TX within actual ABNF notation of VALUE. So the target here is opposite: "how to extend the ABNF form of VALUE in = a simple way to allow the "transport" of any UTF-8 string/char", to AVOID the usage of = specific coder/decoder in the future packages. Obviously this have a sense if the solution is "simple" (require a = little more effort at the "parser level") and "general" (allow to carry ALL UTF-8 strings and = chars).=20 -----Messaggio originale----- Da: Tom Taylor [mailto:taylor@nortel.com] Inviato: luned=EC 27 giugno 2005 15.02 A: Contardi Angelo Cc: Steve Cipolli; Megaco IETF - Mail List (E-mail); Christian Groves (E-mail) Oggetto: Re: R: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char I dealt with the issue of non-printable characters when putting together = the Advance Audio Server packages (H.248.9). Please see clause=20 6.2.5.1.2/H.248.9 for a discussion of the matter. Contardi Angelo wrote: > He Steve, >=20 > i don't understand these points: >=20 > 1) Where are included non printing chars from 0x01-0x31 and 0x127 in = VALUE? Note that the "general > definition of packages" (pargraphs 12.x.x of H.248.1) allow those = chars too. Otherwise it should > be stated somewhere the opposite. >=20 > 2) Why %x80-F7 should be included in both "quoted" and "non quoted" = form of value. Isn't it enought > to include them just in quoted form of VALUE ? =20 >=20 > 3) How to TX 0x22 (")? It's a NEED, not an optional to tx 0x22 too, = because of, for instance, > the package "Text telephone package", described in the = specification H.248.2, need to tx ANY > UTF-8 string, 0x22 included. I tink this package is used to tx a = text writed by users and so > it may include 0x22 too. And actually 0x22 can't be tx in ANY VALUE = form. So how do you > solve this problem?=20 >=20 > -----Messaggio originale----- > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > Inviato: venerd=EC 24 giugno 2005 21.11 > A: Contardi Angelo > Cc: Sasha Ruditsky; Christian Groves; itu-sg16@external.cisco.com; > megaco@ietf.org > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow to > represent ageneric UTF-8 string/char >=20 >=20 > Angelo, >=20 > Today all ASCII characters except double quotes can be specified by = the VALUE production (some of the characters need to be in the = quotedstring form). Adding UTF-8 does not change this. The part of = UTF-8 that is < 0x80 is exactly ASCII and does not change or need to = change the way in which VALUE is encoded. =20 >=20 > UTF-8 characters above 0x7F are encoded as multiple bytes in which = each byte of the character is guaranteed to be > 0x7F. So UTF-8 = characters are either < 0x80 and are simply the equivalent of ASCII or = they are encoded into multiple bytes in which every byte of the = character is > 0x7F. There will never be a circumstance where a byte of = a UTF-8 multibyte character collides with _any_ ASCII character. >=20 > Perhaps the table below will help clarify >=20 > Scalar Value 1st Byte 2nd Byte 3rd Byte 4th Byte > 00000000 0xxxxxxx 0xxxxxxx > 00000yyy yyxxxxxx 110yyyyy 10xxxxxx > zzzzyyyy yyxxxxxx 1110zzzz 10yyyyyy 10xxxxxx > 000uuuuu zzzzyyyy yyxxxxxx 11110uuu 10uuzzzz 10yyyyyy 10xxxxxx >=20 > Notice that "one byte" UTF-8 characters have their high order bit = cleared (0) and that all bytes of all multi-byte UTF-8 encodings have = the high-order bit set (1). In other words all multi-byte character's = bytes are > 0x7F. >=20 > So changing the productions to: > VALUE =3D quotedString / 1*(SafeChar / %x80-F7) > quotedString =3D DQUOTE *(SafeChar / %x80-F7 / RestChar / = WSP) DQUOTE >=20 > as Sasha Ruditsky suggests will allow UTF-8 characters to be used in = VALUEs. ASCII characters (and UTF-8 equvialents < 0x80) that are in the = RestChar set will need to be quoted just as they have always been. = UTF-8 characters above 0x7F may or may not be quoted, just as all the = ASCII characters in the SafeChar set. >=20 > --Stephen > =09 >=20 >=20 >>-----Original Message----- >>From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it]=20 >>Sent: Friday, June 24, 2005 12:25 PM >>To: Steve Cipolli >>Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow=20 >>to represent ageneric UTF-8 string/char >> >> >> ... _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Jun 27 14:31:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmyOd-0005mT-TN; Mon, 27 Jun 2005 14:31:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmyOb-0005mO-F9 for megaco@megatron.ietf.org; Mon, 27 Jun 2005 14:31:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21557 for ; Mon, 27 Jun 2005 14:31:47 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmynn-0001dj-M9 for megaco@ietf.org; Mon, 27 Jun 2005 14:57:52 -0400 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Date: Mon, 27 Jun 2005 14:31:40 -0400 Message-ID: Thread-Topic: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Thread-Index: AcV48IIZVMaJF4lEQsyG4IrmRqfc3QCDTCGwABEGBOA= From: "Steve Cipolli" To: "Contardi Angelo" , "Megaco IETF - Mail List \(E-mail\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Content-Transfer-Encoding: quoted-printable Cc: "Christian Groves \(E-mail\)" 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 See below. --Stephen > -----Original Message----- > From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it]=20 > Sent: Monday, June 27, 2005 5:59 AM > To: Steve Cipolli; Megaco IETF - Mail List (E-mail) > Cc: Christian Groves (E-mail) > Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow=20 > to represent ageneric UTF-8 string/char >=20 >=20 > He Steve, >=20 > i don't understand these points: >=20 > 1) Where are included non printing chars from 0x01-0x31 and=20 > 0x127 in VALUE? Note that the "general > definition of packages" (pargraphs 12.x.x of H.248.1)=20 > allow those chars too. Otherwise it should > be stated somewhere the opposite. This issue exists for ASCII today. It is not something the UTF-8 = introduces. I do not disagree that this should be solved, but it is a = separate problem from adding UTF-8. The 2 problems can be solved = independently. >=20 > 2) Why %x80-F7 should be included in both "quoted" and "non=20 > quoted" form of value. Isn't it enought > to include them just in quoted form of VALUE ? =20 VALUE takes both quoted and non-quoted forms. The quoted form is used = when a string contains unsafe characters (ie. those that conflict with = the ABNF syntaxes delimiters). Typically strings containing only "safe = characters" are not quoted. Strings containing unsafe characters must = be quoted. I won't argue the merits of this logic, but this is the = current syntax and its usage. The UTF-8 chars above 0x7F are "safe = characters" (ie. they do not interfere with the ABNF sysntax for H.24) = and therefore do not require quoting. Allowing both forms is simply = keeping consistency with how VALUE was originally defined. Adding = UTF-8 does not introduce any new issues in this regard (ie. it doesn't = add unsafe characters) and so should not introduce any new syntax rules = (what characters are safe and what are unsafe). =20 >=20 > 3) How to TX 0x22 (")? It's a NEED, not an optional to tx=20 > 0x22 too, because of, for instance, > the package "Text telephone package", described in the=20 > specification H.248.2, need to tx ANY > UTF-8 string, 0x22 included. I tink this package is used=20 > to tx a text writed by users and so > it may include 0x22 too. And actually 0x22 can't be tx in=20 > ANY VALUE form. So how do you > solve this problem?=20 This problem exists today without UTF-8. It is a completely separate = issue. We can solve the UTF-8 problem with or without solving the 0x22 = problem. Likewise we can solve the 0x22 problem with or without solving = the UTF-8 problem. I'm not against solving the 0x22 problem, but it = need not be solved at the same time or in conjunction with the UTF-8 = problem. >=20 > -----Messaggio originale----- > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > Inviato: venerd=EC 24 giugno 2005 21.11 > A: Contardi Angelo > Cc: Sasha Ruditsky; Christian Groves;=20 > itu-sg16@external.cisco.com; megaco@ietf.org > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow=20 > to represent ageneric UTF-8 string/char >=20 >=20 > Angelo, >=20 > Today all ASCII characters except double quotes can be=20 > specified by the VALUE production (some of the characters=20 > need to be in the quotedstring form). Adding UTF-8 does not=20 > change this. The part of UTF-8 that is < 0x80 is exactly=20 > ASCII and does not change or need to change the way in which=20 > VALUE is encoded. =20 >=20 > UTF-8 characters above 0x7F are encoded as multiple bytes in=20 > which each byte of the character is guaranteed to be > 0x7F. =20 > So UTF-8 characters are either < 0x80 and are simply the=20 > equivalent of ASCII or they are encoded into multiple bytes=20 > in which every byte of the character is > 0x7F. There will=20 > never be a circumstance where a byte of a UTF-8 multibyte=20 > character collides with _any_ ASCII character. >=20 > Perhaps the table below will help clarify >=20 > Scalar Value 1st Byte 2nd Byte 3rd Byte 4th Byte > 00000000 0xxxxxxx 0xxxxxxx > 00000yyy yyxxxxxx 110yyyyy 10xxxxxx > zzzzyyyy yyxxxxxx 1110zzzz 10yyyyyy 10xxxxxx > 000uuuuu zzzzyyyy yyxxxxxx 11110uuu 10uuzzzz 10yyyyyy 10xxxxxx >=20 > Notice that "one byte" UTF-8 characters have their high order=20 > bit cleared (0) and that all bytes of all multi-byte UTF-8=20 > encodings have the high-order bit set (1). In other words=20 > all multi-byte character's bytes are > 0x7F. >=20 > So changing the productions to: > VALUE =3D quotedString / 1*(SafeChar / %x80-F7) > quotedString =3D DQUOTE *(SafeChar / %x80-F7 /=20 > RestChar / WSP) DQUOTE >=20 > as Sasha Ruditsky suggests will allow UTF-8 characters to be=20 > used in VALUEs. ASCII characters (and UTF-8 equvialents <=20 > 0x80) that are in the RestChar set will need to be quoted=20 > just as they have always been. UTF-8 characters above 0x7F=20 > may or may not be quoted, just as all the ASCII characters in=20 > the SafeChar set. >=20 > --Stephen > =09 >=20 > > -----Original Message----- > > From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it] > > Sent: Friday, June 24, 2005 12:25 PM > > To: Steve Cipolli > > Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow=20 > > to represent ageneric UTF-8 string/char > >=20 > >=20 > >=20 > >=20 > > -----Messaggio originale----- > > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > > Inviato: venerd=EC 24 giugno 2005 18.01 > > A: Contardi Angelo; Megaco IETF - Mail List (E-mail) > > Cc: Christian Groves (E-mail) > > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow > > to represent ageneric UTF-8 string/char > >=20 > >=20 > >=20 > > Two points: > >=20 > > 1. It is not necessary to quote the UTF-8 characters as you > > define in your second solution. VALUE can be extended to=20 > > accept characters (quoted and unquoted) in the range 0x80-0xFF. =20 > >=20 > > The problem is that VALUE don't allow to "carry" ALL ASCII > > (0x00-0x7F) too, NEEDED to code UTF-8 characters < 0x80. So=20 > > the only "extension" 0x80-0xFF is NOT enough to allow the TX=20 > > of ALL UTF-8 with ABNF. The quotation is NEEDED becaue of if=20 > > you "scan" an input sequence and allow a VALUE as "any=20 > > sequence of ono or more 0x00-0xFF", all "tokens" identified=20 > > as VALUEs. The extension of quoted form of VALUE i propose=20 > > don't increment the number of the forms of VALUE, just EXEND=20 > > the actual Quoted form of VALUE > >=20 > > 2. Providing a mechanism to allow double quotes (") in a > > (double) quotedstring is essentially a separate issue, since=20 > > addition of UTF-8 chars does not motivate the need for this=20 > > mechanism nor complicate its addition. > >=20 > > See point 1. > >=20 > > --Stephen > >=20 > > > -----Original Message----- > > > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On=20 > > > Behalf Of Contardi Angelo > > > Sent: Friday, June 24, 2005 11:34 AM > > > To: Megaco IETF - Mail List (E-mail) > > > Cc: Christian Groves (E-mail) > > > Subject: [Megaco] The ABNF coding of VALUE doesn't allow to > > > represent ageneric UTF-8 string/char > > >=20 > > >=20 > > > Hello, > > >=20 > > > from my previous private discussion with Christian=20 > Groves, i have=20 > > > deduce this: > > >=20 > > > The ABNF coding of VALUE doesn't allow to represent a generic =20 > > > UTF-8 string or char (RFC 3629) because of: > > >=20 > > > 1) The FIRST byte of an UTF-8 char may be ANY ASCII char in the=20 > > > range 0x00-0x7E > > > and, for instance, the ASCII 0x00-0x07 and 0x22 (") are > > > not allowed in ANY > > > ABNF form of VALUE. > > > =20 > > > 2) Furthermore, UTF-8 chars "greater than 0x7E", need =20 > "ASCII chars" =20 > > > (to better > > > say, Octets) in the range 0x80-0xFF (not ALL), not allowed > > > in ANY ABNF form > > > of VALUE. > > >=20 > > > So, to "correct" this problem, i can suggest two possible=20 > solutions: > > >=20 > > > 1) The simple one, code the UTF-8 string/char in "Octect=20 > Mode", as=20 > > > described in > > > ANNEX B.3. This is a BAD solution from the efficiency > > > transmission point of > > > view because of it "halve the TX band": to TX one UTF-8 =20 > > > char (max 4 Octet) > > > i must TX max 2 x 4 =3D 8 Octet (ASCII chars). > > >=20 > > > 2) The difficult one, allow the ABNF quoted form of VALUE=20 > to TX ALL=20 > > > ASCII chars > > > 0x01-0xFF (the range 0x80-0xFF are more properly named > > > OCTET in RFC2234 ), > > > except 0x22 ("), that should be ESCAPED with "\", as =20 > > > already done for ABNF > > > Local and Remote Descriptor (see SDP). Note that '\0'=20 > > > (0x00) is NOT ALLOWED > > > in this new quoted string form as in the present one, but=20 > > > it's not a problem > > > because in UTF-8 the char '\0' (0x00) is same as in ASCII=20 > > > (string terminator) > > > and is NOT used to code "non ASCII" UTF-8 chars, all=20 > > > those chars > 0x7F that > > > require more than one ASCII chars to be encoded (from 2 to=20 > > > 4 ASCII chars). In > > > fact the "extra chars" needed to code an UTF-8 char are=20 > > > all above 0x7F. > > >=20 > > > While the 1st mode doesn't require any modification of ABNF=20 > > > syntax (but is it applicable in any case ?), the 2nd one require=20 > > > this ABNF modification: > > >=20 > > > quotedString =3D DQUOTE *(quotedChar) DQUOTE > > > =09 > > > ; %x22 (") is allowed just if "escaped" with "\" > > > quotedChar =3D ( %x01-21 / "\" DQUOTE / %x23-FF ) > > >=20 > > > In a parser implementation, i think, this is not a "terrible=20 > > > complication" and can be solved in the same way of=20 > "octetString" of=20 > > > Local and RemoteDescriptor. It require also to implement an =20 > > > ESCAPE "strip(rx)/padding(tx)" mechanism, as already=20 > required for=20 > > > SDP. > > >=20 > > > P.S.: I suppose NO ONE need to send the "string=20 > terminator" '\0'=20 > > > (0x00) in an > > > UTF-8 string or char. If my assertion is false, in > > > the "solution 2)" the > > > %x00 should also be "escaped". Viceversa, the=20 > > > "solution 1)" can already > > > "transport" %x00 octet. > > >=20 > > > Best regards > > >=20 > > > o o o o o o o . . . ___________________________________ > > > o _____ || Angelo Contardi | > > > .][__n_n_|DD[ =3D=3D=3D=3D_____ | = angelo.contardi@italtel.it | > > > >(________|__|_[_________]_|________________________________| > > > _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o` > > >=20 > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 28 04:27:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnBQr-00010B-3q; Tue, 28 Jun 2005 04:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnBQn-000103-3A for megaco@megatron.ietf.org; Tue, 28 Jun 2005 04:26:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12353 for ; Tue, 28 Jun 2005 04:26:55 -0400 (EDT) Received: from mercurio.italtel.it ([138.132.53.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnBq6-00032a-Ay for megaco@ietf.org; Tue, 28 Jun 2005 04:53:07 -0400 Received: from mercurio.italtel.it (localhost [127.0.0.1]) by mercurio.italtel.it (8.12.11/8.12.11) with ESMTP id j5S8QjHF028068 for ; Tue, 28 Jun 2005 10:26:46 +0200 (MEST) Received: from ICSSW035.corp.dom (icssw035.settimo.italtel.it [138.132.90.72]) by mercurio.italtel.it (8.12.11/8.12.11) with ESMTP id j5S8QJN0027960; Tue, 28 Jun 2005 10:26:39 +0200 (MEST) X-Spam-Filter: made by mercurio.italtel.it Received: from BESONE.corp.dom ([138.132.89.14]) by ICSSW035.corp.dom with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 10:25:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Date: Tue, 28 Jun 2005 10:25:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <8E6DA0ECC9F8EE4483CBF31602B1537E81D329@BESONE.corp.dom> Thread-Topic: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Thread-Index: AcV7RnuF5SRhOApgRm240zBiyJiQTAAb8j4g From: "Contardi Angelo" To: "Steve Cipolli" , "Megaco IETF - Mail List \(E-mail\)" X-OriginalArrivalTime: 28 Jun 2005 08:25:45.0885 (UTC) FILETIME=[FB3894D0:01C57BBA] X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Content-Transfer-Encoding: quoted-printable Cc: "Christian Groves \(E-mail\)" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello Steve, if i correctely undestend what you mean, you split the problem to carry = ALL UTF-8 chars/strings in TWO steps: Step 1) Carry ALL pritable UTF-8 chars, except 0x22 ("). Step 2) Carry The rest of other UTF-8 chars. Your proposal solve just the first step. And the second one, how do you = solve ? Adding a new form of VALUE? Which ? A generic UTF-8 string shold then be = formed by a concatenation of quoted, for "printable" UTF-8 chars, and = "somethingelse" , for "non printable" UTF-8 chars ? Is it feasible and reasonably simple to = implement ? Or is better to leave the actual "status quo" ? I think the problem of UTF-8 chars should be solved "globally" because = of this problem rise from "general packages definition" (paragraphs 12.x.x) in which it's = stated that the VALUEs Type of Paramaters/Properties may be also (ANY, not a subset) UTF-8 = String or Char. Actually these two types are allowed just by ASN.1 syntax, not by ABNF. In other points of the syntax where VALEU is used, UTF-8 aren't required = (ASCII it's enought). I think nobody care to tx UTF-8 strings in "error text" or in other = quoted strings different form packages Parameters or Properties values. So the extension of ABNF syntax to carry UTF-8 in VALUE should be FULL = support of UTF-8, as actually is the ASN.1 syntax. Otherwise may be adopted the "trick" used = in H.248.9 with the actual ABNF syntax but should be specified in the "general packages = definition" that the UTF-8 string/char type is valid only for ASN.1 syntax and the = implementor of packages that need UTF-8 string/char type must specify the coding/decoding UTF-8/xxx = scheme (xxx =3D ASCII or Octect or something else), as already done in H.248.9. -----Messaggio originale----- Da: Steve Cipolli [mailto:SCipolli@radvision.com] Inviato: luned=EC 27 giugno 2005 20.32 A: Contardi Angelo; Megaco IETF - Mail List (E-mail) Cc: Christian Groves (E-mail) Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char See below. --Stephen > -----Original Message----- > From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it]=20 > Sent: Monday, June 27, 2005 5:59 AM > To: Steve Cipolli; Megaco IETF - Mail List (E-mail) > Cc: Christian Groves (E-mail) > Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow=20 > to represent ageneric UTF-8 string/char >=20 >=20 > He Steve, >=20 > i don't understand these points: >=20 > 1) Where are included non printing chars from 0x01-0x31 and=20 > 0x127 in VALUE? Note that the "general > definition of packages" (pargraphs 12.x.x of H.248.1)=20 > allow those chars too. Otherwise it should > be stated somewhere the opposite. This issue exists for ASCII today. It is not something the UTF-8 = introduces. I do not disagree that this should be solved, but it is a = separate problem from adding UTF-8. The 2 problems can be solved = independently. >=20 > 2) Why %x80-F7 should be included in both "quoted" and "non=20 > quoted" form of value. Isn't it enought > to include them just in quoted form of VALUE ? =20 VALUE takes both quoted and non-quoted forms. The quoted form is used = when a string contains unsafe characters (ie. those that conflict with = the ABNF syntaxes delimiters). Typically strings containing only "safe = characters" are not quoted. Strings containing unsafe characters must = be quoted. I won't argue the merits of this logic, but this is the = current syntax and its usage. The UTF-8 chars above 0x7F are "safe = characters" (ie. they do not interfere with the ABNF sysntax for H.24) = and therefore do not require quoting. Allowing both forms is simply = keeping consistency with how VALUE was originally defined. Adding = UTF-8 does not introduce any new issues in this regard (ie. it doesn't = add unsafe characters) and so should not introduce any new syntax rules = (what characters are safe and what are unsafe). =20 >=20 > 3) How to TX 0x22 (")? It's a NEED, not an optional to tx=20 > 0x22 too, because of, for instance, > the package "Text telephone package", described in the=20 > specification H.248.2, need to tx ANY > UTF-8 string, 0x22 included. I tink this package is used=20 > to tx a text writed by users and so > it may include 0x22 too. And actually 0x22 can't be tx in=20 > ANY VALUE form. So how do you > solve this problem?=20 This problem exists today without UTF-8. It is a completely separate = issue. We can solve the UTF-8 problem with or without solving the 0x22 = problem. Likewise we can solve the 0x22 problem with or without solving = the UTF-8 problem. I'm not against solving the 0x22 problem, but it = need not be solved at the same time or in conjunction with the UTF-8 = problem. >=20 > -----Messaggio originale----- > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > Inviato: venerd=EC 24 giugno 2005 21.11 > A: Contardi Angelo > Cc: Sasha Ruditsky; Christian Groves;=20 > itu-sg16@external.cisco.com; megaco@ietf.org > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow=20 > to represent ageneric UTF-8 string/char >=20 >=20 > Angelo, >=20 > Today all ASCII characters except double quotes can be=20 > specified by the VALUE production (some of the characters=20 > need to be in the quotedstring form). Adding UTF-8 does not=20 > change this. The part of UTF-8 that is < 0x80 is exactly=20 > ASCII and does not change or need to change the way in which=20 > VALUE is encoded. =20 >=20 > UTF-8 characters above 0x7F are encoded as multiple bytes in=20 > which each byte of the character is guaranteed to be > 0x7F. =20 > So UTF-8 characters are either < 0x80 and are simply the=20 > equivalent of ASCII or they are encoded into multiple bytes=20 > in which every byte of the character is > 0x7F. There will=20 > never be a circumstance where a byte of a UTF-8 multibyte=20 > character collides with _any_ ASCII character. >=20 > Perhaps the table below will help clarify >=20 > Scalar Value 1st Byte 2nd Byte 3rd Byte 4th Byte > 00000000 0xxxxxxx 0xxxxxxx > 00000yyy yyxxxxxx 110yyyyy 10xxxxxx > zzzzyyyy yyxxxxxx 1110zzzz 10yyyyyy 10xxxxxx > 000uuuuu zzzzyyyy yyxxxxxx 11110uuu 10uuzzzz 10yyyyyy 10xxxxxx >=20 > Notice that "one byte" UTF-8 characters have their high order=20 > bit cleared (0) and that all bytes of all multi-byte UTF-8=20 > encodings have the high-order bit set (1). In other words=20 > all multi-byte character's bytes are > 0x7F. >=20 > So changing the productions to: > VALUE =3D quotedString / 1*(SafeChar / %x80-F7) > quotedString =3D DQUOTE *(SafeChar / %x80-F7 /=20 > RestChar / WSP) DQUOTE >=20 > as Sasha Ruditsky suggests will allow UTF-8 characters to be=20 > used in VALUEs. ASCII characters (and UTF-8 equvialents <=20 > 0x80) that are in the RestChar set will need to be quoted=20 > just as they have always been. UTF-8 characters above 0x7F=20 > may or may not be quoted, just as all the ASCII characters in=20 > the SafeChar set. >=20 > --Stephen > =09 >=20 > > -----Original Message----- > > From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it] > > Sent: Friday, June 24, 2005 12:25 PM > > To: Steve Cipolli > > Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow=20 > > to represent ageneric UTF-8 string/char > >=20 > >=20 > >=20 > >=20 > > -----Messaggio originale----- > > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > > Inviato: venerd=EC 24 giugno 2005 18.01 > > A: Contardi Angelo; Megaco IETF - Mail List (E-mail) > > Cc: Christian Groves (E-mail) > > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow > > to represent ageneric UTF-8 string/char > >=20 > >=20 > >=20 > > Two points: > >=20 > > 1. It is not necessary to quote the UTF-8 characters as you > > define in your second solution. VALUE can be extended to=20 > > accept characters (quoted and unquoted) in the range 0x80-0xFF. =20 > >=20 > > The problem is that VALUE don't allow to "carry" ALL ASCII > > (0x00-0x7F) too, NEEDED to code UTF-8 characters < 0x80. So=20 > > the only "extension" 0x80-0xFF is NOT enough to allow the TX=20 > > of ALL UTF-8 with ABNF. The quotation is NEEDED becaue of if=20 > > you "scan" an input sequence and allow a VALUE as "any=20 > > sequence of ono or more 0x00-0xFF", all "tokens" identified=20 > > as VALUEs. The extension of quoted form of VALUE i propose=20 > > don't increment the number of the forms of VALUE, just EXEND=20 > > the actual Quoted form of VALUE > >=20 > > 2. Providing a mechanism to allow double quotes (") in a > > (double) quotedstring is essentially a separate issue, since=20 > > addition of UTF-8 chars does not motivate the need for this=20 > > mechanism nor complicate its addition. > >=20 > > See point 1. > >=20 > > --Stephen > >=20 > > > -----Original Message----- > > > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On=20 > > > Behalf Of Contardi Angelo > > > Sent: Friday, June 24, 2005 11:34 AM > > > To: Megaco IETF - Mail List (E-mail) > > > Cc: Christian Groves (E-mail) > > > Subject: [Megaco] The ABNF coding of VALUE doesn't allow to > > > represent ageneric UTF-8 string/char > > >=20 > > >=20 > > > Hello, > > >=20 > > > from my previous private discussion with Christian=20 > Groves, i have=20 > > > deduce this: > > >=20 > > > The ABNF coding of VALUE doesn't allow to represent a generic =20 > > > UTF-8 string or char (RFC 3629) because of: > > >=20 > > > 1) The FIRST byte of an UTF-8 char may be ANY ASCII char in the=20 > > > range 0x00-0x7E > > > and, for instance, the ASCII 0x00-0x07 and 0x22 (") are > > > not allowed in ANY > > > ABNF form of VALUE. > > > =20 > > > 2) Furthermore, UTF-8 chars "greater than 0x7E", need =20 > "ASCII chars" =20 > > > (to better > > > say, Octets) in the range 0x80-0xFF (not ALL), not allowed > > > in ANY ABNF form > > > of VALUE. > > >=20 > > > So, to "correct" this problem, i can suggest two possible=20 > solutions: > > >=20 > > > 1) The simple one, code the UTF-8 string/char in "Octect=20 > Mode", as=20 > > > described in > > > ANNEX B.3. This is a BAD solution from the efficiency > > > transmission point of > > > view because of it "halve the TX band": to TX one UTF-8 =20 > > > char (max 4 Octet) > > > i must TX max 2 x 4 =3D 8 Octet (ASCII chars). > > >=20 > > > 2) The difficult one, allow the ABNF quoted form of VALUE=20 > to TX ALL=20 > > > ASCII chars > > > 0x01-0xFF (the range 0x80-0xFF are more properly named > > > OCTET in RFC2234 ), > > > except 0x22 ("), that should be ESCAPED with "\", as =20 > > > already done for ABNF > > > Local and Remote Descriptor (see SDP). Note that '\0'=20 > > > (0x00) is NOT ALLOWED > > > in this new quoted string form as in the present one, but=20 > > > it's not a problem > > > because in UTF-8 the char '\0' (0x00) is same as in ASCII=20 > > > (string terminator) > > > and is NOT used to code "non ASCII" UTF-8 chars, all=20 > > > those chars > 0x7F that > > > require more than one ASCII chars to be encoded (from 2 to=20 > > > 4 ASCII chars). In > > > fact the "extra chars" needed to code an UTF-8 char are=20 > > > all above 0x7F. > > >=20 > > > While the 1st mode doesn't require any modification of ABNF=20 > > > syntax (but is it applicable in any case ?), the 2nd one require=20 > > > this ABNF modification: > > >=20 > > > quotedString =3D DQUOTE *(quotedChar) DQUOTE > > > =09 > > > ; %x22 (") is allowed just if "escaped" with "\" > > > quotedChar =3D ( %x01-21 / "\" DQUOTE / %x23-FF ) > > >=20 > > > In a parser implementation, i think, this is not a "terrible=20 > > > complication" and can be solved in the same way of=20 > "octetString" of=20 > > > Local and RemoteDescriptor. It require also to implement an =20 > > > ESCAPE "strip(rx)/padding(tx)" mechanism, as already=20 > required for=20 > > > SDP. > > >=20 > > > P.S.: I suppose NO ONE need to send the "string=20 > terminator" '\0'=20 > > > (0x00) in an > > > UTF-8 string or char. If my assertion is false, in > > > the "solution 2)" the > > > %x00 should also be "escaped". Viceversa, the=20 > > > "solution 1)" can already > > > "transport" %x00 octet. > > >=20 > > > Best regards > > >=20 > > > o o o o o o o . . . ___________________________________ > > > o _____ || Angelo Contardi | > > > .][__n_n_|DD[ =3D=3D=3D=3D_____ | = angelo.contardi@italtel.it | > > > >(________|__|_[_________]_|________________________________| > > > _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o` > > >=20 > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 28 10:52:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHRd-0006uZ-1e; Tue, 28 Jun 2005 10:52:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHRb-0006uU-Mp for megaco@megatron.ietf.org; Tue, 28 Jun 2005 10:52:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16483 for ; Tue, 28 Jun 2005 10:52:09 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnHqy-0003OP-Gp for megaco@ietf.org; Tue, 28 Jun 2005 11:18:25 -0400 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Date: Tue, 28 Jun 2005 10:52:03 -0400 Message-ID: Thread-Topic: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char Thread-Index: AcV7RnuF5SRhOApgRm240zBiyJiQTAAb8j4gAAw3YmA= From: "Steve Cipolli" To: "Contardi Angelo" , "Megaco IETF - Mail List \(E-mail\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Content-Transfer-Encoding: quoted-printable Cc: "Christian Groves \(E-mail\)" 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 Step 2 is a problem that exists for ASCII today. It is not a UTF-8 = problem at all. I welcome your solution to step 2 if this is a problem = that folks want solved, but again it is not a problem caused by the = introduction of UTF-8. =20 --Stephen > -----Original Message----- > From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it]=20 > Sent: Tuesday, June 28, 2005 4:26 AM > To: Steve Cipolli; Megaco IETF - Mail List (E-mail) > Cc: Christian Groves (E-mail) > Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow=20 > to represent ageneric UTF-8 string/char >=20 >=20 > Hello Steve, >=20 > if i correctely undestend what you mean, you split the=20 > problem to carry ALL UTF-8 chars/strings in TWO steps: >=20 > Step 1) Carry ALL pritable UTF-8 chars, except 0x22 ("). > Step 2) Carry The rest of other UTF-8 chars. >=20 > Your proposal solve just the first step. And the second one,=20 > how do you solve ? Adding a new form of VALUE? Which ? A=20 > generic UTF-8 string shold then be formed by a concatenation=20 > of quoted, for "printable" UTF-8 chars, and "somethingelse" ,=20 > for "non printable" UTF-8 chars ? Is it feasible and=20 > reasonably simple to implement ? Or is better to leave the=20 > actual "status quo" ? >=20 > I think the problem of UTF-8 chars should be solved=20 > "globally" because of this problem rise from "general=20 > packages definition" (paragraphs 12.x.x) in which it's stated=20 > that the VALUEs Type of Paramaters/Properties may be also=20 > (ANY, not a subset) UTF-8 String or Char. Actually these two=20 > types are allowed just by ASN.1 syntax, not by ABNF. In other=20 > points of the syntax where VALEU is used, UTF-8 aren't=20 > required (ASCII it's enought). I think nobody care to tx=20 > UTF-8 strings in "error text" or in other quoted strings=20 > different form packages Parameters or Properties values. So=20 > the extension of ABNF syntax to carry UTF-8 in VALUE should=20 > be FULL support of UTF-8, as actually is the ASN.1 syntax.=20 > Otherwise may be adopted the "trick" used in H.248.9 with the=20 > actual ABNF syntax but should be specified in the "general=20 > packages definition" that the UTF-8 string/char type is valid=20 > only for ASN.1 syntax and the implementor of packages that=20 > need UTF-8 string/char type must specify the coding/decoding=20 > UTF-8/xxx scheme (xxx =3D ASCII or Octect or something else),=20 > as already done in H.248.9. >=20 > -----Messaggio originale----- > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > Inviato: luned=EC 27 giugno 2005 20.32 > A: Contardi Angelo; Megaco IETF - Mail List (E-mail) > Cc: Christian Groves (E-mail) > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow=20 > to represent ageneric UTF-8 string/char >=20 >=20 > See below. >=20 > --Stephen >=20 > > -----Original Message----- > > From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it] > > Sent: Monday, June 27, 2005 5:59 AM > > To: Steve Cipolli; Megaco IETF - Mail List (E-mail) > > Cc: Christian Groves (E-mail) > > Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow=20 > > to represent ageneric UTF-8 string/char > >=20 > >=20 > > He Steve, > >=20 > > i don't understand these points: > >=20 > > 1) Where are included non printing chars from 0x01-0x31 and > > 0x127 in VALUE? Note that the "general > > definition of packages" (pargraphs 12.x.x of H.248.1)=20 > > allow those chars too. Otherwise it should > > be stated somewhere the opposite. > This issue exists for ASCII today. It is not something the=20 > UTF-8 introduces. I do not disagree that this should be=20 > solved, but it is a separate problem from adding UTF-8. The=20 > 2 problems can be solved independently. > >=20 > > 2) Why %x80-F7 should be included in both "quoted" and "non > > quoted" form of value. Isn't it enought > > to include them just in quoted form of VALUE ? =20 > VALUE takes both quoted and non-quoted forms. The quoted=20 > form is used when a string contains unsafe characters (ie.=20 > those that conflict with the ABNF syntaxes delimiters). =20 > Typically strings containing only "safe characters" are not=20 > quoted. Strings containing unsafe characters must be quoted.=20 > I won't argue the merits of this logic, but this is the=20 > current syntax and its usage. The UTF-8 chars above 0x7F are=20 > "safe characters" (ie. they do not interfere with the ABNF=20 > sysntax for H.24) and therefore do not require quoting. =20 > Allowing both forms is simply keeping consistency with how=20 > VALUE was originally defined. Adding UTF-8 does not=20 > introduce any new issues in this regard (ie. it doesn't add=20 > unsafe characters) and so should not introduce any new syntax=20 > rules (what characters are safe and what are unsafe). =20 > >=20 > > 3) How to TX 0x22 (")? It's a NEED, not an optional to tx > > 0x22 too, because of, for instance, > > the package "Text telephone package", described in the=20 > > specification H.248.2, need to tx ANY > > UTF-8 string, 0x22 included. I tink this package is used=20 > > to tx a text writed by users and so > > it may include 0x22 too. And actually 0x22 can't be tx in=20 > > ANY VALUE form. So how do you > > solve this problem?=20 > This problem exists today without UTF-8. It is a completely=20 > separate issue. We can solve the UTF-8 problem with or=20 > without solving the 0x22 problem. Likewise we can solve the=20 > 0x22 problem with or without solving the UTF-8 problem. I'm=20 > not against solving the 0x22 problem, but it need not be=20 > solved at the same time or in conjunction with the UTF-8 problem. > >=20 > > -----Messaggio originale----- > > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > > Inviato: venerd=EC 24 giugno 2005 21.11 > > A: Contardi Angelo > > Cc: Sasha Ruditsky; Christian Groves; > > itu-sg16@external.cisco.com; megaco@ietf.org > > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow=20 > > to represent ageneric UTF-8 string/char > >=20 > >=20 > > Angelo, > >=20 > > Today all ASCII characters except double quotes can be > > specified by the VALUE production (some of the characters=20 > > need to be in the quotedstring form). Adding UTF-8 does not=20 > > change this. The part of UTF-8 that is < 0x80 is exactly=20 > > ASCII and does not change or need to change the way in which=20 > > VALUE is encoded. =20 > >=20 > > UTF-8 characters above 0x7F are encoded as multiple bytes in > > which each byte of the character is guaranteed to be > 0x7F. =20 > > So UTF-8 characters are either < 0x80 and are simply the=20 > > equivalent of ASCII or they are encoded into multiple bytes=20 > > in which every byte of the character is > 0x7F. There will=20 > > never be a circumstance where a byte of a UTF-8 multibyte=20 > > character collides with _any_ ASCII character. > >=20 > > Perhaps the table below will help clarify > >=20 > > Scalar Value 1st Byte 2nd Byte 3rd=20 > Byte 4th Byte > > 00000000 0xxxxxxx 0xxxxxxx > > 00000yyy yyxxxxxx 110yyyyy 10xxxxxx > > zzzzyyyy yyxxxxxx 1110zzzz 10yyyyyy 10xxxxxx > > 000uuuuu zzzzyyyy yyxxxxxx 11110uuu 10uuzzzz 10yyyyyy 10xxxxxx > >=20 > > Notice that "one byte" UTF-8 characters have their high order > > bit cleared (0) and that all bytes of all multi-byte UTF-8=20 > > encodings have the high-order bit set (1). In other words=20 > > all multi-byte character's bytes are > 0x7F. > >=20 > > So changing the productions to: > > VALUE =3D quotedString / 1*(SafeChar / %x80-F7) > > quotedString =3D DQUOTE *(SafeChar / %x80-F7 /=20 > > RestChar / WSP) DQUOTE > >=20 > > as Sasha Ruditsky suggests will allow UTF-8 characters to be > > used in VALUEs. ASCII characters (and UTF-8 equvialents <=20 > > 0x80) that are in the RestChar set will need to be quoted=20 > > just as they have always been. UTF-8 characters above 0x7F=20 > > may or may not be quoted, just as all the ASCII characters in=20 > > the SafeChar set. > >=20 > > --Stephen > > =09 > >=20 > > > -----Original Message----- > > > From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it] > > > Sent: Friday, June 24, 2005 12:25 PM > > > To: Steve Cipolli > > > Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow > > > to represent ageneric UTF-8 string/char > > >=20 > > >=20 > > >=20 > > >=20 > > > -----Messaggio originale----- > > > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > > > Inviato: venerd=EC 24 giugno 2005 18.01 > > > A: Contardi Angelo; Megaco IETF - Mail List (E-mail) > > > Cc: Christian Groves (E-mail) > > > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow to=20 > > > represent ageneric UTF-8 string/char > > >=20 > > >=20 > > >=20 > > > Two points: > > >=20 > > > 1. It is not necessary to quote the UTF-8 characters as=20 > you define=20 > > > in your second solution. VALUE can be extended to accept=20 > characters=20 > > > (quoted and unquoted) in the range 0x80-0xFF. > > >=20 > > > The problem is that VALUE don't allow to "carry" ALL ASCII > > > (0x00-0x7F) too, NEEDED to code UTF-8 characters < 0x80. So > > > the only "extension" 0x80-0xFF is NOT enough to allow the TX=20 > > > of ALL UTF-8 with ABNF. The quotation is NEEDED becaue of if=20 > > > you "scan" an input sequence and allow a VALUE as "any=20 > > > sequence of ono or more 0x00-0xFF", all "tokens" identified=20 > > > as VALUEs. The extension of quoted form of VALUE i propose=20 > > > don't increment the number of the forms of VALUE, just EXEND=20 > > > the actual Quoted form of VALUE > > >=20 > > > 2. Providing a mechanism to allow double quotes (") in a > > > (double) quotedstring is essentially a separate issue, since > > > addition of UTF-8 chars does not motivate the need for this=20 > > > mechanism nor complicate its addition. > > >=20 > > > See point 1. > > >=20 > > > --Stephen > > >=20 > > > > -----Original Message----- > > > > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org] On > > > > Behalf Of Contardi Angelo > > > > Sent: Friday, June 24, 2005 11:34 AM > > > > To: Megaco IETF - Mail List (E-mail) > > > > Cc: Christian Groves (E-mail) > > > > Subject: [Megaco] The ABNF coding of VALUE doesn't allow to > > > > represent ageneric UTF-8 string/char > > > >=20 > > > >=20 > > > > Hello, > > > >=20 > > > > from my previous private discussion with Christian > > Groves, i have > > > > deduce this: > > > >=20 > > > > The ABNF coding of VALUE doesn't allow to represent a generic > > > > UTF-8 string or char (RFC 3629) because of: > > > >=20 > > > > 1) The FIRST byte of an UTF-8 char may be ANY ASCII char in the > > > > range 0x00-0x7E > > > > and, for instance, the ASCII 0x00-0x07 and 0x22 (") are > > > > not allowed in ANY > > > > ABNF form of VALUE. > > > > =20 > > > > 2) Furthermore, UTF-8 chars "greater than 0x7E", need > > "ASCII chars" > > > > (to better > > > > say, Octets) in the range 0x80-0xFF (not ALL), not=20 > allowed in =20 > > > > ANY ABNF form > > > > of VALUE. > > > >=20 > > > > So, to "correct" this problem, i can suggest two possible > > solutions: > > > >=20 > > > > 1) The simple one, code the UTF-8 string/char in "Octect > > Mode", as > > > > described in > > > > ANNEX B.3. This is a BAD solution from the efficiency=20 > > > > transmission point of > > > > view because of it "halve the TX band": to TX one UTF-8 > > > > char (max 4 Octet) > > > > i must TX max 2 x 4 =3D 8 Octet (ASCII chars). > > > >=20 > > > > 2) The difficult one, allow the ABNF quoted form of VALUE > > to TX ALL > > > > ASCII chars > > > > 0x01-0xFF (the range 0x80-0xFF are more properly =20 > named OCTET=20 > > > > in RFC2234 ), > > > > except 0x22 ("), that should be ESCAPED with "\", as > > > > already done for ABNF > > > > Local and Remote Descriptor (see SDP). Note that '\0'=20 > > > > (0x00) is NOT ALLOWED > > > > in this new quoted string form as in the present one, but=20 > > > > it's not a problem > > > > because in UTF-8 the char '\0' (0x00) is same as in ASCII=20 > > > > (string terminator) > > > > and is NOT used to code "non ASCII" UTF-8 chars, all=20 > > > > those chars > 0x7F that > > > > require more than one ASCII chars to be encoded (from 2 to=20 > > > > 4 ASCII chars). In > > > > fact the "extra chars" needed to code an UTF-8 char are=20 > > > > all above 0x7F. > > > >=20 > > > > While the 1st mode doesn't require any modification of ABNF > > > > syntax (but is it applicable in any case ?), the 2nd=20 > one require=20 > > > > this ABNF modification: > > > >=20 > > > > quotedString =3D DQUOTE *(quotedChar) DQUOTE > > > > =09 > > > > ; %x22 (") is allowed just if "escaped" with "\" > > > > quotedChar =3D ( %x01-21 / "\" DQUOTE / %x23-FF = ) > > > >=20 > > > > In a parser implementation, i think, this is not a "terrible > > > > complication" and can be solved in the same way of=20 > > "octetString" of > > > > Local and RemoteDescriptor. It require also to implement an > > > > ESCAPE "strip(rx)/padding(tx)" mechanism, as already=20 > > required for > > > > SDP. > > > >=20 > > > > P.S.: I suppose NO ONE need to send the "string > > terminator" '\0' > > > > (0x00) in an > > > > UTF-8 string or char. If my assertion is false, in the=20 > > > > "solution 2)" the > > > > %x00 should also be "escaped". Viceversa, the > > > > "solution 1)" can already > > > > "transport" %x00 octet. > > > >=20 > > > > Best regards > > > >=20 > > > > o o o o o o o . . . =20 > ___________________________________ > > > > o _____ || Angelo=20 > Contardi | > > > > .][__n_n_|DD[ =3D=3D=3D=3D_____ | =20 > angelo.contardi@italtel.it | > > > > =20 > >(________|__|_[_________]_|________________________________| > > > > _/oo OOOOO oo` ooo ooo 'o!o!o =20 > o!o!o` > > > >=20 > > > > _______________________________________________ > > > > Megaco mailing list > > > > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 28 15:39:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnLw7-0005i6-J1; Tue, 28 Jun 2005 15:39:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnLw5-0005hO-SY for megaco@megatron.ietf.org; Tue, 28 Jun 2005 15:39:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11280 for ; Tue, 28 Jun 2005 15:39:53 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnMHm-0002TD-TP for megaco@ietf.org; Tue, 28 Jun 2005 16:02:24 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5SJZuP14113 for ; Tue, 28 Jun 2005 15:35:56 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jun 2005 15:35:46 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402BE17A8@zrtphxm2> From: "Kevin Boyle" To: Christian Groves , Frank Reno Subject: RE: [Megaco] Topology Questions Date: Tue, 28 Jun 2005 15:35:39 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 This issue has been around for some time. The solution determined for V1/V2 was to echo back the TP Descriptor, as Christian stated. A contribution will have to be made for a fix in V3. Kevin -----Original Message----- From: Christian Groves [mailto:christian.groves@ericsson.com] Sent: Sunday, June 26, 2005 8:50 PM To: Frank Reno Cc: megaco@ietf.org; Boyle, Kevin [NCRTP:3Z40:EXCH] Subject: Re: [Megaco] Topology Questions Hello Frank, Please see my replies below. Regards, Christian Frank Reno wrote: [KJBII] snip... > > > Here's another one... > > 7. Section 7.1.18 states that "It is possible to have an action > containing only a Topology descriptor". In the text encoding, what > should the response be to such an action? The ABNF requires something > in the actionReply - at least one context property, command reply or > error descriptor. [CHG] Another ABNF quirk to fix in v3. I would say that for v1 and v2 you should echo back what was sent. If CHOOSE $ was indicated you should send back the chosen terminationId. In terms of a fix to be equivalent with the ASN.1 you probably want to make the command reply optional ie. actionReply = CtxToken EQUAL ContextID LBRKT [ (errorDescriptor / commandReply /(commandReply COMMA errorDescriptor)) ] RBRKT _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 28 15:40:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnLwC-0005kj-2i; Tue, 28 Jun 2005 15:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnLw9-0005jC-Ts for megaco@megatron.ietf.org; Tue, 28 Jun 2005 15:40:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11347 for ; Tue, 28 Jun 2005 15:39:59 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnMF0-0001SO-13 for megaco@ietf.org; Tue, 28 Jun 2005 15:59:31 -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 j5SJWrL18942 for ; Tue, 28 Jun 2005 15:32:53 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jun 2005 15:32:53 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402BE178B@zrtphxm2> From: "Kevin Boyle" To: "B Venkat S.R Swamy" , "Putter, Michael [Business:TELRD:3L40]" Subject: RE: [Megaco] Digit Map Completion event without digits? Date: Tue, 28 Jun 2005 15:32:40 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.2 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Well, this would depend. The digit collection packages in H.248.16 allow for the MGC to define whether to include the digit that caused the mismatch or not. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of B Venkat S.R Swamy Sent: Monday, June 27, 2005 6:01 AM To: Putter, Michael [Business:TELRD:3L40] Cc: 'megaco@ietf.org' Subject: Re: [Megaco] Digit Map Completion event without digits? Hi Yes, you are right, Notify for digit completion will be generated with Method as PartialMatch and without any digits. regards B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.flextronicssoftware.com Michael Putter To Sent by: "'megaco@ietf.org'" megaco-bounces@ie tf.org cc Subject 06/27/2005 02:32 [Megaco] Digit Map Completion event PM without digits? Hello, In "7.1.14.5 DigitMap procedures" there is the following piece in the item 5): "If exactly one candidate remains and it has been fully matched, a completion event is generated indicating an unambiguous match. If no candidates remain, the latest event is removed from the current dial string and a completion event is generated indicating full match if one of the candidates from the previous step was fully satisfied before the latest event was detected, or partial match otherwise." What happens if the 1st dialed digit does not satisfy any candidate? Is completion event is generated with partial match and without digits? Thanks, Michael. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco *********************** FSS-Restricted *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 28 16:15:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnMSF-0006KJ-3D; Tue, 28 Jun 2005 16:13:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnMSB-0006J0-LD for megaco@megatron.ietf.org; Tue, 28 Jun 2005 16:13:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15097 for ; Tue, 28 Jun 2005 16:13:01 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnMrV-0007ha-Ir for megaco@ietf.org; Tue, 28 Jun 2005 16:39:18 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5SKCeP06169 for ; Tue, 28 Jun 2005 16:12:40 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jun 2005 16:12:10 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA402C4C227@zrtphxm2> From: "Kevin Boyle" To: Contardi Angelo , Steve Cipolli , "Megaco IETF - Mail List (E-mail)" Subject: RE: [Megaco] The ABNF coding of VALUE doesn't allow to representa generic UTF-8 string/char Date: Tue, 28 Jun 2005 16:11:58 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Cc: "Christian Groves \(E-mail\)" 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 will note that H.248.23 also has avoided this problem by encoding the data in hex. This, along with the solution in .9, provides examples of two possible solutions to both problems. You continue to point out that ASN.1 doesn't have this problem. That is because ASN.1 uses the hex encoding, and can avoid some of the end of string detection problems that ABNF inherently possesses. .23 uses this same idea -- hex encoding in the ABNF allows explicit detection of the end of the value string without adding a collision with the delimiters. Steve makes some good points about the fact that the upper half of UTF-8 does not collide with the delimiter, and therefore shouldn't be a problem. I have no problem with this as a solution. A contribution should be taken to SG16 for this proposal. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Contardi Angelo Sent: Tuesday, June 28, 2005 4:26 AM To: Steve Cipolli; Megaco IETF - Mail List (E-mail) Cc: Christian Groves (E-mail) Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow to representageneric UTF-8 string/char Hello Steve, if i correctely undestend what you mean, you split the problem to carry ALL UTF-8 chars/strings in TWO steps: Step 1) Carry ALL pritable UTF-8 chars, except 0x22 ("). Step 2) Carry The rest of other UTF-8 chars. Your proposal solve just the first step. And the second one, how do you solve ? Adding a new form of VALUE? Which ? A generic UTF-8 string shold then be formed by a concatenation of quoted, for "printable" UTF-8 chars, and "somethingelse" , for "non printable" UTF-8 chars ? Is it feasible and reasonably simple to implement ? Or is better to leave the actual "status quo" ? I think the problem of UTF-8 chars should be solved "globally" because of this problem rise from "general packages definition" (paragraphs 12.x.x) in which it's stated that the VALUEs Type of Paramaters/Properties may be also (ANY, not a subset) UTF-8 String or Char. Actually these two types are allowed just by ASN.1 syntax, not by ABNF. In other points of the syntax where VALEU is used, UTF-8 aren't required (ASCII it's enought). I think nobody care to tx UTF-8 strings in "error text" or in other quoted strings different form packages Parameters or Properties values. So the extension of ABNF syntax to carry UTF-8 in VALUE should be FULL support of UTF-8, as actually is the ASN.1 syntax. Otherwise may be adopted the "trick" used in H.248.9 with the actual ABNF syntax but should be specified in the "general packages definition" that the UTF-8 string/char type is valid only for ASN.1 syntax and the implementor of packages that need UTF-8 string/char type must specify the coding/decoding UTF-8/xxx scheme (xxx = ASCII or Octect or something else), as already done in H.248.9. -----Messaggio originale----- Da: Steve Cipolli [mailto:SCipolli@radvision.com] Inviato: luned́ 27 giugno 2005 20.32 A: Contardi Angelo; Megaco IETF - Mail List (E-mail) Cc: Christian Groves (E-mail) Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char See below. --Stephen > -----Original Message----- > From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it] > Sent: Monday, June 27, 2005 5:59 AM > To: Steve Cipolli; Megaco IETF - Mail List (E-mail) > Cc: Christian Groves (E-mail) > Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow to > represent ageneric UTF-8 string/char > > > He Steve, > > i don't understand these points: > > 1) Where are included non printing chars from 0x01-0x31 and > 0x127 in VALUE? Note that the "general > definition of packages" (pargraphs 12.x.x of H.248.1) allow those > chars too. Otherwise it should > be stated somewhere the opposite. This issue exists for ASCII today. It is not something the UTF-8 introduces. I do not disagree that this should be solved, but it is a separate problem from adding UTF-8. The 2 problems can be solved independently. > > 2) Why %x80-F7 should be included in both "quoted" and "non quoted" > form of value. Isn't it enought > to include them just in quoted form of VALUE ? VALUE takes both quoted and non-quoted forms. The quoted form is used when a string contains unsafe characters (ie. those that conflict with the ABNF syntaxes delimiters). Typically strings containing only "safe characters" are not quoted. Strings containing unsafe characters must be quoted. I won't argue the merits of this logic, but this is the current syntax and its usage. The UTF-8 chars above 0x7F are "safe characters" (ie. they do not interfere with the ABNF sysntax for H.24) and therefore do not require quoting. Allowing both forms is simply keeping consistency with how VALUE was originally defined. Adding UTF-8 does not introduce any new issues in this regard (ie. it doesn't add unsafe characters) and so should not introduce any new syntax rules (what characters are safe and what are unsafe). > > 3) How to TX 0x22 (")? It's a NEED, not an optional to tx > 0x22 too, because of, for instance, > the package "Text telephone package", described in the > specification H.248.2, need to tx ANY > UTF-8 string, 0x22 included. I tink this package is used to tx a > text writed by users and so > it may include 0x22 too. And actually 0x22 can't be tx in ANY VALUE > form. So how do you > solve this problem? This problem exists today without UTF-8. It is a completely separate issue. We can solve the UTF-8 problem with or without solving the 0x22 problem. Likewise we can solve the 0x22 problem with or without solving the UTF-8 problem. I'm not against solving the 0x22 problem, but it need not be solved at the same time or in conjunction with the UTF-8 problem. > > -----Messaggio originale----- > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > Inviato: venerd́ 24 giugno 2005 21.11 > A: Contardi Angelo > Cc: Sasha Ruditsky; Christian Groves; itu-sg16@external.cisco.com; > megaco@ietf.org > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow to > represent ageneric UTF-8 string/char > > > Angelo, > > Today all ASCII characters except double quotes can be specified by > the VALUE production (some of the characters need to be in the > quotedstring form). Adding UTF-8 does not change this. The part of > UTF-8 that is < 0x80 is exactly ASCII and does not change or need to > change the way in which VALUE is encoded. > > UTF-8 characters above 0x7F are encoded as multiple bytes in which > each byte of the character is guaranteed to be > 0x7F. > So UTF-8 characters are either < 0x80 and are simply the equivalent of > ASCII or they are encoded into multiple bytes in which every byte of > the character is > 0x7F. There will never be a circumstance where a > byte of a UTF-8 multibyte character collides with _any_ ASCII > character. > > Perhaps the table below will help clarify > > Scalar Value 1st Byte 2nd Byte 3rd Byte 4th Byte > 00000000 0xxxxxxx 0xxxxxxx > 00000yyy yyxxxxxx 110yyyyy 10xxxxxx > zzzzyyyy yyxxxxxx 1110zzzz 10yyyyyy 10xxxxxx > 000uuuuu zzzzyyyy yyxxxxxx 11110uuu 10uuzzzz 10yyyyyy 10xxxxxx > > Notice that "one byte" UTF-8 characters have their high order bit > cleared (0) and that all bytes of all multi-byte UTF-8 encodings have > the high-order bit set (1). In other words all multi-byte character's > bytes are > 0x7F. > > So changing the productions to: > VALUE = quotedString / 1*(SafeChar / %x80-F7) > quotedString = DQUOTE *(SafeChar / %x80-F7 / > RestChar / WSP) DQUOTE > > as Sasha Ruditsky suggests will allow UTF-8 characters to be used in > VALUEs. ASCII characters (and UTF-8 equvialents < > 0x80) that are in the RestChar set will need to be quoted just as they > have always been. UTF-8 characters above 0x7F may or may not be > quoted, just as all the ASCII characters in the SafeChar set. > > --Stephen > > > > -----Original Message----- > > From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it] > > Sent: Friday, June 24, 2005 12:25 PM > > To: Steve Cipolli > > Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow to > > represent ageneric UTF-8 string/char > > > > > > > > > > -----Messaggio originale----- > > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > > Inviato: venerd́ 24 giugno 2005 18.01 > > A: Contardi Angelo; Megaco IETF - Mail List (E-mail) > > Cc: Christian Groves (E-mail) > > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow to > > represent ageneric UTF-8 string/char > > > > > > > > Two points: > > > > 1. It is not necessary to quote the UTF-8 characters as you define > > in your second solution. VALUE can be extended to accept characters > > (quoted and unquoted) in the range 0x80-0xFF. > > > > The problem is that VALUE don't allow to "carry" ALL ASCII > > (0x00-0x7F) too, NEEDED to code UTF-8 characters < 0x80. So the only > > "extension" 0x80-0xFF is NOT enough to allow the TX of ALL UTF-8 > > with ABNF. The quotation is NEEDED becaue of if you "scan" an input > > sequence and allow a VALUE as "any sequence of ono or more > > 0x00-0xFF", all "tokens" identified as VALUEs. The extension of > > quoted form of VALUE i propose don't increment the number of the > > forms of VALUE, just EXEND the actual Quoted form of VALUE > > > > 2. Providing a mechanism to allow double quotes (") in a > > (double) quotedstring is essentially a separate issue, since > > addition of UTF-8 chars does not motivate the need for this > > mechanism nor complicate its addition. > > > > See point 1. > > > > --Stephen > > > > > -----Original Message----- > > > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On > > > Behalf Of Contardi Angelo > > > Sent: Friday, June 24, 2005 11:34 AM > > > To: Megaco IETF - Mail List (E-mail) > > > Cc: Christian Groves (E-mail) > > > Subject: [Megaco] The ABNF coding of VALUE doesn't allow to > > > represent ageneric UTF-8 string/char > > > > > > > > > Hello, > > > > > > from my previous private discussion with Christian > Groves, i have > > > deduce this: > > > > > > The ABNF coding of VALUE doesn't allow to represent a generic > > > UTF-8 string or char (RFC 3629) because of: > > > > > > 1) The FIRST byte of an UTF-8 char may be ANY ASCII char in the > > > range 0x00-0x7E > > > and, for instance, the ASCII 0x00-0x07 and 0x22 (") are not > > > allowed in ANY > > > ABNF form of VALUE. > > > > > > 2) Furthermore, UTF-8 chars "greater than 0x7E", need > "ASCII chars" > > > (to better > > > say, Octets) in the range 0x80-0xFF (not ALL), not allowed in > > > ANY ABNF form > > > of VALUE. > > > > > > So, to "correct" this problem, i can suggest two possible > solutions: > > > > > > 1) The simple one, code the UTF-8 string/char in "Octect > Mode", as > > > described in > > > ANNEX B.3. This is a BAD solution from the efficiency > > > transmission point of > > > view because of it "halve the TX band": to TX one UTF-8 char > > > (max 4 Octet) > > > i must TX max 2 x 4 = 8 Octet (ASCII chars). > > > > > > 2) The difficult one, allow the ABNF quoted form of VALUE > to TX ALL > > > ASCII chars > > > 0x01-0xFF (the range 0x80-0xFF are more properly named OCTET > > > in RFC2234 ), > > > except 0x22 ("), that should be ESCAPED with "\", as already > > > done for ABNF > > > Local and Remote Descriptor (see SDP). Note that '\0' > > > (0x00) is NOT ALLOWED > > > in this new quoted string form as in the present one, but it's > > > not a problem > > > because in UTF-8 the char '\0' (0x00) is same as in ASCII > > > (string terminator) > > > and is NOT used to code "non ASCII" UTF-8 chars, all those > > > chars > 0x7F that > > > require more than one ASCII chars to be encoded (from 2 to > > > 4 ASCII chars). In > > > fact the "extra chars" needed to code an UTF-8 char are all > > > above 0x7F. > > > > > > While the 1st mode doesn't require any modification of ABNF > > > syntax (but is it applicable in any case ?), the 2nd one require > > > this ABNF modification: > > > > > > quotedString = DQUOTE *(quotedChar) DQUOTE > > > > > > ; %x22 (") is allowed just if "escaped" with "\" > > > quotedChar = ( %x01-21 / "\" DQUOTE / %x23-FF ) > > > > > > In a parser implementation, i think, this is not a "terrible > > > complication" and can be solved in the same way of > "octetString" of > > > Local and RemoteDescriptor. It require also to implement an > > > ESCAPE "strip(rx)/padding(tx)" mechanism, as already > required for > > > SDP. > > > > > > P.S.: I suppose NO ONE need to send the "string > terminator" '\0' > > > (0x00) in an > > > UTF-8 string or char. If my assertion is false, in the > > > "solution 2)" the > > > %x00 should also be "escaped". Viceversa, the "solution 1)" > > > can already > > > "transport" %x00 octet. > > > > > > Best regards > > > > > > o o o o o o o . . . ___________________________________ > > > o _____ || Angelo Contardi | > > > .][__n_n_|DD[ ====_____ | angelo.contardi@italtel.it | > > > >(________|__|_[_________]_|________________________________| > > > _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o` > > > > > > _______________________________________________ > > > Megaco mailing 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 Jun 29 10:16:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DndMh-0005qv-Md; Wed, 29 Jun 2005 10:16:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DndMg-0005qq-KA for megaco@megatron.ietf.org; Wed, 29 Jun 2005 10:16:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24161 for ; Wed, 29 Jun 2005 10:16:32 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DndmE-00088b-0H for megaco@ietf.org; Wed, 29 Jun 2005 10:43:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] The ABNF coding of VALUE doesn't allow to representageneric UTF-8 string/char Date: Wed, 29 Jun 2005 10:16:23 -0400 Message-ID: Thread-Topic: [Megaco] The ABNF coding of VALUE doesn't allow to representageneric UTF-8 string/char Thread-Index: AcV8HblVCBCqJRzaS5GIysN/LgpAPwABsgbA From: "Steve Cipolli" To: "Kevin Boyle" , "Contardi Angelo" , "Megaco IETF - Mail List \(E-mail\)" X-Spam-Score: 0.9 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: Sasha Ruditsky , "Christian Groves \(E-mail\)" 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="===============0283734327==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0283734327== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57CB5.210884F4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57CB5.210884F4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha Ruditski from RADVISION is putting together a contribution for adding UTF-8 characters 0x80-0xFF (technically only 0x80-0xF7 according to the rules of UTF-8) =20 The other two issues: 1. Support for escaping double quotes (0x22) in quoted VALUE strings and 2. Support for non-printable characters in the range 0x01-0x19 should be handled in separate contributions. =20 Issue #1 makes sense to me to be included in v3. =20 =20 Issue #2 is less clear. to me. I'm not sure it is worth the effort, or if instead the package definition text should simply be changed to say "printable UTF-8 characters (0x20-0xFF)" for all encodings. My reasoning is that even if we add 0x01-0x19 to VALUE we still will not be able to transmit UTF-8 character 0x00 in ABNF, so the blanket statement that says all UTF-8 characters are supported would still not be true. =20 --Stephen -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com]=20 Sent: Tuesday, June 28, 2005 4:12 PM To: Contardi Angelo; Steve Cipolli; Megaco IETF - Mail List (E-mail) Cc: Christian Groves (E-mail) Subject: RE: [Megaco] The ABNF coding of VALUE doesn't allow to representageneric UTF-8 string/char =09 =09 I will note that H.248.23 also has avoided this problem by encoding the data in hex. This, along with the solution in .9, provides examples of two possible solutions to both problems. You continue to point out that ASN.1 doesn't have this problem. That is because ASN.1 uses the hex encoding, and can avoid some of the end of string detection problems that ABNF inherently possesses. .23 uses this same idea -- hex encoding in the ABNF allows explicit detection of the end of the value string without adding a collision with the delimiters. Steve makes some good points about the fact that the upper half of UTF-8 does not collide with the delimiter, and therefore shouldn't be a problem. I have no problem with this as a solution. A contribution should be taken to SG16 for this proposal. Kevin=20 [Snip...] ------_=_NextPart_001_01C57CB5.210884F4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Sasha=20 Ruditski from RADVISION is putting together a contribution for adding = UTF-8=20 characters 0x80-0xFF (technically only 0x80-0xF7 according to the rules = of=20 UTF-8)
 
The=20 other two issues:
    1. Support for escaping = double=20 quotes (0x22) in quoted VALUE strings and
    2. Support for = non-printable=20 characters in the range 0x01-0x19
should=20 be handled in separate contributions.
 
Issue=20 #1 makes sense to me to be included in v3.  =
 
Issue=20 #2 is less clear. to me.  I'm not sure it is worth the effort, = or if=20 instead the package definition text should simply be changed to say = "printable=20 UTF-8 characters (0x20-0xFF)" for all encodings.  My reasoning is = that even=20 if we add 0x01-0x19 to VALUE we still will not be able to transmit UTF-8 = character 0x00 in ABNF, so the blanket statement that says all UTF-8 = characters=20 are supported would still not be true.
 
--Stephen
-----Original Message-----
From: = Kevin Boyle=20 [mailto:kboyle@nortel.com]
Sent: Tuesday, June 28, 2005 = 4:12=20 PM
To: Contardi Angelo; Steve Cipolli; Megaco IETF - Mail = List=20 (E-mail)
Cc: Christian Groves (E-mail)
Subject: = RE:=20 [Megaco] The ABNF coding of VALUE doesn't allow to representageneric = UTF-8=20 string/char

I will note that H.248.23 also has avoided this = problem by=20 encoding the data in hex.  This, along with the solution in .9, = provides=20 examples of two possible solutions to both problems.

You continue to point out that ASN.1 doesn't have = this=20 problem.  That is because ASN.1 uses the hex encoding, and can = avoid some=20 of the end of string detection problems that ABNF inherently = possesses. =20 .23 uses this same idea -- hex encoding in the ABNF allows explicit = detection=20 of the end of the value string without adding a collision with the=20 delimiters.

Steve makes some good points about the fact that the = upper=20 half of UTF-8 does not collide with the delimiter, and therefore = shouldn't be=20 a problem.  I have no problem with this as a solution.  A=20 contribution should be taken to SG16 for this proposal.

Kevin

[Snip...]

------_=_NextPart_001_01C57CB5.210884F4-- --===============0283734327== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0283734327==-- From megaco-bounces@ietf.org Thu Jun 30 14:39:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do3x8-000181-So; Thu, 30 Jun 2005 14:39:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do3x7-00017k-Vt for megaco@megatron.ietf.org; Thu, 30 Jun 2005 14:39:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10306 for ; Thu, 30 Jun 2005 14:39:56 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do4CF-0002lO-AN for megaco@ietf.org; Thu, 30 Jun 2005 14:55:38 -0400 Received: from web61322.mail.yahoo.com ([209.73.179.76]) by mx2.foretec.com with smtp (Exim 4.24) id 1Do3T8-0005Tv-1Y for megaco@ietf.org; Thu, 30 Jun 2005 14:08:58 -0400 Received: (qmail 79875 invoked by uid 60001); 30 Jun 2005 18:08:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3ftvUXhHkGI3BMB1c4vzYd/SK1qRbkbP3jHQpycojGxCJXtO6+bq3CBfpuZ3wvM/p9SJcICV1VcSeXq8TVLu94Pir9sDF3M087ymEb4poPZU30zTj07VGpwbANDRYFrHJAWAAThMHOS5YPw5cvWyiiIyJflq25OIEffKf4b6nO4= ; Message-ID: <20050630180826.79873.qmail@web61322.mail.yahoo.com> Received: from [216.223.9.2] by web61322.mail.yahoo.com via HTTP; Thu, 30 Jun 2005 11:08:26 PDT Date: Thu, 30 Jun 2005 11:08:26 -0700 (PDT) From: Frank Reno Subject: RE: [Megaco] Audit on Wildcarded Context and ROOT Termination iss ue- To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Content-Transfer-Encoding: 8bit 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 looks like V3 will be modified to allow empty action replies, as these are necessary to respond to actions with no commands. Perhaps empty action replies can be used to return the list of context IDs. It would still be very compact and it wouldn't require any additional changes to the spec. For example P=1{C=1,C=2,C=3,C=4,C=5,C=6} Instead of P=1{C=*{CT{CLT{1,2,3,4,5,6}}}} Frank --- Kevin Boyle wrote: There has already been a proposal for a "context list" construct to return a shorter message for those commands that are just interested in getting a list of contexts. Similarly, there is a construct to allow the return of a list of TermIDs in a command or response. These are being worked into V3. The construct proposed does not keep with the way the existing constructs are built. That list of "numbers" could be anything, and only by convention would one know that they are supposed to be some kind of list of ContextIDs. This level is where descriptors are placed, but this isn't a descriptor -- it's just an arbitrary list. I believe the construct being pursued by SG16 for V3 is much better aligned with the look and feel of H.248 message construction. Kevin -----Original Message----- From: megaco-bounces at ietf.org [mailto:megaco-bounces at ietf.org] On Behalf Of B Venkat S.R Swamy Sent: Monday, June 20, 2005 5:03 AM To: megaco at ietf.org Cc: Jon Rowland Subject: RE: [Megaco] Audit on Wildcarded Context and ROOT Termination issue- Hi The problem with the option 1 below is that for large gateways there is lot of redundant information mainly the "{AV=ROOT}" getting repeated unnecessarly for each action, therefore the suggested solution is quite optimized, repeated here with short token. MG1 to MGC: !/1 [124.124.124.222]:55555 p=9999{ C=*{AV = ROOT {1, 2} } Also with the growing interest in H248 and more and more vendors asking for compliance with the only available test suite defined by ETSI, there is need to address the problems that have been reported in the ETSI test suite(ETSI TS 101 889-2) in megaco mailinglist. Are there any plans to define a similiar test suite in ITU-T . B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.flextronicssoftware.com "Jon Rowland" To B Venkat S.R Swamy/HSS at HSS 06/16/2005 03:24 cc PM Subject RE: [Megaco] Audit on Wildcarded Context and ROOT Termination issue- Option 1 is correct. Options 2 and 3 are responses to a wildcard termination audit of wildcarded context IDs as you correctly point out. This suggests that the ETSI spec is erroneous. Your suggested compressed scheme doesn't really add very much over the short-text encoding of the transaction response: !/1 [124.124.124.124]:55555 P=9999{ C=1{AV=ROOT}, C=2{AV=ROOT} } Hence, I'm not sure it is justifiable given it is not back-compatible. The general problem with this type of command, when used in conjunction with large gateways, is that the response size can get quite large, which can be a problem when using TCP or UDP transports. This has been addressed in V3 by the introduction of a scheme for segmenting responses. Jon. -----Original Message----- From: megaco-bounces at ietf.org [mailto:megaco-bounces at ietf.org] On Behalf Of B Venkat S.R Swamy Sent: 16 June 2005 04:57 To: megaco at ietf.org Subject: [Megaco] Audit on Wildcarded Context and ROOT Termination issue- Hi, H.248.1 V1 and V2 section 7.2.5 say Auditvalue on Termination ID Root with context ID All should return list of all ContextIds (the ContextID list should be returned by using multiple action replies, each containing a ContextID from the list). Now the question is: How will the reply for the following scenario look like? Audit on termination ROOT with context * and empty audit descriptor MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 { Context = * { AuditValue = ROOT { Audit {}} } } There are currently three options: Option 1: Audit on ROOT termination returning only context information: MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = 1 {Auditvalue = ROOT}, Context = 2 {Auditvalue = ROOT} } Option 2: As per ETSI TS 101 889-2 section 5.1.9.1 "TP/MG/AV/BV-05" MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = 1 {Auditvalue = A4444 , Auditvalue = A4445}, Context = 2 {Auditvalue = A5444 , Auditvalue = A5445} } Option 3: condensed form of option 2 above : MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = 1 {Auditvalue = Context {A4444 , A4445} }, Context = 2 {Auditvalue = Context {A5444 , A5445} }, } However the option2 and option3 can be obtained through- Audit on Wildcarded context and Wildcarded termination with Empty Audit Descriptor. MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 { Context = * { AuditValue = * { Audit {}} } } Now considering the fact that the basic objective of Audit on ROOT termination and Context * is to get the list of context IDs only without any termination information, an optimized solution is suggested below. This however requires changes in the protocol grammar. MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 9999 { Context = * {Auditvalue = ROOT {1, 2} } Request mailing list comments on the above issue, on either accepting the above solution or discontinuing the option of sending Audit on ROOT Termination and Context *. Regards, B Venkat S.R Swamy Senior Technical Leader Flextronics Software Systems Phone: +91-124-2455555 Extn 3620 Fax: +91-124-2455345 web: www.flextronicssoftware.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco