Hi=20 there

I have a = question=20 concerning the validity of adding an error descriptor in a command response= =20 within a stream descriptor - could the list please let me know if this shou= ld be=20 valid Megaco (v3)?

When adding or modifying a multi-stream=20 termination, we may identify an error with some subset of the streams. = ; In=20 this case, where should the error descriptor(s) be located? Specifically, is it= valid=20 to include an error descriptor within a stream descriptor?

For example, a termination with id "ip/1" = has three=20 streams (1, 2 and 3). A request to modify all three streams can be=20 accommodated on stream 2, but fails for stream 1 and stream 3. The=20 response I would like to send is as follows:

!/2=20 [16.16.16.16]:1
P=3D11{
C=3D200{
MF=3Dip/1{
M{
ST=3D1{
ER= =3D449{"Unsupported=20 or Unknown Parameter or Property Value"}},
ST=3D3{
ER=3D449{"Unsuppor= ted or=20 Unknown Parameter or Property Value"}}
}}}}

The relevant part of the ABNF seems to suggest that an error descriptor= is not=20 a valid streamParm. I believe=20 this makes the above in= valid=20 Megaco.

However, the "H.248 Sub-series Implementer= s' Guide"=20 says, in section 7.1.20:

An Error Descr= iptor shall=20 be specified at the "deepest level" that is semantically appropriate for th= e=20 error being described ...

...

If the error being describ= ed can be=20 determined to be at a descriptor level, the Error Descriptor may be returne= d at=20 the descriptor level.

Does this= indicate=20 that stream-scope error descriptors are, in fact, allowed?

Thanks in advance for your=20 input

Mike Dell

Data Connection Ltd.<= SPAN=20 class=3D149211010-29042009>

--_000_44EE1E31095AE349AC6C3C0B69FFBF02837179E82BENFIMBOX1adda_-- From sushilku@cisco.com Wed Apr 29 01:43:04 2009 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEACD28C0F9 for ; Wed, 29 Apr 2009 01:43:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj1OtJoU+Ham for ; Wed, 29 Apr 2009 01:43:00 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 86F7828C14D for ; Wed, 29 Apr 2009 01:42:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,265,1238976000"; d="scan'208,217";a="73820686" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 29 Apr 2009 08:44:19 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3T8iJJf025526 for ; Wed, 29 Apr 2009 01:44:19 -0700 Received: from sj-webmail-12.cisco.com (sj-webmail-12.cisco.com [171.70.170.227]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3T8iJGP025513 for ; Wed, 29 Apr 2009 08:44:19 GMT Received: from sj-webmail-12.cisco.com (localhost.localdomain [127.0.0.1]) by sj-webmail-12.cisco.com (8.13.1/8.13.1) with ESMTP id n3T8iJEB008181 for ; Wed, 29 Apr 2009 01:44:19 -0700 Received: from sj-webmail-12.cisco.com (root@localhost) by sj-webmail-12.cisco.com (8.13.1/8.13.1/Submit) with ESMTP id n3T8iJl4008180 for ; Wed, 29 Apr 2009 01:44:19 -0700 Received: from sushilkuwxp02 ( [10.78.164.161]) by sj-webmail-12.cisco.com (Scalix SMTP Relay 10.0.5.3) via ESMTP; Wed, 29 Apr 2009 01:44:19 -0700 (PDT) Date: Wed, 29 Apr 2009 14:14:49 +0530 From: Sushil Kumar To: Message-ID: <003701c9c8a6$c2a77310$47f65930$@com> x-scalix-Hops: 1 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcnIpsCyiEXOlUWITuKFlhY8BJBpbA== MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C9C8D4.DC5FAF10" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9028; t=1240994659; x=1241858659; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sushilku@cisco.com; z=From:=20Sushil=20Kumar=20 |Subject:=20Query=20Regarding=20MG=20-MGC=20behavior |Sender:=20; bh=Pei1DMpAFG5ls2oPd5WdxGN3u0ivlqVSWWwIoTVJpic=; b=ILOTG00TJ/824aODkp0gp7+y0QpWNyYAhnqqpSaJdQu5fim9MA5TBKNOWW TxY5D29nzovS2HpKlvCuvhGa1pwYiEGqObeflzkCylwVufEeqYYScJ2DbpCC R/Lna8cgSW; Authentication-Results: sj-dkim-2; header.From=sushilku@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Mailman-Approved-At: Wed, 29 Apr 2009 21:24:56 -0700 Subject: [Megaco] Query Regarding MG -MGC behavior X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 08:45:13 -0000 ------=_NextPart_000_0038_01C9C8D4.DC5FAF10 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Hi All, I had a query regarding MG - MGC behavior in H.248 Scenario is as follows: 1. MG is registered with only one MGC (say MGC1) and MGC1 is in redundant mode (i.e. it has a standby MGC2 ) 2. MG initiate Service change request "901" towards MGC1 and MGC1 in reply sends handoff to MG with MGCIdToTry = MGC2 . 3. MG is now trying to register with MGC2 with message "903". 4. MGC2 ack the service change request from MG and after that there is no message exchange between MG and MGC2 and in the mean time ITO expired. 5. Therefore MG now tries to register again with MGC1 with service change request "909 MGC Impending Failure" 6. MGC doesn't respond to this serviceChange request. MG performs several retry for this above service change request in step 5. 7. To this MGC1 sends error =506 { "Number of TransactionPendings Exceeded" } 8. Now what should MG do in response to this error ? 9. Should MG again retry to register itself with standby MGC2 considering its a failed registration attempt ? Or In response of this error=506 , it should go to Out of service state considering it as failure in response of service change request? Any help on this is really appreciated. Thanks in advance. Regards Sushil ------=_NextPart_000_0038_01C9C8D4.DC5FAF10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi All,

