From Matia.Marcu@Teledata-Networks.com Thu Apr 14 01:35:12 2011 Return-Path: X-Original-To: megaco@ietfc.amsl.com Delivered-To: megaco@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B86BBE0887 for ; Thu, 14 Apr 2011 01:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.421 X-Spam-Level: * X-Spam-Status: No, score=1.421 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_RECV_BEZEQINT_B=0.763, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzXZOKrH2jkk for ; Thu, 14 Apr 2011 01:35:10 -0700 (PDT) Received: from teledata-networks.com (mail.teledata-networks.com [81.218.12.242]) by ietfc.amsl.com (Postfix) with ESMTP id 16BB1E0884 for ; Thu, 14 Apr 2011 01:35:09 -0700 (PDT) Received: from Internal Mail-Server by Mail-SeCure (envelope-from Matia.Marcu@Teledata-Networks.com) with SMTP; 14 Apr 2011 11:17:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBFA7F.05623E13" Date: Thu, 14 Apr 2011 11:36:16 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: simulating termination on-hook when the gateway goes out of service Thread-Index: Acv6fwUqPfKoIh/3T8qDPlAzj702Jg== From: "Matia Marcu" To: Subject: [Megaco] simulating termination on-hook when the gateway goes out of service X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 08:35:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBFA7F.05623E13 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let's consider the case of two terminations involved in a conversation when the virtual gateway serving them is restarted. =20 In this case, when the GW is restored to service, most SSWs are able to handle correctly the terminations that have been off-hook at the time of the GW restart. =20 But some SSWs stop referring to these terminations after the GW is back in service. The explanation was that, before sending ServiceChange - Forced on ROOT, the GW should have sent a fictional on-hook notification for each termination in off-hook state. =20 We think that, in the spirit of H.248, the GW should not simulate on-hook when the termination is off-hook. =20 Is our behaviour correct?=20 =20 Many thanks. =20 Best regards, =20 Matia=20 NOTICE: This email and any files transmitted with it are Enablence and Teledata-Networks confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains Enablence and Teledata-Networks confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ------_=_NextPart_001_01CBFA7F.05623E13 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let's consider the case of two terminations involved in a conversation when = the virtual gateway serving them is restarted.

 

In this case, when the GW is restored to service, most SSWs are able to = handle correctly the terminations that have been off-hook at the time of the GW = restart.

 

But some SSWs stop referring to these terminations after the GW is back in = service. The explanation was that, before sending ServiceChange – Forced on = ROOT, the GW should have sent a fictional on-hook notification for each = termination in off-hook state.

 

We think that, in the spirit of H.248, the GW should not simulate on-hook = when the termination is off-hook.

 

Is our behaviour correct?

 

Many thanks.

 

Best regards,

 

Matia