I had a query regarding MG - MGC behavior in H.248

Scenario is as follows:

1. &nbs= p; MG is registered with only one MGC (say MGC1) and MGC1 is in red= undant mode (i.e. it has a standby MGC2 )

2. &nbs= p; MG initiate Service change request “901” towards MGC1 and M= GC1 in reply sends handoff to MG with MGCIdToTry =3D MGC2 .

3. &nbs= p; MG is now trying to register with MGC2 with message “903”.=

4. &nbs= p; MGC2 ack the service change request from MG and after that there is no m= essage exchange between MG and MGC2 and in the mean time ITO expired= =2E

5. &nbs= p; Therefore MG now tries to register again with MGC1 with service change reques= t “909 MGC Impending Failure”

6. &nbs= p; MGC doesn’t respond to this serviceChange request. MG performs se= veral retry for this above service change request in step 5.

7. &nbs= p; To this MGC1 sends error =3D506 { "Number of TransactionPendings Exceeded" }

8. &nbs= p; Now what should MG do in response to this error ?

9. &nbs= p; Should MG again retry to register itself with standby MGC2 considering its= a failed registration attempt ?

&nbs= p; In response of this error=3D506 , it should go to Out of service state= considering it as failure in response of service change request?

Any help on this is rea= lly appreciated.

Thanks in advance.

Regards

Sushil

------=_NextPart_000_0038_01C9C8D4.DC5FAF10-- From Albrecht.Schwarz@alcatel-lucent.de Thu Apr 30 00:43:45 2009 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF2443A6CAC for ; Thu, 30 Apr 2009 00:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+-PgO6Pf1Zn for ; Thu, 30 Apr 2009 00:43:40 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id DD57C3A6C5F for ; Thu, 30 Apr 2009 00:43:39 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3U7iiNO026959; Thu, 30 Apr 2009 09:44:53 +0200 Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 09:44:43 +0200 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_01C9C967.867E4B58" Date: Thu, 30 Apr 2009 09:44:42 +0200 Message-ID: In-Reply-To: <003701c9c8a6$c2a77310$47f65930$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Query Regarding MG -MGC behavior Thread-Index: AcnIpsCyiEXOlUWITuKFlhY8BJBpbAAv2Ljw References: <003701c9c8a6$c2a77310$47f65930$@com> From: "Schwarz Albrecht" To: "Sushil Kumar" , X-OriginalArrivalTime: 30 Apr 2009 07:44:43.0722 (UTC) FILETIME=[86CDD2A0:01C9C967] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Megaco] Query Regarding MG -MGC behavior X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:43:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C967.867E4B58 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The right "MG strategy" is beyond the H.248 protocol itself, because dependent in engineering networks with regards to service/system availability. It is almost impossible to define a single (qualitative) behaviour on a generic level. You have to take into account the quantitative performance of your MGC entitities concering system availability (i.e., the estimated time or ratio of In-Service periods vs expected Out-of-Service periods). =20 On the highest level you could categorize MGCs (and MGs) in HA-MGC and LA-MGC implementations (high available vs low available). =20 Assuming that both MGCs got correct H.248 protocol implementations, it looks like that both MGC entities are rather LA-MGC types in your example. That type of info would go into the configuration of timers, number of reattempts, etc ... and even the EMS/NMS behaviour. =20 -Albrecht =20 =20 PS H.248 does not know the term of a "standby" node, you should rather use the H.248 terms "primary", "first secondary", etc. E.g., a primary MGC may itself implemented in a redundant manner (in order to achieve HA) by an internal architecture with a working & protection plane. See e.g. Fig. 1/H.Sup7. =20 ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Sushil Kumar Sent: Mittwoch, 29. April 2009 10:45 To: megaco@ietf.org Subject: [Megaco] Query Regarding MG -MGC behavior =09 =09 Hi All, =20 I had a query regarding MG - MGC behavior in H.248 =20 Scenario is as follows: =20 1. MG is registered with only one MGC (say MGC1) and MGC1 is in redundant mode (i.e. it has a standby MGC2 ) 2. MG initiate Service change request "901" towards MGC1 and MGC1 in reply sends handoff to MG with MGCIdToTry =3D MGC2 . 3. MG is now trying to register with MGC2 with message "903". 4. MGC2 ack the service change request from MG and after that there is no message exchange between MG and MGC2 and in the mean time ITO expired. 5. Therefore MG now tries to register again with MGC1 with service change request "909 MGC Impending Failure" 6. MGC doesn't respond to this serviceChange request. MG performs several retry for this above service change request in step 5. 7. To this MGC1 sends error =3D506 { "Number of TransactionPendings Exceeded" }=20 8. Now what should MG do in response to this error ? 9. Should MG again retry to register itself with standby MGC2 considering its a failed registration attempt ? Or In response of this error=3D506 , it should go to Out of service state considering it as failure in response of service change request? =20 =20 Any help on this is really appreciated. =20 Thanks in advance. =20 =20 Regards Sushil =20 ------_=_NextPart_001_01C9C967.867E4B58 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The right "MG strategy" is beyond the H.248 = protocol=20 itself, because dependent in engineering networks with regards to = service/system=20 availability.

It is almost impossible to define a single=20 (qualitative) behaviour on a generic level.

You have to take into account the = quantitative=20 performance of your MGC entitities concering system availability (i.e., = the=20 estimated time or ratio of In-Service periods vs expected Out-of-Service = periods).

On the highest level you could categorize = MGCs (and=20 MGs) in HA-MGC and LA-MGC implementations (high available vs low=20 available).

Assuming that both MGCs got correct H.248 = protocol=20 implementations, it looks like that both MGC entities are rather LA-MGC = types in=20 your example.

That type of info would go into the = configuration of=20 timers, number of reattempts, etc ... and even the EMS/NMS=20 behaviour.

-Albrecht

H.248 does not know the term of a "standby" = node, you=20 should rather use the H.248 terms "primary", "first secondary",=20 etc.