NOTICE: This email and any files transmitted with it are Enablence and Teledata-Networks confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains Enablence and Teledata-Networks confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
------_=_NextPart_001_01CBFA7F.05623E13-- From arindam.bhattacharjee@alcatel-lucent.com Thu Apr 14 09:32:11 2011 Return-Path: X-Original-To: megaco@ietfc.amsl.com Delivered-To: megaco@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 525AAE0820 for ; Thu, 14 Apr 2011 09:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIAQVRYdFS+l for ; Thu, 14 Apr 2011 09:32:07 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfc.amsl.com (Postfix) with ESMTP id 5D319E07CA for ; Thu, 14 Apr 2011 09:32:04 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p3EGW2Bk007422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Apr 2011 11:32:02 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3EGW1Te010911 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 Apr 2011 11:32:02 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 14 Apr 2011 11:32:02 -0500 From: "Bhattacharjee, Arindam (Arindam)" To: Matia Marcu , "megaco@ietf.org" Date: Thu, 14 Apr 2011 11:32:00 -0500 Thread-Topic: [Megaco] simulating termination on-hook when the gateway goes out of service Thread-Index: Acv6fwUqPfKoIh/3T8qDPlAzj702JgAQMyyg Message-ID: <703C56B521385C4C9091299BE82357B7EB1EFA79@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_703C56B521385C4C9091299BE82357B7EB1EFA79USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [Megaco] simulating termination on-hook when the gateway goes out of service X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:32:11 -0000 --_000_703C56B521385C4C9091299BE82357B7EB1EFA79USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Matia, I think by SSW you mean MGC. In case of ServiceChange-Forced for ROOT of MG , MGC should clean up all th= e terminations wrt to that MG. Now in the case when MG is restarted MGC should send auditvalue to refresh = all the states of terminations in MG and arm the events for detection of of= fhk/onhk, digitmaps etc. Detetction of offhk/onhk may be triggered in MG by using strict parameter = =3D state in your example which makes MG to report with or without transiti= on. -Arindam From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of= Matia Marcu Sent: Thursday, April 14, 2011 4:36 AM To: megaco@ietf.org Subject: [Megaco] simulating termination on-hook when the gateway goes out = of service Let's consider the case of two terminations involved in a conversation when= the virtual gateway serving them is restarted. In this case, when the GW is restored to service, most SSWs are able to han= dle correctly the terminations that have been off-hook at the time of the G= W restart. But some SSWs stop referring to these terminations after the GW is back in = service. The explanation was that, before sending ServiceChange - Forced on= ROOT, the GW should have sent a fictional on-hook notification for each te= rmination in off-hook state. We think that, in the spirit of H.248, the GW should not simulate on-hook w= hen the termination is off-hook. Is our behaviour correct? Many thanks. Best regards, Matia NOTICE: This email and any files transmitted with it are Enablence and Tele= data-Networks confidential and intended solely for the use of the individua= l or entity to whom they are addressed. If you have received this email in = error please notify the sender. This message contains Enablence and Teledat= a-Networks confidential information and is intended only for the individual= named. If you are not the named addressee you should not disseminate, dist= ribute or copy this e-mail. Please notify the sender immediately by e-mail = if you have received this e-mail by mistake and delete this e-mail from you= r system. If you are not the intended recipient you are notified that discl= osing, copying, distributing or taking any action in reliance on the conten= ts of this information is strictly prohibited. --_000_703C56B521385C4C9091299BE82357B7EB1EFA79USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Matia,

 

I think by SSW you mean MGC.

In case of ServiceChange-Forced for ROOT of MG , MGC should clean up all the terminations wrt to that MG.

Now in the case when MG is restarted MGC should send auditva= lue to refresh all the states of terminations in MG and arm the events for detection of offhk/onhk, digitmaps etc.

Detetction of offhk/onhk may be triggered in MG by using str= ict parameter =3D state in your example which makes MG to report with or withou= t transition.

 

-Arindam

 

From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Matia Marcu
Sent: Thursday, April 14, 2011 4:36 AM
To: megaco@ietf.org
Subject: [Megaco] simulating termination on-hook when the gateway go= es out of service

 

Le= t's consider the case of two terminations involved in a conversation when the virtual gateway serving them is restarted.

 

In= this case, when the GW is restored to service, most SSWs are able to handle correctly the terminations that have been off-hook at the time of the GW restart.

 

Bu= t some SSWs stop referring to these terminations after the GW is back in service. = The explanation was that, before sending ServiceChange – Forced on ROOT, = the GW should have sent a fictional on-hook notification for each termination i= n off-hook state.

 

We= think that, in the spirit of H.248, the GW should not simulate on-hook when the termination is off-hook.

 

Is= our behaviour correct?

 

Ma= ny thanks.

 

Be= st regards,

 

Ma= tia



NOTICE: This email and any files transmitted with it are Enablence and Teledata-Networks confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains Enablence an= d Teledata-Networks confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immed= iately by e-mail if you have received this e-mail by mistake and delete this e-mai= l from your system. If you are not the intended recipient you are notified th= at disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