E.g., a primary MGC may itself implemented in a = redundant=20 manner (in order to achieve HA) by an internal architecture with a = working &=20 protection plane. See e.g. Fig. 1/H.Sup7.

From: megaco-bounces@ietf.org=20 [mailto:megaco-bounces@ietf.org] On Behalf Of Sushil=20 Kumar
Sent: Mittwoch, 29. April 2009 10:45
To:=20 megaco@ietf.org
Subject: [Megaco] Query Regarding MG -MGC=20 behavior

Hi All,

I had a query regarding MG - MGC behavior in=20 H.248

Scenario is as follows:

1.      =20 MG is registered with only one MGC = (say=20 MGC1) and MGC1 is in redundant mode (i.e. it has a standby MGC2=20 )

2.      =20 MG initiate Service change request = “901” towards=20 MGC1 and MGC1 in reply sends handoff to MG with MGCIdToTry =3D = MGC2=20 .

3.      =20 MG is now trying to register with MGC2 = with=20 message “903”.

4.      =20 MGC2 ack the service change request from = MG and=20 after that there is no message exchange between MG and MGC2 and = in the=20 mean time ITO expired.

5.      =20 Therefore MG now tries to register again with=20 MGC1 with service change request “909 MGC Impending=20 Failure”

6.      =20 MGC doesn’t respond to this = serviceChange request. MG=20 performs several retry for this above service change request in = step 5.=20

7.      =20 To this MGC1 sends error =3D506 { = "Number of=20 TransactionPendings Exceeded" }

8.      =20 Now what should MG do in response to this = error=20 ?

9.      =20 Should MG again retry to register = itself with=20 standby MGC2 considering its a failed registration attempt=20 ?

Or

=20       In response of this error=3D506 = ,=20 it should go to Out of service state considering it as failure = in=20 response of service change request?

Any help on this is = really=20 appreciated.

Thanks in advance.

Regards

Sushil

------_=_NextPart_001_01C9C967.867E4B58-- From Michael.Dell@dataconnection.com Thu Apr 30 04:26:40 2009 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52653A71F8 for ; Thu, 30 Apr 2009 04:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTMpySIOC5Go for ; Thu, 30 Apr 2009 04:26:40 -0700 (PDT) Received: from enfiets2.dataconnection.com (enfiets2.dataconnection.com [192.91.191.39]) by core3.amsl.com (Postfix) with ESMTP id 0CC883A71FA for ; Thu, 30 Apr 2009 04:26:28 -0700 (PDT) Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets2.dataconnection.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 30 Apr 2009 12:30:51 +0100 Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Thu, 30 Apr 2009 12:27:50 +0100 From: Michael Dell To: "megaco@ietf.org" Date: Thu, 30 Apr 2009 12:25:56 +0100 Thread-Topic: Error descriptors within stream descriptors Thread-Index: AcnIuFGoOt2dOx9QQAGkoBQ19PUUXgAzhCjg Message-ID: <44EE1E31095AE349AC6C3C0B69FFBF02837179F0E5@ENFIMBOX1.ad.datcon.co.uk> 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_44EE1E31095AE349AC6C3C0B69FFBF02837179F0E5ENFIMBOX1adda_" MIME-Version: 1.0 Subject: [Megaco] Error descriptors within stream descriptors X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 11:26:40 -0000 --_000_44EE1E31095AE349AC6C3C0B69FFBF02837179F0E5ENFIMBOX1adda_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there I have a question concerning the validity of adding an error descriptor in = a command response within a stream descriptor - could the list please let m= e know if this should be valid Megaco (v3)? When adding or modifying a multi-stream termination, we may identify an err= or with some subset of the streams. In this case, where should the error d= escriptor(s) be located? Specifically, is it valid to include an error des= criptor within a stream descriptor? For example, a termination with id "ip/1" has three streams (1, 2 and 3). = A request to modify all three streams can be accommodated on stream 2, but = fails for stream 1 and stream 3. The response I would like to send is as f= ollows: !/2 [16.16.16.16]:1 P=3D11{ C=3D200{ MF=3Dip/1{ M{ ST=3D1{ ER=3D449{"Unsupported or Unknown Parameter or Property Value"}}, ST=3D3{ ER=3D449{"Unsupported or Unknown Parameter or Property Value"}} }}}} The relevant part of the ABNF seems to suggest that an error descriptor is = not a valid streamParm. I believe this makes the above invalid Megaco. However, the "H.248 Sub-series Implementers' Guide" says, in section 7.1.20= : An Error Descriptor shall be specified at the "deepest level" that is seman= tically appropriate for the error being described ... ... If the error being described can be determined to be at a descriptor level,= the Error Descriptor may be returned at the descriptor level. Does this indicate that stream-scope error descriptors are, in fact, allowe= d? Thanks in advance for your input Mike Dell Data Connection Ltd. --_000_44EE1E31095AE349AC6C3C0B69FFBF02837179F0E5ENFIMBOX1adda_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi=20 there

The relevant part of the ABNF seems to suggest that an error descriptor= is not=20 a valid streamParm. I believe=20 this makes the above in= valid=20 Megaco.

However, the "H.248 Sub-series Implementer= s' Guide"=20 says, in section 7.1.20:

An Error Descr= iptor shall=20 be specified at the "deepest level" that is semantically appropriate for th= e=20 error being described ...

...

If the error being describ= ed can be=20 determined to be at a descriptor level, the Error Descriptor may be returne= d at=20 the descriptor level.

Does this= indicate=20 that stream-scope error descriptors are, in fact, allowed?

Thanks in advance for your=20 input

Mike Dell

Data Connection Ltd.

--_000_44EE1E31095AE349AC6C3C0B69FFBF02837179F0E5ENFIMBOX1adda_-- From sudhanshu.garg@aricent.com Thu Apr 30 05:17:40 2009 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A62428C11A for ; Thu, 30 Apr 2009 05:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pL0Fj2i9N5P9 for ; Thu, 30 Apr 2009 05:17:39 -0700 (PDT) Received: from jaguar.aricent.com (inoutbound.aricent.com [125.21.164.247]) by core3.amsl.com (Postfix) with ESMTP id CB8C73A7204 for ; Thu, 30 Apr 2009 05:17:37 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id n3UC7xvF009605 for ; Thu, 30 Apr 2009 17:38:00 +0530 Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id n3UC7xgJ009550 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 30 Apr 2009 17:37:59 +0530 Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.136]) with mapi; Thu, 30 Apr 2009 17:48:53 +0530 From: Sudhanshu Garg To: Michael Dell , "megaco@ietf.org" Date: Thu, 30 Apr 2009 17:48:51 +0530 Thread-Topic: Error descriptors within stream descriptors Thread-Index: AcnIuFGoOt2dOx9QQAGkoBQ19PUUXgAzhCjgAABLTVA= Message-ID: <5DF2A48952E63B43ACC2EC34AA8C25B00AB0347AA5@GUREXMB01.ASIAN.AD.ARICENT.COM> References: <44EE1E31095AE349AC6C3C0B69FFBF02837179F0E5@ENFIMBOX1.ad.datcon.co.uk> In-Reply-To: <44EE1E31095AE349AC6C3C0B69FFBF02837179F0E5@ENFIMBOX1.ad.datcon.co.uk> 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_5DF2A48952E63B43ACC2EC34AA8C25B00AB0347AA5GUREXMB01ASIA_" MIME-Version: 1.0 Subject: Re: [Megaco] Error descriptors within stream descriptors X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 12:17:40 -0000 --_000_5DF2A48952E63B43ACC2EC34AA8C25B00AB0347AA5GUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, Putting error descriptor inside another descriptor is not possible. Regards, Sudhanshu Garg Engineering Project Manager Ph: +91 124 4176218 Mob: +91 9999500798 A R I C E N T ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of= Michael Dell Sent: Thursday, April 30, 2009 4:56 PM To: megaco@ietf.org Subject: [Megaco] Error descriptors within stream descriptors Hi there I have a question concerning the validity of adding an error descriptor in = a command response within a stream descriptor - could the list please let m= e know if this should be valid Megaco (v3)? When adding or modifying a multi-stream termination, we may identify an err= or with some subset of the streams. In this case, where should the error d= escriptor(s) be located? Specifically, is it valid to include an error des= criptor within a stream descriptor? For example, a termination with id "ip/1" has three streams (1, 2 and 3). = A request to modify all three streams can be accommodated on stream 2, but = fails for stream 1 and stream 3. The response I would like to send is as f= ollows: !/2 [16.16.16.16]:1 P=3D11{ C=3D200{ MF=3Dip/1{ M{ ST=3D1{ ER=3D449{"Unsupported or Unknown Parameter or Property Value"}}, ST=3D3{ ER=3D449{"Unsupported or Unknown Parameter or Property Value"}} }}}} The relevant part of the ABNF seems to suggest that an error descriptor is = not a valid streamParm. I believe this makes the above invalid Megaco. However, the "H.248 Sub-series Implementers' Guide" says, in section 7.1.20= : An Error Descriptor shall be specified at the "deepest level" that is seman= tically appropriate for the error being described ... ... If the error being described can be determined to be at a descriptor level,= the Error Descriptor may be returned at the descriptor level. Does this indicate that stream-scope error descriptors are, in fact, allowe= d? Thanks in advance for your input Mike Dell Data Connection Ltd. ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged 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 m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." --_000_5DF2A48952E63B43ACC2EC34AA8C25B00AB0347AA5GUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mike,