--_000_703C56B521385C4C9091299BE82357B7EB1EFA79USNAVSXCHMBSA2n_-- From charlie.ross@ericsson.com Mon Apr 25 15:21:19 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7C2E0698 for ; Mon, 25 Apr 2011 15:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msN7pBVMoqQQ for ; Mon, 25 Apr 2011 15:21:19 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 15373E0697 for ; Mon, 25 Apr 2011 15:21:16 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3PKSES1032418 for ; Mon, 25 Apr 2011 15:28:20 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.252]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 25 Apr 2011 16:28:13 -0400 From: Charlie Ross To: "megaco@ietf.org" Date: Mon, 25 Apr 2011 16:28:12 -0400 Thread-Topic: Error in H.248.41 IP Realm Availability package definition? Thread-Index: AcwDh0xbSIoVeoBhSEq3rqV7d3N9dQ== Message-ID: <4C9A0A1285A73648BBB8707F62E26A2F50582EFFEF@EUSAACMS0714.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4C9A0A1285A73648BBB8707F62E26A2F50582EFFEFEUSAACMS0714e_" MIME-Version: 1.0 Subject: [Megaco] Error in H.248.41 IP Realm Availability package definition? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 22:21:19 -0000 --_000_4C9A0A1285A73648BBB8707F62E26A2F50582EFFEFEUSAACMS0714e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, In H.248.41 Amendment 1, the IP Realm Availability (ipra) package is define= d as extending the IP Domain Connection (ipdc) package. IP Realm Availabil= ity has a property, "available realms" (ar), that is assigned binary proper= ty ID 0x0001. This appears to clash with the inherited "realm" property th= at is assigned property ID 0x0001 in the parent IP Domain Connection packag= e. From other examples of package extension that I have seen, it seems tha= t the available realms property should have been given a binary ID that is = unique within the IP Realm Availability definition, such as 0x0002. This w= ould allow both properties to be referenced through IP Realm Availability [= package ID: 0x00e0]. ipra/realm [0x00e00001] ipra/ar [0x00e00001? or 0x00e00002] Is this possibly an oversight in the standard or is there some other way to= distinguish these properties within IP Realm Availability when using binar= y encoding? Thanks for your insights, Charlie Ross Media Gateway Design Architect Ericsson BCAM Business Unit email: charlie.ross@ericsson.com --_000_4C9A0A1285A73648BBB8707F62E26A2F50582EFFEFEUSAACMS0714e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
In H.248.41 Amendment 1, the IP Realm Availability (ipra) package is d= efined as extending the IP Domain Connection (ipdc) package.  IP Realm= Availability has a property, "available realms" (ar), that is as= signed binary property ID 0x0001.  This appears to clash with the inherited "realm" property that is assigned pro= perty ID 0x0001 in the parent IP Domain Connection package.  From othe= r examples of package extension that I have seen, it seems that the availab= le realms property should have been given a binary ID that is unique within the IP Realm Availability definition, such as 0x00= 02.  This would allow both properties to be referenced through IP Real= m Availability [package ID: 0x00e0].
 
ipra/realm [0x00e00001]
ipra/ar [0x00e00001?  or 0x00e00002]
 
Is this possibly an oversight in the standard or is there some other w= ay to distinguish these properties within IP Realm Availability when using = binary encoding?
 
Thanks for your insights,
 