Putting error descriptor inside anothe= r descriptor is not possible.

Regards,

Sudhanshu Garg

Engineering P= roject Manager

Ph: +91 124 4176218

Mob: +91 9999500798

A R I C E N T

From: mega= co-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Michael Dell Sent: Thursday, April 30, 2009 4= :56 PM
To: megaco@ietf.org
Subject: [Megaco] Error desc= riptors within stream descriptors

Hi there

I have a question concerning the validity of adding an e= rror descriptor in a command response within a stream descriptor - could th= e list please let me know if this should be valid Megaco (v3)?

When adding or modifying a multi-stream termination, we = may identify an error with some subset of the streams. In this case, = where should the error descriptor(s) be located? Specifically, is it valid to include an error descriptor= within a stream descriptor?

For example, a termination with id "ip/1" has = three streams (1, 2 and 3). A request to modify all three streams can= be accommodated on stream 2, but fails for stream 1 and stream 3. The response I would like to send is as follo= ws:<= o:p>

!/2 [16.16.16.16]:1
P=3D11{
C=3D200{
MF=3Dip/1{
M{
ST=3D1{
ER=3D449{"Unsupported or Unknown Parameter or Property Value"}},<= br> ST=3D3{
ER=3D449{"Unsupported or Unknown Parameter or Property Value"}} }}}}=

The relevant part of the ABNF seems to suggest that= an error descriptor is not a valid streamParm. I believe this&n= bsp;makes the above invalid Megaco.

However, the "H.248 Sub-series Implementers' Guide&= quot; says, in section 7.1.20:

An Error Descriptor shall be specifie= d at the "deepest level" that is semantically appropriate for the= error being described ...

...

If the error being described can be d= etermined to be at a descriptor level, the Error Descriptor may be returned= at the descriptor level.

Does this indicate that stream-scope error descriptors a= re, in fact, allowed?

Thanks in advance for your input

Mike Dell

Data Connection Ltd.

"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error,please notify the originator immediately. If you = are not the intended recipient, you are notified that you are strictly proh= ibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
--_000_5DF2A48952E63B43ACC2EC34AA8C25B00AB0347AA5GUREXMB01ASIA_--