C= harlie Ross
Media Gateway Design Arc= hitect
Ericsson BCAM Business U= nit
email: charlie.ross@ericsson.com
 
 --_000_4C9A0A1285A73648BBB8707F62E26A2F50582EFFEFEUSAACMS0714e_-- From Christian.Groves@nteczone.com Tue Apr 26 19:06:09 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCBFE072B for ; Tue, 26 Apr 2011 19:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPte7txa7zIM for ; Tue, 26 Apr 2011 19:06:08 -0700 (PDT) Received: from cserver5.myshophosting.com (175-107-161-1.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F556E075E for ; Tue, 26 Apr 2011 19:06:08 -0700 (PDT) Received: from ppp118-209-54-214.lns20.mel4.internode.on.net ([118.209.54.214] helo=[192.168.0.2]) by cserver5.myshophosting.com with esmtp (Exim 4.69) (envelope-from ) id 1QEu8g-0002NR-R6; Wed, 27 Apr 2011 12:06:02 +1000 Message-ID: <4DB77A6F.7020803@nteczone.com> Date: Wed, 27 Apr 2011 12:07:43 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: megaco@ietf.org References: <4C9A0A1285A73648BBB8707F62E26A2F50582EFFEF@EUSAACMS0714.eamcs.ericsson.se> In-Reply-To: <4C9A0A1285A73648BBB8707F62E26A2F50582EFFEF@EUSAACMS0714.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Megaco] Error in H.248.41 IP Realm Availability package definition? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 02:06:09 -0000 Hello Charlie, cc: Arturo, Yes it appears that you are correct the available realms property in the ipra package does cause a conflict. It either should be binary ID 0x0002 or the package extension should be removed in order to address the issue. Ericsson was the original editor of this work item. This Recommendation is also used by Tispan/3GPP so we would need to consider this when deciding on a path to take. Removing the extension is probably the safest path to take. Any other opinions? Regards, Christian On 26/04/2011 6:28 AM, Charlie Ross wrote: > Hello, > In H.248.41 Amendment 1, the IP Realm Availability (ipra) package is > defined as extending the IP Domain Connection (ipdc) package. IP > Realm Availability has a property, "available realms" (ar), that is > assigned binary property ID 0x0001. This appears to clash with the > inherited "realm" property that is assigned property ID 0x0001 in the > parent IP Domain Connection package. From other examples of package > extension that I have seen, it seems that the available realms > property should have been given a binary ID that is unique within the > IP Realm Availability definition, such as 0x0002. This would allow > both properties to be referenced through IP Realm Availability > [package ID: 0x00e0]. > ipra/realm [0x00e00001] > ipra/ar [0x00e00001? or 0x00e00002] > Is this possibly an oversight in the standard or is there some other > way to distinguish these properties within IP Realm Availability when > using binary encoding? > Thanks for your insights, > /*Charlie Ross*/ > Media Gateway Design Architect > Ericsson BCAM Business Unit > _email_: charlie.ross@ericsson.com > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco From arturo.martin-de-nicolas@ericsson.com Fri Apr 29 02:45:50 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1D4E06B9 for ; Fri, 29 Apr 2011 02:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij6X0m7UDjCG for ; Fri, 29 Apr 2011 02:45:46 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 481F6E0678 for ; Fri, 29 Apr 2011 02:45:45 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-3e-4dba88c83954 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EF.E4.11171.8C88ABD4; Fri, 29 Apr 2011 11:45:44 +0200 (CEST) Received: from ESESSCMS0365.eemea.ericsson.se ([169.254.1.220]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 29 Apr 2011 11:45:40 +0200 From: Arturo Martin De Nicolas To: Christian Groves , "megaco@ietf.org" Date: Fri, 29 Apr 2011 11:45:39 +0200 Thread-Topic: [Megaco] Error in H.248.41 IP Realm Availability package definition? Thread-Index: AcwEf9XD3B7LjXQYQ9+RXGYfGxrERQB0UGAg Message-ID: <126AED987D19E148BBA558BE393ADF15E0F8F53F@ESESSCMS0365.eemea.ericsson.se> References: <4C9A0A1285A73648BBB8707F62E26A2F50582EFFEF@EUSAACMS0714.eamcs.ericsson.se> <4DB77A6F.7020803@nteczone.com> In-Reply-To: <4DB77A6F.7020803@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Megaco] Error in H.248.41 IP Realm Availability package definition? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 09:45:50 -0000 Hi Christian, Charlie, Thanks for the info. Yes, seems this was unfortunately overlooked. At this stage I tend to agree with you, Christian, that it's probably safer= to remove the extension.=20 I guess this is a good forum for companies to state if they have an opinion= . We ourselves may also come back. Best regards, Arturo =20 -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com]=20 Sent: Wednesday, April 27, 2011 4:08 AM To: megaco@ietf.org Cc: Arturo Martin De Nicolas Subject: Re: [Megaco] Error in H.248.41 IP Realm Availability package defin= ition? Hello Charlie, cc: Arturo, Yes it appears that you are correct the available realms property in the ip= ra package does cause a conflict. It either should be binary ID 0x0002 or t= he package extension should be removed in order to address the issue. Erics= son was the original editor of this work item. This Recommendation is also = used by Tispan/3GPP so we would need to consider this when deciding on a pa= th to take. Removing the extension is probably the safest path to take. Any other opini= ons? Regards, Christian On 26/04/2011 6:28 AM, Charlie Ross wrote: > Hello, > In H.248.41 Amendment 1, the IP Realm Availability (ipra) package is=20 > defined as extending the IP Domain Connection (ipdc) package. IP=20 > Realm Availability has a property, "available realms" (ar), that is=20 > assigned binary property ID 0x0001. This appears to clash with the=20 > inherited "realm" property that is assigned property ID 0x0001 in the=20 > parent IP Domain Connection package. From other examples of package=20 > extension that I have seen, it seems that the available realms=20 > property should have been given a binary ID that is unique within the=20 > IP Realm Availability definition, such as 0x0002. This would allow=20 > both properties to be referenced through IP Realm Availability=20 > [package ID: 0x00e0]. > ipra/realm [0x00e00001] > ipra/ar [0x00e00001? or 0x00e00002] > Is this possibly an oversight in the standard or is there some other=20 > way to distinguish these properties within IP Realm Availability when=20 > using binary encoding? > Thanks for your insights, > /*Charlie Ross*/ > Media Gateway Design Architect > Ericsson BCAM Business Unit > _email_: charlie.ross@ericsson.com > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco From charlie.ross@ericsson.com Fri Apr 29 09:33:57 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C14E06AD for ; Fri, 29 Apr 2011 09:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpotdf39Kt5t for ; Fri, 29 Apr 2011 09:33:52 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1232BE069F for ; Fri, 29 Apr 2011 09:33:52 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3TGXmJk022372 for ; Fri, 29 Apr 2011 11:33:51 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.252]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 29 Apr 2011 12:33:45 -0400 From: Charlie Ross To: "megaco@ietf.org" Date: Fri, 29 Apr 2011 12:33:45 -0400 Thread-Topic: Error in H.248.41 IP Realm Availability package Thread-Index: AcwFDdH+7j5NQ3AxQLG8buSgqgWUywBei/RQ Message-ID: <4C9A0A1285A73648BBB8707F62E26A2F505859CA2A@EUSAACMS0714.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Megaco] Error in H.248.41 IP Realm Availability package X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 16:33:57 -0000 For what it's worth, I agree that removing the extension relationship is pr= obably the way to go. The IP Realm Availability package definition actuall= y makes references to the "ipdc/realm" property as though the latter was a = exclusively part a separate package rather than being inherited through ex= tension. Charlie Ross Media Gateway Design Architect Ericsson BCAM Business Unit email: charlie.ross@ericsson.com > Hello Charlie, cc: Arturo, >=20 > Yes it appears that you are correct the available realms property in the = ipra package does cause a conflict. It > either should be binary ID 0x0002 = or the package extension should be removed in order to address the issue. >= > > Ericsson was the original editor of this work item. This Recommendatio= n is also used by Tispan/3GPP so we would > need to consider this when deci= ding on a path to take. >=20 > Removing the extension is probably the safest path to take. Any other opi= nions? >=20 > Regards, Christian >=20 > On 26/04/2011 6:28 AM, Charlie Ross wrote: > > Hello, > > In H.248.41 Amendment 1, the IP Realm Availability (ipra) package is=20 > > defined as extending the IP Domain Connection (ipdc) package. IP=20 > > Realm Availability has a property, "available realms" (ar), that is=20 > > assigned binary property ID 0x0001. This appears to clash with the=20 > > inherited "realm" property that is assigned property ID 0x0001 in the=20 > > parent IP Domain Connection package. From other examples of package=20 > > extension that I have seen, it seems that the available realms=20 > > property should have been given a binary ID that is unique within the=20 > > IP Realm Availability definition, such as 0x0002. This would allow=20 > > both properties to be referenced through IP Realm Availability=20 > > [package ID: 0x00e0]. > > ipra/realm [0x00e00001] > > ipra/ar [0x00e00001? or 0x00e00002] > > Is this possibly an oversight in the standard or is there some other=20 > > way to distinguish these properties within IP Realm Availability when=20 > > using binary encoding? > > Thanks for your insights, > > /*Charlie Ross*/ > > Media Gateway Design Architect > > Ericsson BCAM Business Unit > > _email_: charlie.ross@ericsson.com