From megaco-bounces@ietf.org  Thu Jul  1 01:47:32 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17294
	for <megaco-archive@lists.ietf.org>; Thu, 1 Jul 2004 01:47:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BfuNC-0004MK-D6; Thu, 01 Jul 2004 01:44:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BfuIe-0003Ta-W6
	for megaco@megatron.ietf.org; Thu, 01 Jul 2004 01:39:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17134
	for <megaco@ietf.org>; Thu, 1 Jul 2004 01:39:55 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BfuIc-000467-VA
	for megaco@ietf.org; Thu, 01 Jul 2004 01:39:55 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BfuHZ-0003hv-00
	for megaco@ietf.org; Thu, 01 Jul 2004 01:38:50 -0400
Received: from [202.188.224.18] (helo=icemail8.ao.ericsson.se)
	by ietf-mx with esmtp (Exim 4.12) id 1BfuGQ-0002xt-00
	for megaco@ietf.org; Thu, 01 Jul 2004 01:37:39 -0400
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by icemail8.ao.ericsson.se (8.12.10/8.12.9) with ESMTP id
	i615e2HW082452; Thu, 1 Jul 2004 13:40:03 +0800 (MYT)
	(envelope-from christian.groves@ericsson.com)
Received: from ericsson.com (EG2E500202DSEGL [146.11.22.19]) by
	eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange
	Internet Mail Service Version 5.5.2657.72)
	id N1L0YCFZ; Thu, 1 Jul 2004 15:37:04 +1000
Message-ID: <40E3A342.6080404@ericsson.com>
Date: Thu, 01 Jul 2004 15:38:10 +1000
X-Sybari-Trust: dad9d8dd 100f6658 db047d19 00000138
From: Christian Groves <christian.groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aleksandr Ryabin <kengr@motorola.com>
Subject: Re: [Megaco] Which error to use for errors in Topology descriptor?
References: <5.2.1.1.0.20040623192010.045dda90@IL06EXM13.corp.mot.com>	<5.2.1.1.0.20040622114309.0476bd50@IL06EXM13.corp.mot.com>	<5.2.1.1.0.20040622114309.0476bd50@IL06EXM13.corp.mot.com>	<5.2.1.1.0.20040623192010.045dda90@IL06EXM13.corp.mot.com>
	<5.2.1.1.0.20040624100246.01cc4630@IL06EXM13.corp.mot.com>
In-Reply-To: <5.2.1.1.0.20040624100246.01cc4630@IL06EXM13.corp.mot.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by icemail8.ao.ericsson.se
	id i615e2HW082452
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
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 <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
Content-Transfer-Encoding: quoted-printable

Hello Aleksandr,

How about:
Additional to H.248.8:

4.2.5x	Error Code #: 522 Name: Invalid Topology
Definition: The MG was unable execute the action as it was unable to appl=
y the=20
requested context topology.
Package: =96
Reference: =96
Error Text in the error Descriptor: <TBD>
Comment: =96

Do people want something to be returned in the Error descriptor? ie. the =
triple=20
that caused the problem. I tend to think that as the "topology" is the gr=
oup of=20
triple its enough not to have anything. Thoughts?

Regards, Christian

Aleksandr Ryabin wrote:

> Hi Christinan,
>=20
> Can we agree on the error code number now and the document this is to=20
> added?
> Can the editor of the appropriate document (i.e. IG, or H.248.8 update)=
=20
> please assign the number?
>=20
> Thanks
>         Aleks
>=20
> At 11:38 PM 6/23/2004, Christian Groves wrote:
>=20
>> Hello Aleksandr,
>>
>> Sounds like a reasonable thing to add.
>>
>> Christian
>>
>> Aleksandr Ryabin wrote:
>>
>>> Hi Christian,
>>> Yes, exactly, "invalid topology" or something like "could not apply=20
>>> topology"
>>> Regards,
>>>         Aleks
>>> At 07:08 PM 6/23/2004, Christian Groves wrote:
>>>
>>>> Hello Aleksandr,
>>>>
>>>> What sort of error were you thinking about?
>>>>
>>>> If there's something wrong with the syntax then this can be covered=20
>>>> with 422 syntax error in action. Invalid termination/stream ID can=20
>>>> be covered by other errors.
>>>>
>>>> Is the error something like "invalid topology" where the MG can't=20
>>>> connect terminations according to the MGC's wishes?
>>>>
>>>> Regards, Christian
>>>>
>>>> Aleksandr Ryabin wrote:
>>>>
>>>>> Hi,
>>>>> Which error should be used to report errors detected within=20
>>>>> TopologyDescriptor?
>>>>> If there are none yet, can one be added to H.248.8?
>>>>> Thanks
>>>>>     Aleks
>>>>>
>>>>> _______________________________________________
>>>>> 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
>=20


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


From mailman-bounces@ietf.org  Thu Jul  1 07:51:59 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17384
	for <megaco-archive@lists.ietf.org>; Thu, 1 Jul 2004 07:51:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Bfxme-000712-Bu
	for megaco-archive@lists.ietf.org; Thu, 01 Jul 2004 05:23:08 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: ietf.org mailing list memberships reminder
From: mailman-owner@ietf.org
To: megaco-archive@ietf.org
X-No-Archive: yes
Message-ID: <mailman.19811.1088672765.3306.mailman@lists.ietf.org>
Date: Thu, 01 Jul 2004 05:06:05 -0400
Precedence: bulk
X-BeenThere: mailman@lists.ietf.org
X-Mailman-Version: 2.1.5
List-Id: Mailman site list <mailman.lists.ietf.org>
X-List-Administrivia: yes
Sender: mailman-bounces@ietf.org
Errors-To: mailman-bounces@ietf.org
Content-Transfer-Encoding: 7bit

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, mailman-request@ietf.org) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

**********************************************************************

NOTE WELL:

Any submission to the IETF intended by the Contributor for publication
as all or part of an IETF Internet-Draft or RFC and any statement made
within the context of an IETF activity is considered an "IETF
Contribution". Such statements include oral statements in IETF
sessions, as well as written and electronic communications made at any
time or place, which are addressed to:

o the IETF plenary session, o any IETF working group or portion
thereof, o the IESG, or any member thereof on behalf of the IESG, o
the IAB or any member thereof on behalf of the IAB, o any IETF mailing
list, including the IETF list itself, any working group
  or design team list, or any other list functioning under IETF
auspices,
o the RFC Editor or the Internet-Drafts function

All IETF Contributions are subject to the rules of RFC 3667 and RFC
3668.

Statements made outside of an IETF session, mailing list or other
function, that are clearly not intended to be input to an IETF
activity, group or function, are not IETF Contributions in the context
of this notice.

Please consult RFC 3667 for details.

*******************************************************************************


If you have questions, problems, comments, etc, send them to
mailman-owner@ietf.org.  Thanks!

Passwords for megaco-archive@lists.ietf.org:

List                                     Password // URL
----                                     --------  
megaco@ietf.org                          rFKd      
https://www1.ietf.org/mailman/options/megaco/megaco-archive%40lists.ietf.org


From megaco-bounces@ietf.org  Thu Jul  1 11:48:05 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12560
	for <megaco-archive@lists.ietf.org>; Thu, 1 Jul 2004 11:48:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Bg32L-0000tg-9q; Thu, 01 Jul 2004 10:59:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg2Be-0006t1-C2
	for megaco@megatron.ietf.org; Thu, 01 Jul 2004 10:05:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29208
	for <megaco@ietf.org>; Thu, 1 Jul 2004 10:05:12 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1Bg2Bd-00009D-Dg
	for megaco@ietf.org; Thu, 01 Jul 2004 10:05:13 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Bg2Ae-0007ZU-00
	for megaco@ietf.org; Thu, 01 Jul 2004 10:04:13 -0400
Received: from motgate.mot.com ([129.188.136.100])
	by ietf-mx with esmtp (Exim 4.12) id 1Bg29a-0006yz-00
	for megaco@ietf.org; Thu, 01 Jul 2004 10:03:06 -0400
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231])
	by motgate.mot.com (Motorola/Motgate) with ESMTP id i61E316H024467;
	Thu, 1 Jul 2004 07:03:01 -0700 (MST)
Received: from smilevm.motorola.com ([10.14.25.162])
	by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i61Du2sr024894; 
	Thu, 1 Jul 2004 08:56:03 -0500
Message-Id: <5.2.1.1.0.20040701095526.04958760@IL06EXM13.corp.mot.com>
X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Thu, 01 Jul 2004 10:00:50 -0400
To: Christian Groves<christian.groves@ericsson.com>, <megaco@ietf.org>
From: Aleksandr Ryabin <kengr@motorola.com>
Subject: Re: [Megaco] Which error to use for errors in Topology
  descriptor?
In-Reply-To: <40E3A342.6080404@ericsson.com>
References: <5.2.1.1.0.20040624100246.01cc4630@IL06EXM13.corp.mot.com>
	<5.2.1.1.0.20040623192010.045dda90@IL06EXM13.corp.mot.com>
	<5.2.1.1.0.20040622114309.0476bd50@IL06EXM13.corp.mot.com>
	<5.2.1.1.0.20040622114309.0476bd50@IL06EXM13.corp.mot.com>
	<5.2.1.1.0.20040623192010.045dda90@IL06EXM13.corp.mot.com>
	<5.2.1.1.0.20040624100246.01cc4630@IL06EXM13.corp.mot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
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
Content-Transfer-Encoding: quoted-printable

Hi Christian,

Sounds good.
Error can contain one, or more triples that caused the problem, i.e:

Error Text in the error Descriptor: invalid triples

Regards,
         Aleks

At 01:38 AM 7/1/2004, Christian Groves wrote:
>Hello Aleksandr,
>
>How about:
>Additional to H.248.8:
>
>4.2.5x  Error Code #: 522 Name: Invalid Topology
>Definition: The MG was unable execute the action as it was unable to apply=
=20
>the requested context topology.
>Package: =AD
>Reference: =AD
>Error Text in the error Descriptor: <TBD>
>Comment: =AD
>
>Do people want something to be returned in the Error descriptor? ie. the=20
>triple that caused the problem. I tend to think that as the "topology" is=
=20
>the group of triple its enough not to have anything. Thoughts?
>
>Regards, Christian
>
>Aleksandr Ryabin wrote:
>
>>Hi Christinan,
>>Can we agree on the error code number now and the document this is to=
 added?
>>Can the editor of the appropriate document (i.e. IG, or H.248.8 update)=20
>>please assign the number?
>>Thanks
>>         Aleks
>>At 11:38 PM 6/23/2004, Christian Groves wrote:
>>
>>>Hello Aleksandr,
>>>
>>>Sounds like a reasonable thing to add.
>>>
>>>Christian
>>>
>>>Aleksandr Ryabin wrote:
>>>
>>>>Hi Christian,
>>>>Yes, exactly, "invalid topology" or something like "could not apply=20
>>>>topology"
>>>>Regards,
>>>>         Aleks
>>>>At 07:08 PM 6/23/2004, Christian Groves wrote:
>>>>
>>>>>Hello Aleksandr,
>>>>>
>>>>>What sort of error were you thinking about?
>>>>>
>>>>>If there's something wrong with the syntax then this can be covered=20
>>>>>with 422 syntax error in action. Invalid termination/stream ID can be=
=20
>>>>>covered by other errors.
>>>>>
>>>>>Is the error something like "invalid topology" where the MG can't=20
>>>>>connect terminations according to the MGC's wishes?
>>>>>
>>>>>Regards, Christian
>>>>>
>>>>>Aleksandr Ryabin wrote:
>>>>>
>>>>>>Hi,
>>>>>>Which error should be used to report errors detected within=20
>>>>>>TopologyDescriptor?
>>>>>>If there are none yet, can one be added to H.248.8?
>>>>>>Thanks
>>>>>>     Aleks
>>>>>>
>>>>>>_______________________________________________
>>>>>>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 Jul  1 15:53:41 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28981
	for <megaco-archive@lists.ietf.org>; Thu, 1 Jul 2004 15:53:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Bg7V3-0000GX-Pu; Thu, 01 Jul 2004 15:45:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg7GR-0002MR-BN
	for megaco@megatron.ietf.org; Thu, 01 Jul 2004 15:30:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28079
	for <megaco@ietf.org>; Thu, 1 Jul 2004 15:30:29 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1Bg7GQ-0004Q2-1o
	for megaco@ietf.org; Thu, 01 Jul 2004 15:30:30 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Bg7FP-00042J-00
	for megaco@ietf.org; Thu, 01 Jul 2004 15:29:28 -0400
Received: from eins.siemens.at ([193.81.246.11])
	by ietf-mx with esmtp (Exim 4.12) id 1Bg7ER-0003J9-00
	for megaco@ietf.org; Thu, 01 Jul 2004 15:28:27 -0400
Received: from vies1kbx.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i61JRvEP026860
	for <megaco@ietf.org>; Thu, 1 Jul 2004 21:27:57 +0200
Received: from vies141a.sie.siemens.at (vies1kbx [158.226.135.174])
	by vies1kbx.sie.siemens.at (8.12.10/8.12.1) with ESMTP id
	i61JRugP001365 for <megaco@ietf.org>; Thu, 1 Jul 2004 21:27:57 +0200
Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id <NBANWFZ2>; Thu, 1 Jul 2004 21:29:33 +0200
Message-ID: <DC363E3C9293D71193BA0002B3CC414C0112DB8D@vies186a.sie.siemens.at>
From: Kalleitner Franz <franz.kalleitner@siemens.com>
To: "'Christian Groves '" <christian.groves@ericsson.com>
Subject: AW: RE : AW: [Megaco] telephony event defintion
Date: Thu, 1 Jul 2004 21:29:32 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
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
Content-Transfer-Encoding: quoted-printable

Hello Christian,

it would be great if we could continue the discussion on that threat.
Based on NGN discussions I assume that sending codelists to a MG will =
be a
common handling in the future, since MGC does not know at inital offer, =
via
which interface the answerer will be connected(
wireline,wireless,wi-fi,....)and deploying sofistictated features. =
Isn't it
?

I think it become very important to handle or negosiate codeclists =
between
MGC and MG.
Since ACodec is defind as "single codec" there is no chance to =
implement
such a behaviour
(except using SDP equivalents or text based encoding)
thanks in advance,=20

regards, Franz


-----Urspr=FCngliche Nachricht-----
Von: Kalleitner Franz=20
Gesendet: Freitag, 25. Juni 2004 11:27
An: 'CHATRAS Bruno FTRD/DAC/ISS'; Christian Groves=20
Cc: BELLING THOMAS; megaco@ietf.org
Betreff: AW: RE : AW: [Megaco] telephony event defintion


Of course, its possible to use SDP equivalents and it seems to be the =
only
way out to solve this problem.

Yes, the question is related to 3GPP TS 29.332.=20
So if there is the necessity to use the SDP equivalents, its not =
possible to
align the BICC procedure with the IMS(SIP) procedures.

Franz

-----Urspr=FCngliche Nachricht-----
Von: CHATRAS Bruno FTRD/DAC/ISS =
[mailto:bruno.chatras@francetelecom.com]
Gesendet: Freitag, 25. Juni 2004 11:01
An: Kalleitner Franz; Christian Groves=20
Cc: BELLING THOMAS; megaco@ietf.org
Betreff: RE : AW: [Megaco] telephony event defintion


Why not using the code point for SDP_A defined in Annex C.11 of =
H.248.1?

Is this question related to 3GPP TS 29.332?

Regards,
Bruno


-----Message d'origine-----
De : megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] De la =
part de
Kalleitner Franz
Envoy=E9 : vendredi 25 juin 2004 09:58
=C0 : 'Christian Groves '; Kalleitner Franz
Cc : BELLING THOMAS; ''megaco@ietf.org' '
Objet : AW: AW: [Megaco] telephony event defintion


Hello Christian,

thanks a lot for you answer.
You are right, for BICC networks its possible to use the tunneling =
solution.
However, we need to find a solution to manage the interworking between =
SIP
and ISUP networks Q.1912.5 or RFC3398 as well the 3GPP 29.163, =
specifying a
SIP-BICC interworking as well. As you proposed, for the BICC interface =
we
want to use the methods defined in Q1950 and Q765.5 but its not =
possible to
use them for the SIP interface. SIP doesn't offer any tunneling in a =
similar
way. Nevertheless its necessary to configure an IP termination =
connected to
a SIP network via H248.=20

So that's the background, why I'm asking these questions concerning =
DTMF
codec and codeclists, because we want to reuse h248 basics as much as
possible to implement the interworking between SIP and ISUP/BICC =
networks.

Do you think there is a chance to solve these two items within H248
standardization?

kind regards
Franz





-----Originalnachricht-----
Von: Christian Groves
An: Kalleitner Franz
Cc: 'megaco@ietf.org'; BELLING THOMAS
Gesendet: 25.06.04 04:16
Betreff: Re: AW: [Megaco] telephony event defintion

Hello Franz,

For BICC networks (where the Acodec is defined in Q.765.5) sending DTMF =
as
per=20
RFC2833 is not needed across Q.1950(H.248). The actual SDP parameters =
used
for=20
the connection are transmitted via IPBCP (Q.1970).

There is a parameter in H.248.1 annex C 0x100F "Payload Type" that may =
be of

some use.

Regards, Christian

Kalleitner Franz wrote:

> I wonder if anybody could respond on that threat!
> Without a codepoint for DTMF, the functionality of RFC2833 cannot be
applied
> for
> network configuration specifing DTMF as an ACodec i.e for codec
negosiation
> purposes!
> A solution for text encoded H248 is available but not for binary.
>=20
> Many thanks in advance
> Franz
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]Im
Auftrag
> von Kalleitner Franz
> Gesendet: Donnerstag, 17. Juni 2004 13:21
> An: 'megaco@ietf.org'
> Betreff: [Megaco] telephony event defintion
>=20
>=20
> Hello megaco-list members,
>=20
> I didn't manage to transfer the media description of the
telephone-event
> (defined in RFC 2833) as a media attribute into ASN.1 format. In SDP=20
> its easily done via a dynamically payload type definition, plus=20
> fmtp,rtpmap for the codec definition Using ASN.1 encoding the payload =

> attribute is defined in H248.1 Annex
C.
> However, an reference pointing to the codec definition is not
available,
> therefore I scanned ITU-T and 3GPP references, but I didn't found any =

> definition for the telephone-event.
>=20
> Probably another had the same problem, with more success than I'm and
may
> send a reply to this threat.
> Many thanks in advance!
>=20
> Franz
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>=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  Tue Jul  6 08:32:10 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10031
	for <megaco-archive@lists.ietf.org>; Tue, 6 Jul 2004 08:32:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Bhohg-0008Bb-Hw; Tue, 06 Jul 2004 08: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 1BhoQ6-0006Lo-74
	for megaco@megatron.ietf.org; Tue, 06 Jul 2004 07:47:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07653
	for <megaco@ietf.org>; Tue, 6 Jul 2004 07:47:23 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BhoQ0-0005Os-IY
	for megaco@ietf.org; Tue, 06 Jul 2004 07:47:24 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BhoPC-00054r-00
	for megaco@ietf.org; Tue, 06 Jul 2004 07:46:35 -0400
Received: from albatross.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12) id 1BhoOG-0004ko-00
	for megaco@ietf.org; Tue, 06 Jul 2004 07:45:36 -0400
Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120])
	by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id
	i66BjVWR007803
	for <megaco@ietf.org>; Tue, 6 Jul 2004 13:45:35 +0200 (MEST)
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by
	esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	Tue, 6 Jul 2004 13:45:31 +0200
Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by
	esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange
	Internet Mail Service Version 5.5.2657.72)
	id MA44BZYT; Tue, 6 Jul 2004 13:45:31 +0200
Received: from ericsson.com (EG2E500202DSEGL [146.11.22.37]) by
	eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange
	Internet Mail Service Version 5.5.2657.72)
	id 3MHLW6AY; Tue, 6 Jul 2004 21:45:27 +1000
Message-ID: <40EA9123.4050804@ericsson.com>
Date: Tue, 06 Jul 2004 21:46:43 +1000
X-Sybari-Trust: ac908c71 100f6658 ea7f31e3 00000138
From: Christian Groves <christian.groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kalleitner Franz <franz.kalleitner@siemens.com>
Subject: Re: AW: RE : AW: [Megaco] telephony event defintion
References: <DC363E3C9293D71193BA0002B3CC414C0112DB8D@vies186a.sie.siemens.at>
In-Reply-To: <DC363E3C9293D71193BA0002B3CC414C0112DB8D@vies186a.sie.siemens.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 06 Jul 2004 11:45:31.0809 (UTC)
	FILETIME=[BDEAB110:01C4634E]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.ericsson.se
	id i66BjVWR007803
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Cc: "Phil \(Ification\) Hodges" <Philip.Hodges@ericsson.com>,
        "'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
Content-Transfer-Encoding: quoted-printable

Hello Franz,

A agree that sending codec lists is something useful. H.248 allows you to=
 send=20
multiple codec value, reserve values and reserve groups so I believe it c=
opes=20
for all situations. I don't think using Acodec limits this.

The issue as far as I see is the support of DTMF (RFC2833). I guess there=
 are=20
several solutions.
1. Update Q.765.5 Acodec values to include a code points for:
      audio          telephone-event                        [RFC2833]
      audio          tone                                   [RFC2833]
    This could be proposed to ITU SG11.
2. Introduce a new property to Annex C for the code points above. It coul=
d=20
either be specific for the above code points or generic as per rtpmap for=
 fmtp.=20
This would be done in ITU SG16.
3. Use SDP=3Da as proposed by Bruno below.

Thoughts?

Regards, Christian

Kalleitner Franz wrote:

> Hello Christian,
>=20
> it would be great if we could continue the discussion on that threat.
> Based on NGN discussions I assume that sending codelists to a MG will b=
e=20
> a common handling in the future, since MGC does not know at inital=20
> offer, via which interface the answerer will be connected(=20
> wireline,wireless,wi-fi,....)and deploying sofistictated features. Isn'=
t=20
> it ?
>=20
> I think it become very important to handle or negosiate codeclists=20
> between MGC and MG.
> Since ACodec is defind as "single codec" there is no chance to implemen=
t=20
> such a behaviour
> (except using SDP equivalents or text based encoding)
> thanks in advance,
>=20
> regards, Franz
>=20
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: Kalleitner Franz
> Gesendet: Freitag, 25. Juni 2004 11:27
> An: 'CHATRAS Bruno FTRD/DAC/ISS'; Christian Groves
> Cc: BELLING THOMAS; megaco@ietf.org
> Betreff: AW: RE : AW: [Megaco] telephony event defintion
>=20
>=20
> Of course, its possible to use SDP equivalents and it seems to be the=20
> only way out to solve this problem.
>=20
> Yes, the question is related to 3GPP TS 29.332.
> So if there is the necessity to use the SDP equivalents, its not=20
> possible to align the BICC procedure with the IMS(SIP) procedures.
>=20
> Franz
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com=
]
> Gesendet: Freitag, 25. Juni 2004 11:01
> An: Kalleitner Franz; Christian Groves
> Cc: BELLING THOMAS; megaco@ietf.org
> Betreff: RE : AW: [Megaco] telephony event defintion
>=20
>=20
> Why not using the code point for SDP_A defined in Annex C.11 of H.248.1=
?
>=20
> Is this question related to 3GPP TS 29.332?
>=20
> Regards,
> Bruno
>=20
>=20
> -----Message d'origine-----
> De : megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] De la par=
t=20
> de Kalleitner Franz
> Envoy=E9 : vendredi 25 juin 2004 09:58
> =C0 : 'Christian Groves '; Kalleitner Franz
> Cc : BELLING THOMAS; ''megaco@ietf.org' '
> Objet : AW: AW: [Megaco] telephony event defintion
>=20
>=20
> Hello Christian,
>=20
> thanks a lot for you answer.
> You are right, for BICC networks its possible to use the tunneling=20
> solution. However, we need to find a solution to manage the interworkin=
g=20
> between SIP and ISUP networks Q.1912.5 or RFC3398 as well the 3GPP=20
> 29.163, specifying a SIP-BICC interworking as well. As you proposed, fo=
r=20
> the BICC interface we want to use the methods defined in Q1950 and=20
> Q765.5 but its not possible to use them for the SIP interface. SIP=20
> doesn't offer any tunneling in a similar way. Nevertheless its necessar=
y=20
> to configure an IP termination connected to a SIP network via H248.
>=20
> So that's the background, why I'm asking these questions concerning DTM=
F=20
> codec and codeclists, because we want to reuse h248 basics as much as=20
> possible to implement the interworking between SIP and ISUP/BICC networ=
ks.
>=20
> Do you think there is a chance to solve these two items within H248=20
> standardization?
>=20
> kind regards
> Franz
>=20
>=20
>=20
>=20
>=20
> -----Originalnachricht-----
> Von: Christian Groves
> An: Kalleitner Franz
> Cc: 'megaco@ietf.org'; BELLING THOMAS
> Gesendet: 25.06.04 04:16
> Betreff: Re: AW: [Megaco] telephony event defintion
>=20
> Hello Franz,
>=20
> For BICC networks (where the Acodec is defined in Q.765.5) sending DTMF=
=20
> as per
> RFC2833 is not needed across Q.1950(H.248). The actual SDP parameters=20
> used for
> the connection are transmitted via IPBCP (Q.1970).
>=20
> There is a parameter in H.248.1 annex C 0x100F "Payload Type" that may=20
> be of
> some use.
>=20
> Regards, Christian
>=20
> Kalleitner Franz wrote:
>=20
>  > I wonder if anybody could respond on that threat!
>  > Without a codepoint for DTMF, the functionality of RFC2833 cannot be
> applied
>  > for
>  > network configuration specifing DTMF as an ACodec i.e for codec
> negosiation
>  > purposes!
>  > A solution for text encoded H248 is available but not for binary.
>  >
>  > Many thanks in advance
>  > Franz
>  >
>  > -----Urspr=FCngliche Nachricht-----
>  > Von: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]Im
> Auftrag
>  > von Kalleitner Franz
>  > Gesendet: Donnerstag, 17. Juni 2004 13:21
>  > An: 'megaco@ietf.org'
>  > Betreff: [Megaco] telephony event defintion
>  >
>  >
>  > Hello megaco-list members,
>  >
>  > I didn't manage to transfer the media description of the
> telephone-event
>  > (defined in RFC 2833) as a media attribute into ASN.1 format. In SDP
>  > its easily done via a dynamically payload type definition, plus
>  > fmtp,rtpmap for the codec definition Using ASN.1 encoding the payloa=
d
>  > attribute is defined in H248.1 Annex
> C.
>  > However, an reference pointing to the codec definition is not
> available,
>  > therefore I scanned ITU-T and 3GPP references, but I didn't found an=
y
>  > definition for the telephone-event.
>  >
>  > Probably another had the same problem, with more success than I'm an=
d
> may
>  > send a reply to this threat.
>  > Many thanks in advance!
>  >
>  > Franz
>  >
>  > _______________________________________________
>  > 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
>  >
>=20
>=20
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>=20


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


From megaco-bounces@ietf.org  Sat Jul 10 08:43:13 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11253
	for <megaco-archive@lists.ietf.org>; Sat, 10 Jul 2004 08:43:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BjHAa-00050n-Ue; Sat, 10 Jul 2004 08:41:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BjH9g-0004qd-1Y
	for megaco@megatron.ietf.org; Sat, 10 Jul 2004 08:40:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10885
	for <megaco@ietf.org>; Sat, 10 Jul 2004 08:40:34 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BjH9f-0002YN-C7
	for megaco@ietf.org; Sat, 10 Jul 2004 08:40:35 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BjH8k-0002Bs-00
	for megaco@ietf.org; Sat, 10 Jul 2004 08:39:39 -0400
Received: from mail.utstar.com ([216.37.114.6])
	by ietf-mx with esmtp (Exim 4.12) id 1BjH7y-0001qt-00
	for megaco@ietf.org; Sat, 10 Jul 2004 08:38:50 -0400
Received: from njtcbalal8 ([210.21.232.26])
	by mail.utstar.com (8.12.10/8.12.10) with SMTP id i6ACcixx010874;
	Sat, 10 Jul 2004 08:38:47 -0400 (EDT)
From: "Balasubramanian Pitchandi" <bs@utstar.com>
To: <megaco@ietf.org>
Date: Sat, 10 Jul 2004 20:38:43 +0800
Message-ID: <PEEFIEKICKPOBIDKHCJCCEEAFIAA.bs@utstar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Cc: wei.zhao@utstar.com, tiger.pi@utstar.com
Subject: [Megaco] ABNF encoding of Boolean Values
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bs@utstar.com
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
Content-Transfer-Encoding: 7bit

Hello,

RFC3525 has two contradicting sections (A.1.2 & B.2) with respect to the
encoding of boolean values.

A.1.2 states that ObservedEvents parameter should be encoded as

init = false

whereas the section B.2 clearly states that all boolean values should be
encoded as either "on" or "off", which would mean that the same would be
encoded as

init = off

Which one of this is correct?

Thanks
Bala


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


From megaco-bounces@ietf.org  Sat Jul 10 12:25:30 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21189
	for <megaco-archive@lists.ietf.org>; Sat, 10 Jul 2004 12:25:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BjKaR-0001No-74; Sat, 10 Jul 2004 12:20:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BjKP2-0006kb-PM
	for megaco@megatron.ietf.org; Sat, 10 Jul 2004 12:08:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20642
	for <megaco@ietf.org>; Sat, 10 Jul 2004 12:08:38 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BjKP1-0007Yv-UJ
	for megaco@ietf.org; Sat, 10 Jul 2004 12:08:40 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BjKO6-0007Gp-00
	for megaco@ietf.org; Sat, 10 Jul 2004 12:07:43 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12) id 1BjKNJ-0006f1-00
	for megaco@ietf.org; Sat, 10 Jul 2004 12:06:53 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id i6AG6MN28415
	for <megaco@ietf.org>; Sat, 10 Jul 2004 12:06:22 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MXHSSXJ2>; Sat, 10 Jul 2004 12:06:21 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C126CEA78@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: bs@utstar.com, megaco@ietf.org
Subject: RE: [Megaco] ABNF encoding of Boolean Values
Date: Sat, 10 Jul 2004 12:06:21 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Cc: wei.zhao@utstar.com, tiger.pi@utstar.com
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

Appendix A is binary encoding, not text encoding.  Appendix B is text
encoding.  The sections are not contradictory.

Kevin 

-----Original Message-----
From: Balasubramanian Pitchandi [mailto:bs@utstar.com] 
Sent: Saturday, July 10, 2004 8:39 AM
To: megaco@ietf.org
Cc: wei.zhao@utstar.com; tiger.pi@utstar.com
Subject: [Megaco] ABNF encoding of Boolean Values

Hello,

RFC3525 has two contradicting sections (A.1.2 & B.2) with respect to the
encoding of boolean values.

A.1.2 states that ObservedEvents parameter should be encoded as

init = false

whereas the section B.2 clearly states that all boolean values should be
encoded as either "on" or "off", which would mean that the same would be
encoded as

init = off

Which one of this is correct?

Thanks
Bala


_______________________________________________
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 Jul 11 09:48:54 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21699
	for <megaco-archive@lists.ietf.org>; Sun, 11 Jul 2004 09:48:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Bjeet-0002XP-Lp; Sun, 11 Jul 2004 09:46:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Bjea4-0001yP-Qt
	for megaco@megatron.ietf.org; Sun, 11 Jul 2004 09:41:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21506
	for <megaco@ietf.org>; Sun, 11 Jul 2004 09:41:23 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1Bjea4-0003Hz-2X
	for megaco@ietf.org; Sun, 11 Jul 2004 09:41:24 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BjeZ4-00036P-00
	for megaco@ietf.org; Sun, 11 Jul 2004 09:40:23 -0400
Received: from mail.utstar.com ([216.37.114.6])
	by ietf-mx with esmtp (Exim 4.12) id 1BjeYn-0002vH-00
	for megaco@ietf.org; Sun, 11 Jul 2004 09:40:05 -0400
Received: from njtcbalal8 (njtc-rbetti.nj.us.utstar.com [172.16.104.131])
	by mail.utstar.com (8.12.10/8.12.10) with SMTP id i6BDdsxx012910
	for <megaco@ietf.org>; Sun, 11 Jul 2004 09:39:57 -0400 (EDT)
From: "Balasubramanian Pitchandi" <bs@utstar.com>
To: <megaco@ietf.org>
Date: Sun, 11 Jul 2004 21:39:56 +0800
Message-ID: <PEEFIEKICKPOBIDKHCJCMEEFFIAA.bs@utstar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Problem with the andisp/dwa example 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bs@utstar.com
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
Content-Transfer-Encoding: 7bit

Hello,

In H248.23, Section 6.5, there is a small problem with the example given.
The example data is given as:

Signals{andisp/dwa{ddb=802001083035313831363135020A3931393535353030303007084
A6F686E20446F65D5,pattern=1}}

Here, the Checksum (the last byte) is incorrectly specified as D5, whereas
the actual checksum is D8.

Can this be corrected in a future revision of the document?

Thanks
Bala


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


From megaco-bounces@ietf.org  Mon Jul 12 00:48:56 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00477
	for <megaco-archive@lists.ietf.org>; Mon, 12 Jul 2004 00:48:56 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BjseP-0001tj-6e; Mon, 12 Jul 2004 00:42:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Bjsaw-0001Eh-Ap
	for megaco@megatron.ietf.org; Mon, 12 Jul 2004 00:39:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29991
	for <megaco@ietf.org>; Mon, 12 Jul 2004 00:39:11 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1Bjsau-0005MZ-En
	for megaco@ietf.org; Mon, 12 Jul 2004 00:39:12 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BjsaG-0005Br-00
	for megaco@ietf.org; Mon, 12 Jul 2004 00:38:33 -0400
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12) id 1BjsZJ-0004ws-00
	for megaco@ietf.org; Mon, 12 Jul 2004 00:37:33 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id i6C4b2X26303
	for <megaco@ietf.org>; Mon, 12 Jul 2004 00:37:03 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MXHSS8FG>; Mon, 12 Jul 2004 00:37:03 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C126CED32@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: bs@utstar.com, megaco@ietf.org
Subject: RE: [Megaco] Problem with the andisp/dwa example 
Date: Mon, 12 Jul 2004 00:37:00 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
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

This was already corrected in H.248.23 Corrigendum 1 (03/2004).

Kevin 

-----Original Message-----
From: Balasubramanian Pitchandi [mailto:bs@utstar.com] 
Sent: Sunday, July 11, 2004 9:40 AM
To: megaco@ietf.org
Subject: [Megaco] Problem with the andisp/dwa example 

Hello,

In H248.23, Section 6.5, there is a small problem with the example given.
The example data is given as:

Signals{andisp/dwa{ddb=802001083035313831363135020A3931393535353030303007084
A6F686E20446F65D5,pattern=1}}

Here, the Checksum (the last byte) is incorrectly specified as D5, whereas
the actual checksum is D8.

Can this be corrected in a future revision of the document?

Thanks
Bala


_______________________________________________
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 Jul 13 01:44:59 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28813
	for <megaco-archive@lists.ietf.org>; Tue, 13 Jul 2004 01:44:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BkFuN-00087W-4e; Tue, 13 Jul 2004 01:32:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BkFom-0006pM-3h
	for megaco@megatron.ietf.org; Tue, 13 Jul 2004 01:27:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28221
	for <megaco@ietf.org>; Tue, 13 Jul 2004 01:27:03 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BkFok-0005UC-2O
	for megaco@ietf.org; Tue, 13 Jul 2004 01:27:02 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BkFnl-0005En-00
	for megaco@ietf.org; Tue, 13 Jul 2004 01:26:02 -0400
Received: from szsmtp.utstar.com.cn ([210.21.224.29])
	by ietf-mx with esmtp (Exim 4.12) id 1BkFmi-0004ja-00
	for megaco@ietf.org; Tue, 13 Jul 2004 01:24:56 -0400
Received: from szvsaattom (sz-vsa-attom [172.19.18.87] (may be forged))
	by szsmtp.utstar.com.cn (8.11.6/8.11.1) with SMTP id i6D5OCr11729;
	Tue, 13 Jul 2004 13:24:12 +0800
From: "atto" <atto.mu@utstar.com>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>
Subject: =?gb2312?B?tPC4tDogW01lZ2Fjb10gQUJORiBlbmNvZGluZyBvZiBCb29sZWFuIFZhbHU=?=
	=?gb2312?B?ZXM=?=
Date: Tue, 13 Jul 2004 13:25:54 +0800
Message-ID: <CDEHKEMIAMIJHBPOGCFFCEANCCAA.atto.mu@utstar.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C126CEA78@zrtpd0jq.us.nortel.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MIME_BASE64_TEXT 
	autolearn=no version=2.60
Cc: bala <bs@utstar.com>, 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>
Content-Type: multipart/mixed; boundary="===============1961633448=="
Sender: megaco-bounces@ietf.org
Errors-To: megaco-bounces@ietf.org

--===============1961633448==
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

aGksIGtldmluLA0KDQpJIGFtIGNvbmZ1c2VkIGJ5IHNvbWUgY29uZmxpY3QgaW4gcmZjMzUyNS4N
Cg0KYnkgQi4yIGNvbW1lbnQsIHRoZSB0ZXh0IGVuY29kaW5nIGJvb2xlYW4gc2hvdWxkIGJlICJv
biIvIm9mZiIsIA0KDQpidXQgYnkgZGVmaW5pdGlvbiBvZiAgY2Qvb257aW5pdH0sIHRoZSB2YWx1
ZSBvZiBib29sZWFuIGlzICAidHJ1ZSIvImZhbHNlIi4NCg0KCU9ic2VydmVkRXZlbnRzRGVzY3Jp
cHRvciBwYXJhbWV0ZXJzDQoJCUluaXRpYWwgU3RhdGUNCgkJUGFyYW1ldGVySUQ6IGluaXQgKDB4
MDAwMikNCgkJVHlwZTogQm9vbGVhbg0KCQlQb3NzaWJsZSB2YWx1ZXM6DQoJCSJUcnVlIiBtZWFu
cyB0aGF0IHRoZSBldmVudCB3YXMgcmVwb3J0ZWQgYmVjYXVzZSB0aGUgbGluZSB3YXMgYWxyZWFk
eSBvbi1ob29rIHdoZW4gdGhlIGV2ZW50cyBkZXNjcmlwdG9yIGNvbnRhaW5pbmcgdGhpcyBldmVu
dCB3YXMgYWN0aXZhdGVkOw0KCQkiRmFsc2UiIG1lYW5zIHRoYXQgdGhlIGV2ZW50IHJlcHJlc2Vu
dHMgYW4gYWN0dWFsIHN0YXRlIHRyYW5zaXRpb24gdG8gb24taG9vay4NCg0KYW5kIHNvbWUgZXhh
bXBsZXMgb2YgY2Qvb257aW5pdH0gYWxzbyBzaG93ICB0aGF0ICJ0cnVlIi8iZmFsc2UiIHNob3Vs
ZCBiZSB1c2VkLiAoaW4gcmZjMzUyNSBwYWdlIDE4Ni8xOTEvMTkzKQ0KDQpNRUdBQ08vMSBbMTI1
LjEyNS4xMjUuMTExXTo1NTU1NSBUcmFuc2FjdGlvbiA9IDUwMDA4IHsNCiAgICAgIENvbnRleHQg
PSA1MDAwIHsNCiAgICAgICAgICBOb3RpZnkgPSBBNTU1NSB7T2JzZXJ2ZWRFdmVudHMgPTEyMzUg
ew0KICAgICAgICAgICAgIDE5OTkwNzI5VDI0MDIwMDAyOmFsL29uKGluaXQ9ZmFsc2UpfQ0KICAg
ICAgICAgIH0NCiAgICAgIH0gfQ0KDQppcyBpdCBhIG1pc3Rha2Ugb2YgcmZjMzUyNT8gDQpvciB0
aGUgYm9vbGVhbiBjYW4gYmUgZWl0aGVyIG9uL29mZiBvciB0cnVlL2ZhbHNlLCBqdXN0IGFjY29y
ZGluZyBieSB0aGUgZGVmaW5pdGlvbj8NCg0KdGhhbmtzDQphdHRvDQoNCi0tLS0t1K3KvNPKvP4t
LS0tLQ0Kt6K8/sjLOiBtZWdhY28tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1lZ2Fjby1ib3Vu
Y2VzQGlldGYub3JnXbT6se0NCktldmluIEJveWxlDQq3osvNyrG85DogMjAwNMTqN9TCMTHI1SAw
OjA2DQrK1bz+yMs6IGJzQHV0c3Rhci5jb207IG1lZ2Fjb0BpZXRmLm9yZw0Ks63LzTogd2VpLnpo
YW9AdXRzdGFyLmNvbTsgdGlnZXIucGlAdXRzdGFyLmNvbQ0K1vfM4jogUkU6IFtNZWdhY29dIEFC
TkYgZW5jb2Rpbmcgb2YgQm9vbGVhbiBWYWx1ZXMNCg0KDQpBcHBlbmRpeCBBIGlzIGJpbmFyeSBl
bmNvZGluZywgbm90IHRleHQgZW5jb2RpbmcuICBBcHBlbmRpeCBCIGlzIHRleHQNCmVuY29kaW5n
LiAgVGhlIHNlY3Rpb25zIGFyZSBub3QgY29udHJhZGljdG9yeS4NCg0KS2V2aW4gDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCYWxhc3VicmFtYW5pYW4gUGl0Y2hhbmRpIFtt
YWlsdG86YnNAdXRzdGFyLmNvbV0gDQpTZW50OiBTYXR1cmRheSwgSnVseSAxMCwgMjAwNCA4OjM5
IEFNDQpUbzogbWVnYWNvQGlldGYub3JnDQpDYzogd2VpLnpoYW9AdXRzdGFyLmNvbTsgdGlnZXIu
cGlAdXRzdGFyLmNvbQ0KU3ViamVjdDogW01lZ2Fjb10gQUJORiBlbmNvZGluZyBvZiBCb29sZWFu
IFZhbHVlcw0KDQpIZWxsbywNCg0KUkZDMzUyNSBoYXMgdHdvIGNvbnRyYWRpY3Rpbmcgc2VjdGlv
bnMgKEEuMS4yICYgQi4yKSB3aXRoIHJlc3BlY3QgdG8gdGhlDQplbmNvZGluZyBvZiBib29sZWFu
IHZhbHVlcy4NCg0KQS4xLjIgc3RhdGVzIHRoYXQgT2JzZXJ2ZWRFdmVudHMgcGFyYW1ldGVyIHNo
b3VsZCBiZSBlbmNvZGVkIGFzDQoNCmluaXQgPSBmYWxzZQ0KDQp3aGVyZWFzIHRoZSBzZWN0aW9u
IEIuMiBjbGVhcmx5IHN0YXRlcyB0aGF0IGFsbCBib29sZWFuIHZhbHVlcyBzaG91bGQgYmUNCmVu
Y29kZWQgYXMgZWl0aGVyICJvbiIgb3IgIm9mZiIsIHdoaWNoIHdvdWxkIG1lYW4gdGhhdCB0aGUg
c2FtZSB3b3VsZCBiZQ0KZW5jb2RlZCBhcw0KDQppbml0ID0gb2ZmDQoNCldoaWNoIG9uZSBvZiB0
aGlzIGlzIGNvcnJlY3Q/DQoNClRoYW5rcw0KQmFsYQ0KDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpNZWdhY28gbWFpbGluZyBsaXN0DQpNZWdhY29A
aWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21lZ2Fjbw0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTWVnYWNv
IG1haWxpbmcgbGlzdA0KTWVnYWNvQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9tZWdhY28=



--===============1961633448==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============1961633448==--


From megaco-bounces@ietf.org  Wed Jul 14 09:53:05 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17133
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jul 2004 09:53:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Bkk3A-00016E-8a; Wed, 14 Jul 2004 09:43:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkjwf-0007Wp-Sh
	for megaco@megatron.ietf.org; Wed, 14 Jul 2004 09:37:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16510
	for <megaco@ietf.org>; Wed, 14 Jul 2004 09:37:11 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1Bkjwe-0001IJ-OR
	for megaco@ietf.org; Wed, 14 Jul 2004 09:37:12 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Bkjvt-000107-00
	for megaco@ietf.org; Wed, 14 Jul 2004 09:36:25 -0400
Received: from email10.etsi.org ([212.234.161.112] helo=email10.etsihq.org)
	by ietf-mx with esmtp (Exim 4.12) id 1Bkjuy-0000NT-00
	for Megaco@ietf.org; Wed, 14 Jul 2004 09:35:28 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 Jul 2004 15:34:57 +0200
Message-ID: <4091553999CBE4409CC2B562152B5A339C6FB2@email10.etsihq.org>
Thread-Topic: Add command with NULL context
Thread-Index: AcRpp1pgNvtdnGdeSK2vTonPIey/SQ==
From: "Csaba Koppany" <Csaba.Koppany@etsi.org>
To: <Megaco@ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Subject: [Megaco] Add command with NULL context
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
Content-Transfer-Encoding: quoted-printable

Hi List,
=20
can someone clarify hat would be the correct answer to message below?
=20
=20
MEGACO/2 [123.123.123.4]:55555
Transaction =3D 10003 {
    Context =3D - {
       Add =3D $ {
          ....
       }
    }
} =20

I guess using NULL context in an add command is an error, independently
the value of the termination Id.
It is written hat if the ROOT termination is addressed the 410
"Incorrect identifier" Shall be returned, but what are the error codes
in case of using a specific, CHOOSE or ALL wildcards?=20

It is also my question if this error description should be on the
command or Action level, as by the syntax it is possible to include an
error descriptor inside the ActioReply with an empty list of command.

Thank you for any suggestions!
Best regards,
  Csaba Koppany

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


From megaco-bounces@ietf.org  Wed Jul 14 13:28:06 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00436
	for <megaco-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:28:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BknQ7-0007KM-81; Wed, 14 Jul 2004 13:19:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BknFz-0005Mc-Lk
	for megaco@megatron.ietf.org; Wed, 14 Jul 2004 13:09:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29514
	for <megaco@ietf.org>; Wed, 14 Jul 2004 13:09:20 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BknFy-0001QG-MS
	for megaco@ietf.org; Wed, 14 Jul 2004 13:09:22 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BknF2-00015W-00
	for megaco@ietf.org; Wed, 14 Jul 2004 13:08:24 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12) id 1BknE5-0000UQ-00
	for Megaco@ietf.org; Wed, 14 Jul 2004 13:07:25 -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 i6EH6r417798
	for <Megaco@ietf.org>; Wed, 14 Jul 2004 13:06:54 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MXHSW85K>; Wed, 14 Jul 2004 13:06:54 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C1284459D@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Csaba Koppany <Csaba.Koppany@etsi.org>, Megaco@ietf.org
Subject: RE: [Megaco] Add command with NULL context
Date: Wed, 14 Jul 2004 13:06:51 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
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

Seems to me that this would be a protocol error (401).

Try: !/1 [12.34.56.78]:2944 P=10003{C=-{ER=401{"That's not allowed!"}}}

Kevin 

-----Original Message-----
From: Csaba Koppany [mailto:Csaba.Koppany@etsi.org] 
Sent: Wednesday, July 14, 2004 9:35 AM
To: Megaco@ietf.org
Subject: [Megaco] Add command with NULL context

Hi List,
 
can someone clarify hat would be the correct answer to message below?
 
 
MEGACO/2 [123.123.123.4]:55555
Transaction = 10003 {
    Context = - {
       Add = $ {
          ....
       }
    }
}  

I guess using NULL context in an add command is an error, independently the
value of the termination Id.
It is written hat if the ROOT termination is addressed the 410 "Incorrect
identifier" Shall be returned, but what are the error codes in case of using
a specific, CHOOSE or ALL wildcards? 

It is also my question if this error description should be on the command or
Action level, as by the syntax it is possible to include an error descriptor
inside the ActioReply with an empty list of command.

Thank you for any suggestions!
Best regards,
  Csaba Koppany

_______________________________________________
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 Jul 15 21:33:43 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25439
	for <megaco-archive@lists.ietf.org>; Thu, 15 Jul 2004 21:33:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BlHWg-0006PU-4h; Thu, 15 Jul 2004 21:28:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BlHP2-0004zh-Io
	for megaco@megatron.ietf.org; Thu, 15 Jul 2004 21:20:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24845
	for <megaco@ietf.org>; Thu, 15 Jul 2004 21:20:42 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BlHP0-0000rq-NP
	for megaco@ietf.org; Thu, 15 Jul 2004 21:20:42 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BlHO1-0000Ww-00
	for megaco@ietf.org; Thu, 15 Jul 2004 21:19:41 -0400
Received: from [211.160.15.6] (helo=mail.putian.com)
	by ietf-mx with esmtp (Exim 4.12) id 1BlHNW-000022-00
	for megaco@ietf.org; Thu, 15 Jul 2004 21:19:12 -0400
Content-Class: urn:content-classes:message
Subject: Re:  [Megaco] Add command with NULL context
MIME-Version: 1.0
Date: Fri, 16 Jul 2004 09:17:45 +0800
Message-ID: <006A9E7E02D21C45AC3CB741AEBF844E01719979@mail.putian.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Thread-Topic: Megaco Digest, Vol 3, Issue 9
thread-index: AcRqhn0mRakHZS1zSoKtfEPqsKGL9gASx8Qw
From: =?utf-8?B?5p2o5YWI5rOi?= <yxb@cpit.com.cn>
To: <megaco@ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
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="===============0366294019=="
Sender: megaco-bounces@ietf.org
Errors-To: megaco-bounces@ietf.org

--===============0366294019==
Content-Class: urn:content-classes:message
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

QnV0IGFzIEkga25vdywgaWYgdGVybWluYXRpb24gaXMgUk9PVCwgaXQgcHJlc2VudHMgdGhlIE1H
Vywgc28gY29udGV4dCBzaG91bGQgYmUgbnVsbCx3aGljaCBpcyBub3QgbmVjZXNzYXJ5Ow0KaWYg
c3BlY2lmaWMsIENIT09TRSBvciBBTEwsIGNvbnRleHQgbm90IG51bGwuSnVzdCBteSB2aWV3cG9p
bnQuDQoNCi0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0NCuWPkeS7tuS6ujogbWVnYWNvLWJvdW5jZXNA
aWV0Zi5vcmcgW21haWx0bzptZWdhY28tYm91bmNlc0BpZXRmLm9yZ13ku6PooaggbWVnYWNvLXJl
cXVlc3RAaWV0Zi5vcmcNCuWPkemAgeaXtumXtDogMjAwNOW5tDfmnIgxNuaXpSAwOjEyDQrmlLbk
u7bkuro6IG1lZ2Fjb0BpZXRmLm9yZw0K5Li76aKYOiBNZWdhY28gRGlnZXN0LCBWb2wgMywgSXNz
dWUgOQ0KDQoNClNlbmQgTWVnYWNvIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bw0KCW1lZ2Fj
b0BpZXRmLm9yZw0KDQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBX
aWRlIFdlYiwgdmlzaXQNCglodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t
ZWdhY28NCm9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5
ICdoZWxwJyB0bw0KCW1lZ2Fjby1yZXF1ZXN0QGlldGYub3JnDQoNCllvdSBjYW4gcmVhY2ggdGhl
IHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KCW1lZ2Fjby1vd25lckBpZXRmLm9yZw0KDQpX
aGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3Jl
IHNwZWNpZmljDQp0aGFuICJSZTogQ29udGVudHMgb2YgTWVnYWNvIGRpZ2VzdC4uLiINCg0KDQpU
b2RheSdzIFRvcGljczoNCg0KICAgMS4gUkU6IEFkZCBjb21tYW5kIHdpdGggTlVMTCBjb250ZXh0
IChLZXZpbiBCb3lsZSkNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk1lc3NhZ2U6IDENCkRhdGU6IFdl
ZCwgMTQgSnVsIDIwMDQgMTM6MDY6NTEgLTA0MDANCkZyb206ICJLZXZpbiBCb3lsZSIgPGtib3ls
ZUBub3J0ZWxuZXR3b3Jrcy5jb20+DQpTdWJqZWN0OiBSRTogW01lZ2Fjb10gQWRkIGNvbW1hbmQg
d2l0aCBOVUxMIGNvbnRleHQNClRvOiBDc2FiYSBLb3BwYW55IDxDc2FiYS5Lb3BwYW55QGV0c2ku
b3JnPiwgTWVnYWNvQGlldGYub3JnDQpNZXNzYWdlLUlEOg0KCTxBQkEyMjdBMTVCODBENTExQkQx
QTAwNTA4QkY5M0ExQzEyODQ0NTlEQHpydHBkMGpxLnVzLm5vcnRlbC5jb20+DQoNClNlZW1zIHRv
IG1lIHRoYXQgdGhpcyB3b3VsZCBiZSBhIHByb3RvY29sIGVycm9yICg0MDEpLg0KDQpUcnk6ICEv
MSBbMTIuMzQuNTYuNzhdOjI5NDQgUD0xMDAwM3tDPS17RVI9NDAxeyJUaGF0J3Mgbm90IGFsbG93
ZWQhIn19fQ0KDQpLZXZpbiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENz
YWJhIEtvcHBhbnkgW21haWx0bzpDc2FiYS5Lb3BwYW55QGV0c2kub3JnXSANClNlbnQ6IFdlZG5l
c2RheSwgSnVseSAxNCwgMjAwNCA5OjM1IEFNDQpUbzogTWVnYWNvQGlldGYub3JnDQpTdWJqZWN0
OiBbTWVnYWNvXSBBZGQgY29tbWFuZCB3aXRoIE5VTEwgY29udGV4dA0KDQpIaSBMaXN0LA0KIA0K
Y2FuIHNvbWVvbmUgY2xhcmlmeSBoYXQgd291bGQgYmUgdGhlIGNvcnJlY3QgYW5zd2VyIHRvIG1l
c3NhZ2UgYmVsb3c/DQogDQogDQpNRUdBQ08vMiBbMTIzLjEyMy4xMjMuNF06NTU1NTUNClRyYW5z
YWN0aW9uID0gMTAwMDMgew0KICAgIENvbnRleHQgPSAtIHsNCiAgICAgICBBZGQgPSAkIHsNCiAg
ICAgICAgICAuLi4uDQogICAgICAgfQ0KICAgIH0NCn0gIA0KDQpJIGd1ZXNzIHVzaW5nIE5VTEwg
Y29udGV4dCBpbiBhbiBhZGQgY29tbWFuZCBpcyBhbiBlcnJvciwgaW5kZXBlbmRlbnRseSB0aGUN
CnZhbHVlIG9mIHRoZSB0ZXJtaW5hdGlvbiBJZC4NCkl0IGlzIHdyaXR0ZW4gaGF0IGlmIHRoZSBS
T09UIHRlcm1pbmF0aW9uIGlzIGFkZHJlc3NlZCB0aGUgNDEwICJJbmNvcnJlY3QNCmlkZW50aWZp
ZXIiIFNoYWxsIGJlIHJldHVybmVkLCBidXQgd2hhdCBhcmUgdGhlIGVycm9yIGNvZGVzIGluIGNh
c2Ugb2YgdXNpbmcNCmEgc3BlY2lmaWMsIENIT09TRSBvciBBTEwgd2lsZGNhcmRzPyANCg0KSXQg
aXMgYWxzbyBteSBxdWVzdGlvbiBpZiB0aGlzIGVycm9yIGRlc2NyaXB0aW9uIHNob3VsZCBiZSBv
biB0aGUgY29tbWFuZCBvcg0KQWN0aW9uIGxldmVsLCBhcyBieSB0aGUgc3ludGF4IGl0IGlzIHBv
c3NpYmxlIHRvIGluY2x1ZGUgYW4gZXJyb3IgZGVzY3JpcHRvcg0KaW5zaWRlIHRoZSBBY3Rpb1Jl
cGx5IHdpdGggYW4gZW1wdHkgbGlzdCBvZiBjb21tYW5kLg0KDQpUaGFuayB5b3UgZm9yIGFueSBz
dWdnZXN0aW9ucyENCkJlc3QgcmVnYXJkcywNCiAgQ3NhYmEgS29wcGFueQ0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTWVnYWNvIG1haWxpbmcgbGlz
dA0KTWVnYWNvQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9tZWdhY28NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTWVnYWNvIG1haWxpbmcg
bGlzdA0KTWVnYWNvQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9tZWdhY28NCg0KDQpFbmQgb2YgTWVnYWNvIERpZ2VzdCwgVm9sIDMsIElzc3VlIDkNCioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K


--===============0366294019==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============0366294019==--


From megaco-bounces@ietf.org  Thu Jul 15 22:53:17 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11757
	for <megaco-archive@lists.ietf.org>; Thu, 15 Jul 2004 22:53:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BlIjy-0007I6-CZ; Thu, 15 Jul 2004 22: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 1BlIfF-0005wq-6L
	for megaco@megatron.ietf.org; Thu, 15 Jul 2004 22:41:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11232
	for <megaco@ietf.org>; Thu, 15 Jul 2004 22:41:30 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BlIfD-0004De-1N
	for megaco@ietf.org; Thu, 15 Jul 2004 22:41:31 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BlIeE-0003tF-00
	for megaco@ietf.org; Thu, 15 Jul 2004 22:40:31 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12) id 1BlIdC-0003GP-00
	for megaco@ietf.org; Thu, 15 Jul 2004 22:39:26 -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 i6G2cjj15451; Thu, 15 Jul 2004 22:38:46 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MXHSZ29X>; Thu, 15 Jul 2004 22:38:46 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C129252B6@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: ??? <yxb@cpit.com.cn>, megaco@ietf.org
Subject: RE: [Megaco] Add command with NULL context
Date: Thu, 15 Jul 2004 22:38:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60
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="===============1706579861=="
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.

--===============1706579861==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C46ADD.8BA0F638"

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_01C46ADD.8BA0F638
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

Regardless of which termination it is, Add to NULL is illegal.  An Add =
of
ROOT to anything is also illegal.  The question was what the response =
to
such a command would be.

Note that an Add to ALL is guaranteed to return an error, except in the =
case
of there being only a single context.  So that is a fairly silly =
combination
as well.

Kevin=20

-----Original Message-----
From: yxb@cpit.com.cn [mailto:yxb@cpit.com.cn]=20
Sent: Thursday, July 15, 2004 9:18 PM
To: megaco@ietf.org
Subject: Re: [Megaco] Add command with NULL context

But as I know, if termination is ROOT, it presents the MGW, so context
should be null,which is not necessary; if specific, CHOOSE or ALL, =
context
not null.Just my viewpoint.

-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB: megaco-bounces@ietf.org =
[mailto:megaco-bounces@ietf.org]=B4=FA=B1=ED
megaco-request@ietf.org
=B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA7=D4=C216=C8=D5 0:12
=CA=D5=BC=FE=C8=CB: megaco@ietf.org
=D6=F7=CC=E2: Megaco Digest, Vol 3, Issue 9


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. RE: Add command with NULL context (Kevin Boyle)


----------------------------------------------------------------------

Message: 1
Date: Wed, 14 Jul 2004 13:06:51 -0400
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
Subject: RE: [Megaco] Add command with NULL context
To: Csaba Koppany <Csaba.Koppany@etsi.org>, Megaco@ietf.org
Message-ID:
	<ABA227A15B80D511BD1A00508BF93A1C1284459D@zrtpd0jq.us.nortel.com>

Seems to me that this would be a protocol error (401).

Try: !/1 [12.34.56.78]:2944 P=3D10003{C=3D-{ER=3D401{"That's not =
allowed!"}}}

Kevin=20

-----Original Message-----
From: Csaba Koppany [mailto:Csaba.Koppany@etsi.org]
Sent: Wednesday, July 14, 2004 9:35 AM
To: Megaco@ietf.org
Subject: [Megaco] Add command with NULL context

Hi List,
=20
can someone clarify hat would be the correct answer to message below?
=20
=20
MEGACO/2 [123.123.123.4]:55555
Transaction =3D 10003 {
    Context =3D - {
       Add =3D $ {
          ....
       }
    }
} =20

I guess using NULL context in an add command is an error, independently =
the
value of the termination Id.
It is written hat if the ROOT termination is addressed the 410 =
"Incorrect
identifier" Shall be returned, but what are the error codes in case of =
using
a specific, CHOOSE or ALL wildcards?=20

It is also my question if this error description should be on the =
command or
Action level, as by the syntax it is possible to include an error =
descriptor
inside the ActioReply with an empty list of command.

Thank you for any suggestions!
Best regards,
  Csaba Koppany

_______________________________________________
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


End of Megaco Digest, Vol 3, Issue 9
************************************

------_=_NextPart_001_01C46ADD.8BA0F638
Content-Type: text/html;
	charset="gb2312"
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=3Dgb2312">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [Megaco] Add command with NULL context</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Regardless of which termination it is, Add to NULL is =
illegal.&nbsp; An Add of ROOT to anything is also illegal.&nbsp; The =
question was what the response to such a command would be.</FONT></P>

<P><FONT SIZE=3D2>Note that an Add to ALL is guaranteed to return an =
error, except in the case of there being only a single context.&nbsp; =
So that is a fairly silly combination as well.</FONT></P>

<P><FONT SIZE=3D2>Kevin </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: yxb@cpit.com.cn [<A =
HREF=3D"mailto:yxb@cpit.com.cn">mailto:yxb@cpit.com.cn</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, July 15, 2004 9:18 PM</FONT>
<BR><FONT SIZE=3D2>To: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Megaco] Add command with NULL =
context</FONT>
</P>

<P><FONT SIZE=3D2>But as I know, if termination is ROOT, it presents =
the MGW, so context should be null,which is not necessary; if specific, =
CHOOSE or ALL, context not null.Just my viewpoint.</FONT></P>

<P><FONT SIZE=3D2>-----=D4=AD=CA=BC=D3=CA=BC=FE-----</FONT>
<BR><FONT SIZE=3D2>=B7=A2=BC=FE=C8=CB: megaco-bounces@ietf.org [<A =
HREF=3D"mailto:megaco-bounces@ietf.org">mailto:megaco-bounces@ietf.org</=
A>]=B4=FA=B1=ED megaco-request@ietf.org</FONT>
<BR><FONT SIZE=3D2>=B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA7=D4=C216=C8=D5 =
0:12</FONT>
<BR><FONT SIZE=3D2>=CA=D5=BC=FE=C8=CB: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>=D6=F7=CC=E2: Megaco Digest, Vol 3, Issue 9</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Send Megaco mailing list submissions to</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>megaco@ietf.org</FONT>
</P>

<P><FONT SIZE=3D2>To subscribe or unsubscribe via the World Wide Web, =
visit</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/megaco" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></FON=
T>
<BR><FONT SIZE=3D2>or, via email, send a message with subject or body =
'help' to</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>megaco-request@ietf.org</FONT>
</P>

<P><FONT SIZE=3D2>You can reach the person managing the list at</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>megaco-owner@ietf.org</FONT>
</P>

<P><FONT SIZE=3D2>When replying, please edit your Subject line so it is =
more specific than &quot;Re: Contents of Megaco digest...&quot;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Today's Topics:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; 1. RE: Add command with NULL context =
(Kevin Boyle)</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>Message: 1</FONT>
<BR><FONT SIZE=3D2>Date: Wed, 14 Jul 2004 13:06:51 -0400</FONT>
<BR><FONT SIZE=3D2>From: &quot;Kevin Boyle&quot; =
&lt;kboyle@nortelnetworks.com&gt;</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Megaco] Add command with NULL =
context</FONT>
<BR><FONT SIZE=3D2>To: Csaba Koppany &lt;Csaba.Koppany@etsi.org&gt;, =
Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Message-ID:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&lt;ABA227A15B80D511BD1A00508BF93A1C1284459D@zrtpd0jq.us.nortel=
.com&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Seems to me that this would be a protocol error =
(401).</FONT>
</P>

<P><FONT SIZE=3D2>Try: !/1 [12.34.56.78]:2944 =
P=3D10003{C=3D-{ER=3D401{&quot;That's not allowed!&quot;}}}</FONT>
</P>

<P><FONT SIZE=3D2>Kevin </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Csaba Koppany [<A =
HREF=3D"mailto:Csaba.Koppany@etsi.org">mailto:Csaba.Koppany@etsi.org</A>=
]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, July 14, 2004 9:35 AM</FONT>
<BR><FONT SIZE=3D2>To: Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: [Megaco] Add command with NULL =
context</FONT>
</P>

<P><FONT SIZE=3D2>Hi List,</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>can someone clarify hat would be the correct answer =
to message below?</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>MEGACO/2 [123.123.123.4]:55555</FONT>
<BR><FONT SIZE=3D2>Transaction =3D 10003 {</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Context =3D - {</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add =3D $ =
{</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
....</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; }</FONT>
<BR><FONT SIZE=3D2>}&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>I guess using NULL context in an add command is an =
error, independently the value of the termination Id.</FONT>
<BR><FONT SIZE=3D2>It is written hat if the ROOT termination is =
addressed the 410 &quot;Incorrect identifier&quot; Shall be returned, =
but what are the error codes in case of using a specific, CHOOSE or ALL =
wildcards? </FONT></P>

<P><FONT SIZE=3D2>It is also my question if this error description =
should be on the command or Action level, as by the syntax it is =
possible to include an error descriptor inside the ActioReply with an =
empty list of command.</FONT></P>

<P><FONT SIZE=3D2>Thank you for any suggestions!</FONT>
<BR><FONT SIZE=3D2>Best regards,</FONT>
<BR><FONT SIZE=3D2>&nbsp; Csaba Koppany</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/megaco" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></FON=
T>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>------------------------------</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/megaco" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></FON=
T>
</P>
<BR>

<P><FONT SIZE=3D2>End of Megaco Digest, Vol 3, Issue 9</FONT>
<BR><FONT SIZE=3D2>************************************</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C46ADD.8BA0F638--


--===============1706579861==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============1706579861==--



From megaco-bounces@ietf.org  Thu Jul 15 23:02:04 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12216
	for <megaco-archive@lists.ietf.org>; Thu, 15 Jul 2004 23:02:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BlIuk-0001Is-7g; Thu, 15 Jul 2004 22:57:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BlIp2-0008S8-NR
	for megaco@megatron.ietf.org; Thu, 15 Jul 2004 22:51:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11677
	for <megaco@ietf.org>; Thu, 15 Jul 2004 22:51:37 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BlIp0-0007WO-L6
	for megaco@ietf.org; Thu, 15 Jul 2004 22:51:38 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BlIoL-0007Cq-00
	for megaco@ietf.org; Thu, 15 Jul 2004 22:50:59 -0400
Received: from [211.160.15.6] (helo=mail.putian.com)
	by ietf-mx with esmtp (Exim 4.12) id 1BlIne-0006s7-00
	for megaco@ietf.org; Thu, 15 Jul 2004 22:50:15 -0400
Content-Class: urn:content-classes:message
Subject: Re: [Megaco] Add command with NULL context
MIME-Version: 1.0
Date: Fri, 16 Jul 2004 10:49:06 +0800
Message-ID: <006A9E7E02D21C45AC3CB741AEBF844E01719AC9@mail.putian.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Thread-Topic: [Megaco] Add command with NULL context
thread-index: AcRq3fkTy/5FG000SIqQMnGjx3FEcwAAUQaA
From: =?gb2312?B?0e7PyLKo?= <yxb@cpit.com.cn>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>, <megaco@ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,
	HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60
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="===============0118703201=="
Sender: megaco-bounces@ietf.org
Errors-To: megaco-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0118703201==
Content-Class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C46ADF.75E96DA0"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C46ADF.75E96DA0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

Right, sorry, I ignored the command is add, if servicechange command ,it =
can do=20

-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA7=D4=C216=C8=D5 10:39
=CA=D5=BC=FE=C8=CB: =D1=EE=CF=C8=B2=A8; megaco@ietf.org
=D6=F7=CC=E2: RE: [Megaco] Add command with NULL context



Regardless of which termination it is, Add to NULL is illegal.  An Add =
of ROOT to anything is also illegal.  The question was what the response =
to such a command would be.

Note that an Add to ALL is guaranteed to return an error, except in the =
case of there being only a single context.  So that is a fairly silly =
combination as well.

Kevin=20

-----Original Message-----=20
From: yxb@cpit.com.cn [ mailto:yxb@cpit.com.cn]=20
Sent: Thursday, July 15, 2004 9:18 PM=20
To: megaco@ietf.org=20
Subject: Re: [Megaco] Add command with NULL context=20

But as I know, if termination is ROOT, it presents the MGW, so context =
should be null,which is not necessary; if specific, CHOOSE or ALL, =
context not null.Just my viewpoint.

-----=D4=AD=CA=BC=D3=CA=BC=FE-----=20
=B7=A2=BC=FE=C8=CB: megaco-bounces@ietf.org [ =
mailto:megaco-bounces@ietf.org]=B4=FA=B1=ED megaco-request@ietf.org=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA7=D4=C216=C8=D5 0:12=20
=CA=D5=BC=FE=C8=CB: megaco@ietf.org=20
=D6=F7=CC=E2: Megaco Digest, Vol 3, Issue 9=20


Send Megaco mailing list submissions to=20
        megaco@ietf.org=20

To subscribe or unsubscribe via the World Wide Web, visit=20
        https://www1.ietf.org/mailman/listinfo/megaco=20
or, via email, send a message with subject or body 'help' to=20
        megaco-request@ietf.org=20

You can reach the person managing the list at=20
        megaco-owner@ietf.org=20

When replying, please edit your Subject line so it is more specific than =
"Re: Contents of Megaco digest..."=20


Today's Topics:=20

   1. RE: Add command with NULL context (Kevin Boyle)=20


----------------------------------------------------------------------=20

Message: 1=20
Date: Wed, 14 Jul 2004 13:06:51 -0400=20
From: "Kevin Boyle" <kboyle@nortelnetworks.com>=20
Subject: RE: [Megaco] Add command with NULL context=20
To: Csaba Koppany <Csaba.Koppany@etsi.org>, Megaco@ietf.org=20
Message-ID:=20
        =
<ABA227A15B80D511BD1A00508BF93A1C1284459D@zrtpd0jq.us.nortel.com>=20

Seems to me that this would be a protocol error (401).=20

Try: !/1 [12.34.56.78]:2944 P=3D10003{C=3D-{ER=3D401{"That's not =
allowed!"}}}=20

Kevin=20

-----Original Message-----=20
From: Csaba Koppany [ mailto:Csaba.Koppany@etsi.org]=20
Sent: Wednesday, July 14, 2004 9:35 AM=20
To: Megaco@ietf.org=20
Subject: [Megaco] Add command with NULL context=20

Hi List,=20
 =20
can someone clarify hat would be the correct answer to message below?=20
 =20
 =20
MEGACO/2 [123.123.123.4]:55555=20
Transaction =3D 10003 {=20
    Context =3D - {=20
       Add =3D $ {=20
          ....=20
       }=20
    }=20
} =20

I guess using NULL context in an add command is an error, independently =
the value of the termination Id.=20
It is written hat if the ROOT termination is addressed the 410 =
"Incorrect identifier" Shall be returned, but what are the error codes =
in case of using a specific, CHOOSE or ALL wildcards?=20

It is also my question if this error description should be on the =
command or Action level, as by the syntax it is possible to include an =
error descriptor inside the ActioReply with an empty list of command.

Thank you for any suggestions!=20
Best regards,=20
  Csaba Koppany=20

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



------------------------------=20

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


End of Megaco Digest, Vol 3, Issue 9=20
************************************=20


------_=_NextPart_001_01C46ADF.75E96DA0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dgb2312">
<TITLE>RE: [Megaco] Add command with NULL context</TITLE>

<META content=3D"MSHTML 5.00.3700.6699" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff size=3D2><SPAN =
class=3D006314702-16072004>Right, sorry, I=20
ignored the command is add, if servicechange command ,it can do=20
</SPAN></FONT></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT=20
  =
size=3D2>-----=D4=AD=CA=BC=D3=CA=BC=FE-----<BR><B>=B7=A2=BC=FE=C8=CB:</B>=
 Kevin Boyle=20
  [mailto:kboyle@nortelnetworks.com]<BR><B>=B7=A2=CB=CD=CA=B1=BC=E4:</B> =
2004=C4=EA7=D4=C216=C8=D5=20
  10:39<BR><B>=CA=D5=BC=FE=C8=CB:</B> =D1=EE=CF=C8=B2=A8; =
megaco@ietf.org<BR><B>=D6=F7=CC=E2:</B> RE: [Megaco] Add=20
  command with NULL context<BR><BR></DIV></FONT>
  <P><FONT size=3D2>Regardless of which termination it is, Add to NULL =
is=20
  illegal.&nbsp; An Add of ROOT to anything is also illegal.&nbsp; The =
question=20
  was what the response to such a command would be.</FONT></P>
  <P><FONT size=3D2>Note that an Add to ALL is guaranteed to return an =
error,=20
  except in the case of there being only a single context.&nbsp; So that =
is a=20
  fairly silly combination as well.</FONT></P>
  <P><FONT size=3D2>Kevin </FONT></P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  yxb@cpit.com.cn [<A =
href=3D"mailto:yxb@cpit.com.cn">mailto:yxb@cpit.com.cn</A>]=20
  </FONT><BR><FONT size=3D2>Sent: Thursday, July 15, 2004 9:18 PM</FONT> =
<BR><FONT=20
  size=3D2>To: megaco@ietf.org</FONT> <BR><FONT size=3D2>Subject: Re: =
[Megaco] Add=20
  command with NULL context</FONT> </P>
  <P><FONT size=3D2>But as I know, if termination is ROOT, it presents =
the MGW, so=20
  context should be null,which is not necessary; if specific, CHOOSE or =
ALL,=20
  context not null.Just my viewpoint.</FONT></P>
  <P><FONT size=3D2>-----=D4=AD=CA=BC=D3=CA=BC=FE-----</FONT> <BR><FONT =
size=3D2>=B7=A2=BC=FE=C8=CB:=20
  megaco-bounces@ietf.org [<A=20
  =
href=3D"mailto:megaco-bounces@ietf.org">mailto:megaco-bounces@ietf.org</A=
>]=B4=FA=B1=ED=20
  megaco-request@ietf.org</FONT> <BR><FONT =
size=3D2>=B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA7=D4=C216=C8=D5 0:12</FONT> =

  <BR><FONT size=3D2>=CA=D5=BC=FE=C8=CB: megaco@ietf.org</FONT> =
<BR><FONT size=3D2>=D6=F7=CC=E2: Megaco=20
  Digest, Vol 3, Issue 9</FONT> </P><BR>
  <P><FONT size=3D2>Send Megaco mailing list submissions to</FONT>=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
  size=3D2>megaco@ietf.org</FONT> </P>
  <P><FONT size=3D2>To subscribe or unsubscribe via the World Wide Web,=20
  visit</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
size=3D2><A=20
  href=3D"https://www1.ietf.org/mailman/listinfo/megaco"=20
  =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> =

  <BR><FONT size=3D2>or, via email, send a message with subject or body =
'help'=20
  to</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
  size=3D2>megaco-request@ietf.org</FONT> </P>
  <P><FONT size=3D2>You can reach the person managing the list at</FONT> =

  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
  size=3D2>megaco-owner@ietf.org</FONT> </P>
  <P><FONT size=3D2>When replying, please edit your Subject line so it =
is more=20
  specific than "Re: Contents of Megaco digest..."</FONT> </P><BR>
  <P><FONT size=3D2>Today's Topics:</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; 1. RE: Add command with NULL context =
(Kevin=20
  Boyle)</FONT> </P><BR>
  <P><FONT=20
  =
size=3D2>----------------------------------------------------------------=
------</FONT>=20
  </P>
  <P><FONT size=3D2>Message: 1</FONT> <BR><FONT size=3D2>Date: Wed, 14 =
Jul 2004=20
  13:06:51 -0400</FONT> <BR><FONT size=3D2>From: "Kevin Boyle"=20
  &lt;kboyle@nortelnetworks.com&gt;</FONT> <BR><FONT size=3D2>Subject: =
RE:=20
  [Megaco] Add command with NULL context</FONT> <BR><FONT size=3D2>To: =
Csaba=20
  Koppany &lt;Csaba.Koppany@etsi.org&gt;, Megaco@ietf.org</FONT> =
<BR><FONT=20
  size=3D2>Message-ID:</FONT> =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
  =
size=3D2>&lt;ABA227A15B80D511BD1A00508BF93A1C1284459D@zrtpd0jq.us.nortel.=
com&gt;</FONT>=20
  </P>
  <P><FONT size=3D2>Seems to me that this would be a protocol error =
(401).</FONT>=20
  </P>
  <P><FONT size=3D2>Try: !/1 [12.34.56.78]:2944 =
P=3D10003{C=3D-{ER=3D401{"That's not=20
  allowed!"}}}</FONT> </P>
  <P><FONT size=3D2>Kevin </FONT></P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Csaba=20
  Koppany [<A=20
  =
href=3D"mailto:Csaba.Koppany@etsi.org">mailto:Csaba.Koppany@etsi.org</A>]=
</FONT>=20
  <BR><FONT size=3D2>Sent: Wednesday, July 14, 2004 9:35 AM</FONT> =
<BR><FONT=20
  size=3D2>To: Megaco@ietf.org</FONT> <BR><FONT size=3D2>Subject: =
[Megaco] Add=20
  command with NULL context</FONT> </P>
  <P><FONT size=3D2>Hi List,</FONT> <BR><FONT size=3D2>&nbsp;</FONT> =
<BR><FONT=20
  size=3D2>can someone clarify hat would be the correct answer to =
message=20
  below?</FONT> <BR><FONT size=3D2>&nbsp;</FONT> <BR><FONT =
size=3D2>&nbsp;</FONT>=20
  <BR><FONT size=3D2>MEGACO/2 [123.123.123.4]:55555</FONT> <BR><FONT=20
  size=3D2>Transaction =3D 10003 {</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  Context =3D - {</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add=20
  =3D $ {</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
....</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; }</FONT> <BR><FONT size=3D2>}&nbsp; =
</FONT></P>
  <P><FONT size=3D2>I guess using NULL context in an add command is an =
error,=20
  independently the value of the termination Id.</FONT> <BR><FONT =
size=3D2>It is=20
  written hat if the ROOT termination is addressed the 410 "Incorrect=20
  identifier" Shall be returned, but what are the error codes in case of =
using a=20
  specific, CHOOSE or ALL wildcards? </FONT></P>
  <P><FONT size=3D2>It is also my question if this error description =
should be on=20
  the command or Action level, as by the syntax it is possible to =
include an=20
  error descriptor inside the ActioReply with an empty list of=20
  command.</FONT></P>
  <P><FONT size=3D2>Thank you for any suggestions!</FONT> <BR><FONT =
size=3D2>Best=20
  regards,</FONT> <BR><FONT size=3D2>&nbsp; Csaba Koppany</FONT> </P>
  <P><FONT =
size=3D2>_______________________________________________</FONT>=20
  <BR><FONT size=3D2>Megaco mailing list</FONT> <BR><FONT=20
  size=3D2>Megaco@ietf.org</FONT> <BR><FONT size=3D2><A=20
  href=3D"https://www1.ietf.org/mailman/listinfo/megaco"=20
  =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> =

  </P><BR><BR>
  <P><FONT size=3D2>------------------------------</FONT> </P>
  <P><FONT =
size=3D2>_______________________________________________</FONT>=20
  <BR><FONT size=3D2>Megaco mailing list</FONT> <BR><FONT=20
  size=3D2>Megaco@ietf.org</FONT> <BR><FONT size=3D2><A=20
  href=3D"https://www1.ietf.org/mailman/listinfo/megaco"=20
  =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> =

</P><BR>
  <P><FONT size=3D2>End of Megaco Digest, Vol 3, Issue 9</FONT> =
<BR><FONT=20
  size=3D2>************************************</FONT>=20
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C46ADF.75E96DA0--


--===============0118703201==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============0118703201==--



From megaco-bounces@ietf.org  Fri Jul 16 00:18:49 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17020
	for <megaco-archive@lists.ietf.org>; Fri, 16 Jul 2004 00:18:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BlK5v-0001WU-Od; Fri, 16 Jul 2004 00: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 1BlK1X-0008Tr-6i
	for megaco@megatron.ietf.org; Fri, 16 Jul 2004 00:08:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16486
	for <megaco@ietf.org>; Fri, 16 Jul 2004 00:08:34 -0400 (EDT)
From: bvswamy@hss.hns.com
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BlK1T-00025Z-Jc
	for megaco@ietf.org; Fri, 16 Jul 2004 00:08:35 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BlK0V-0001lV-00
	for megaco@ietf.org; Fri, 16 Jul 2004 00:07:36 -0400
Received: from spark.hss.co.in ([203.200.71.140])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BlJzf-00018i-00; Fri, 16 Jul 2004 00:06:44 -0400
Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged))
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i6G43oON018073;
	Fri, 16 Jul 2004 09:33:51 +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 i6G46S823442;
	Fri, 16 Jul 2004 09:36:28 +0530 (IST)
In-Reply-To: <006A9E7E02D21C45AC3CB741AEBF844E01719AC9@mail.putian.com>
Subject: Re: [Megaco] Add command with NULL context
To: =?GB2312?B?0e7PyLKo?= <yxb@cpit.com.cn>
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OF20A67D7B.417654D3-ON65256ED3.00158554-65256ED3.00165ECE@hss.hns.com>
Date: Fri, 16 Jul 2004 09:31:00 +0530
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26,
	2002) at 16/07/2004 09:23:13 AM
MIME-Version: 1.0
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=2.8 required=5.0 tests=AWL,NO_REAL_NAME,
	ROUND_THE_WORLD_LOCAL autolearn=no version=2.60
Cc: megaco-bounces@ietf.org, megaco@ietf.org,
        Kevin Boyle <kboyle@nortelnetworks.com>
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="===============2035107104=="
Sender: megaco-bounces@ietf.org
Errors-To: megaco-bounces@ietf.org

--===============2035107104==
Content-type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

DQoNCg0KDQpIaQ0KICAgICAgTm90IG9ubHkgU2VydmljZUNoYW5nZSBjb21tYW5kLCBhIE1PRElG
WSBjb21tYW5kIGNhbiBhbHNvIGNvbWUgd2l0aA0KQUxMLCBQYXJ0aWFsQUxMLCBTcGVjaWZpYywg
TnVsbCBmb3IgY29udGV4dCBpZHMgYW5kIEFMTCwgUGFydGlhbEFMTCwNClNwZWNpZmljIGZvciB0
ZXJtaW5hdGlvbklEcy4gQ0hPT1NFIGlzIG5vdCBhIHZhbGlkIG9wdGlvbiBmb3IgTW9kaWZ5DQpj
b21tYW5kIGJvdGggZm9yIENvbnRleHQgYW5kIFRlcm1pbmF0aW9uIGlkcy4NCg0KDQpSZWdhcmRz
DQpCIFZlbmthdCBTLlIgU3dhbXkNCkh1Z2hlcyBTb2Z0d2FyZSBTeXN0ZW1zDQpQaG9uZTogICs5
MS0xMjQtMjQ1NTU1NSBFeHRuIDM2MjANCkZheDogKzkxLTEyNC0yNDU1MzQ1DQp3ZWI6IHd3dy5o
c3N3b3JsZC5jb20NCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIOadqOWF
iOazoiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgDQogICAgICAgICAgICAgPHl4YkBjcGl0LmNvbS5jbj4gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICBTZW50IGJ5OiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRvIA0KICAgICAgICAgICAg
IG1lZ2Fjby1ib3VuY2VzQGllICAgICAgICAgIktldmluIEJveWxlIiAgICAgICAgICAgICAgICAg
ICAgICAgDQogICAgICAgICAgICAgdGYub3JnICAgICAgICAgICAgICAgICAgICA8a2JveWxlQG5v
cnRlbG5ldHdvcmtzLmNvbT4sICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDxtZWdhY29AaWV0Zi5vcmc+ICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgY2MgDQogICAgICAgICAgICAgMDcvMTYvMjAwNCAwODoxOSAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICBBTSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdWJqZWN0IA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmU6IFtNZWdhY29dIEFkZCBjb21tYW5k
IHdpdGggTlVMTCAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb250
ZXh0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQoNCg0KDQpSaWdodCwg
c29ycnksIEkgIGlnbm9yZWQgdGhlIGNvbW1hbmQgaXMgYWRkLCBpZiBzZXJ2aWNlY2hhbmdlIGNv
bW1hbmQgLGl0DQpjYW4gZG8NCi0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0NCuWPkeS7tuS6ujogS2V2
aW4gQm95bGUgIFttYWlsdG86a2JveWxlQG5vcnRlbG5ldHdvcmtzLmNvbV0NCuWPkemAgeaXtumX
tDogMjAwNOW5tDfmnIgxNuaXpSAgMTA6MzkNCuaUtuS7tuS6ujog5p2o5YWI5rOiOyBtZWdhY29A
aWV0Zi5vcmcNCuS4u+mimDogUkU6IFtNZWdhY29dIEFkZCAgY29tbWFuZCB3aXRoIE5VTEwgY29u
dGV4dA0KDQoNCg0KUmVnYXJkbGVzcyBvZiB3aGljaCB0ZXJtaW5hdGlvbiBpdCBpcywgQWRkIHRv
IE5VTEwgaXMgIGlsbGVnYWwuwqAgQW4gQWRkIG9mDQpST09UIHRvIGFueXRoaW5nIGlzIGFsc28g
aWxsZWdhbC7CoCBUaGUgcXVlc3Rpb24gIHdhcyB3aGF0IHRoZSByZXNwb25zZSB0bw0Kc3VjaCBh
IGNvbW1hbmQgd291bGQgYmUuDQoNCk5vdGUgdGhhdCBhbiBBZGQgdG8gQUxMIGlzIGd1YXJhbnRl
ZWQgdG8gcmV0dXJuIGFuIGVycm9yLCAgZXhjZXB0IGluIHRoZQ0KY2FzZSBvZiB0aGVyZSBiZWlu
ZyBvbmx5IGEgc2luZ2xlIGNvbnRleHQuwqAgU28gdGhhdCBpcyBhICBmYWlybHkgc2lsbHkNCmNv
bWJpbmF0aW9uIGFzIHdlbGwuDQoNCktldmluDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiAgeXhiQGNwaXQuY29tLmNuIFttYWlsdG86eXhiQGNwaXQuY29tLmNuXQ0KU2VudDog
VGh1cnNkYXksIEp1bHkgMTUsIDIwMDQgOToxOCBQTQ0KVG86IG1lZ2Fjb0BpZXRmLm9yZw0KU3Vi
amVjdDogUmU6IFtNZWdhY29dIEFkZCAgY29tbWFuZCB3aXRoIE5VTEwgY29udGV4dA0KDQpCdXQg
YXMgSSBrbm93LCBpZiB0ZXJtaW5hdGlvbiBpcyBST09ULCBpdCBwcmVzZW50cyB0aGUgTUdXLCBz
byAgY29udGV4dA0Kc2hvdWxkIGJlIG51bGwsd2hpY2ggaXMgbm90IG5lY2Vzc2FyeTsgaWYgc3Bl
Y2lmaWMsIENIT09TRSBvciBBTEwsICBjb250ZXh0DQpub3QgbnVsbC5KdXN0IG15IHZpZXdwb2lu
dC4NCg0KLS0tLS3ljp/lp4vpgq7ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiAgbWVnYWNvLWJvdW5jZXNA
aWV0Zi5vcmcgW21haWx0bzptZWdhY28tYm91bmNlc0BpZXRmLm9yZ13ku6PooagNCm1lZ2Fjby1y
ZXF1ZXN0QGlldGYub3JnDQrlj5HpgIHml7bpl7Q6IDIwMDTlubQ35pyIMTbml6UgMDoxMg0K5pS2
5Lu25Lq6OiBtZWdhY29AaWV0Zi5vcmcNCuS4u+mimDogTWVnYWNvICBEaWdlc3QsIFZvbCAzLCBJ
c3N1ZSA5DQoNClNlbmQgTWVnYWNvIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bw0KwqDCoMKg
wqDCoMKgwqAgbWVnYWNvQGlldGYub3JnDQoNClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2
aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCAgdmlzaXQNCsKgwqDCoMKgwqDCoMKgIGh0dHBzOi8vd3d3
MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21lZ2Fjbw0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBh
IG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnICB0bw0KwqDCoMKgwqDCoMKgwqAg
bWVnYWNvLXJlcXVlc3RAaWV0Zi5vcmcNCg0KWW91IGNhbiByZWFjaCB0aGUgcGVyc29uIG1hbmFn
aW5nIHRoZSBsaXN0IGF0DQrCoMKgwqDCoMKgwqDCoCBtZWdhY28tb3duZXJAaWV0Zi5vcmcNCg0K
V2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9y
ZSAgc3BlY2lmaWMgdGhhbg0KIlJlOiBDb250ZW50cyBvZiBNZWdhY28gZGlnZXN0Li4uIg0KDQpU
b2RheSdzIFRvcGljczoNCg0KwqDCoCAxLiBSRTogQWRkIGNvbW1hbmQgd2l0aCBOVUxMIGNvbnRl
eHQgKEtldmluICBCb3lsZSkNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNZXNzYWdlOiAxDQpEYXRlOiBX
ZWQsIDE0IEp1bCAyMDA0ICAxMzowNjo1MSAtMDQwMA0KRnJvbTogIktldmluIEJveWxlIiAgPGti
b3lsZUBub3J0ZWxuZXR3b3Jrcy5jb20+DQpTdWJqZWN0OiBSRTogIFtNZWdhY29dIEFkZCBjb21t
YW5kIHdpdGggTlVMTCBjb250ZXh0DQpUbzogQ3NhYmEgIEtvcHBhbnkgPENzYWJhLktvcHBhbnlA
ZXRzaS5vcmc+LCBNZWdhY29AaWV0Zi5vcmcNCk1lc3NhZ2UtSUQ6DQrCoMKgwqDCoMKgwqDCoCA8
QUJBMjI3QTE1QjgwRDUxMUJEMUEwMDUwOEJGOTNBMUMxMjg0NDU5REB6cnRwZDBqcS51cy5ub3J0
ZWwuY29tPg0KDQpTZWVtcyB0byBtZSB0aGF0IHRoaXMgd291bGQgYmUgYSBwcm90b2NvbCBlcnJv
ciAoNDAxKS4NCg0KVHJ5OiAhLzEgWzEyLjM0LjU2Ljc4XToyOTQ0IFA9MTAwMDN7Qz0te0VSPTQw
MXsiVGhhdCdzIG5vdCAgYWxsb3dlZCEifX19DQoNCktldmluDQoNCi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQpGcm9tOiBDc2FiYSAgS29wcGFueSBbbWFpbHRvOkNzYWJhLktvcHBhbnlAZXRz
aS5vcmddDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMTQsIDIwMDQgOTozNSBBTQ0KVG86IE1lZ2Fj
b0BpZXRmLm9yZw0KU3ViamVjdDogW01lZ2Fjb10gQWRkICBjb21tYW5kIHdpdGggTlVMTCBjb250
ZXh0DQoNCkhpIExpc3QsDQoNCmNhbiBzb21lb25lIGNsYXJpZnkgaGF0IHdvdWxkIGJlIHRoZSBj
b3JyZWN0IGFuc3dlciB0byBtZXNzYWdlICBiZWxvdz8NCg0KDQpNRUdBQ08vMiBbMTIzLjEyMy4x
MjMuNF06NTU1NTUNClRyYW5zYWN0aW9uID0gMTAwMDMgew0KwqDCoMKgICBDb250ZXh0ID0gLSB7
DQrCoMKgwqDCoMKgwqAgQWRkICA9ICQgew0KwqDCoMKgwqDCoMKgwqDCoMKgIC4uLi4NCsKgwqDC
oMKgwqDCoCB9DQrCoMKgwqAgfQ0KfQ0KDQpJIGd1ZXNzIHVzaW5nIE5VTEwgY29udGV4dCBpbiBh
biBhZGQgY29tbWFuZCBpcyBhbiBlcnJvciwgIGluZGVwZW5kZW50bHkNCnRoZSB2YWx1ZSBvZiB0
aGUgdGVybWluYXRpb24gSWQuDQpJdCBpcyAgd3JpdHRlbiBoYXQgaWYgdGhlIFJPT1QgdGVybWlu
YXRpb24gaXMgYWRkcmVzc2VkIHRoZSA0MTAgIkluY29ycmVjdA0KaWRlbnRpZmllciIgU2hhbGwg
YmUgcmV0dXJuZWQsIGJ1dCB3aGF0IGFyZSB0aGUgZXJyb3IgY29kZXMgaW4gY2FzZSBvZg0KdXNp
bmcgYSAgc3BlY2lmaWMsIENIT09TRSBvciBBTEwgd2lsZGNhcmRzPw0KDQpJdCBpcyBhbHNvIG15
IHF1ZXN0aW9uIGlmIHRoaXMgZXJyb3IgZGVzY3JpcHRpb24gc2hvdWxkIGJlIG9uICB0aGUgY29t
bWFuZA0Kb3IgQWN0aW9uIGxldmVsLCBhcyBieSB0aGUgc3ludGF4IGl0IGlzIHBvc3NpYmxlIHRv
IGluY2x1ZGUgYW4gIGVycm9yDQpkZXNjcmlwdG9yIGluc2lkZSB0aGUgQWN0aW9SZXBseSB3aXRo
IGFuIGVtcHR5IGxpc3Qgb2YgIGNvbW1hbmQuDQoNClRoYW5rIHlvdSBmb3IgYW55IHN1Z2dlc3Rp
b25zIQ0KQmVzdCAgcmVnYXJkcywNCsKgIENzYWJhIEtvcHBhbnkNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1lZ2FjbyBtYWlsaW5nIGxpc3QNCk1l
Z2Fjb0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVn
YWNvDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpNZWdhY28gbWFpbGluZyBsaXN0DQpN
ZWdhY29AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21l
Z2Fjbw0KDQpFbmQgb2YgTWVnYWNvIERpZ2VzdCwgVm9sIDMsIElzc3VlIDkNCioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KTWVnYWNvIG1haWxpbmcgbGlzdA0KTWVnYWNvQGlldGYub3Jn
DQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZWdhY28NCg==




--===============2035107104==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============2035107104==--


From megaco-bounces@ietf.org  Fri Jul 16 03:50:51 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12552
	for <megaco-archive@lists.ietf.org>; Fri, 16 Jul 2004 03:50:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BlNMr-0002kh-3H; Fri, 16 Jul 2004 03:42:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BlNJC-0001wB-TF
	for megaco@megatron.ietf.org; Fri, 16 Jul 2004 03:39:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12003
	for <megaco@ietf.org>; Fri, 16 Jul 2004 03:39:00 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BlNJ5-0002co-2S
	for megaco@ietf.org; Fri, 16 Jul 2004 03:38:59 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BlNHz-0002I4-00
	for megaco@ietf.org; Fri, 16 Jul 2004 03:37:52 -0400
Received: from email10.etsi.org ([212.234.161.112] helo=email10.etsihq.org)
	by ietf-mx with esmtp (Exim 4.12) id 1BlNHH-0001jJ-00
	for megaco@ietf.org; Fri, 16 Jul 2004 03:37:07 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Megaco] Add command with NULL context
Date: Fri, 16 Jul 2004 09:36:37 +0200
Message-ID: <4091553999CBE4409CC2B562152B5A339A96A5@email10.etsihq.org>
Thread-Topic: [Megaco] Add command with NULL context
Thread-Index: AcRq6/EgRxFqpz9cRJ2V31E6IOzTkgAG5kug
From: "Csaba Koppany" <Csaba.Koppany@etsi.org>
To: <megaco@ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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="===============0726796962=="
Sender: megaco-bounces@ietf.org
Errors-To: megaco-bounces@ietf.org

--===============0726796962==
content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCiBJIGtub3cgdGhhdCB0aGVyZSBhcmUgbWFueSBpbnZhbGlkIGNvbWJpbmF0aW9ucywg
YXMgaW4geW91ciBleGFtcGxlIHVzaW5nIENIT09TRSBpbiBhIE1vZGlmeSBjb21tYW5kLg0KDQpC
VVQhIFdoYXQgd291bGQgYmUgdGhlIGNvcnJlY3QgcmVzcG9uc2UgaW4gY2FzZSBvZiBzdWNoIGFu
IGludmFsaWQgY29tYmluYXRpb25zIG9mIGNvbW1hbmRzIGFuZCB3aWxkY2FyZGVkIGNvbnRleHQg
b3IgdGVybWluYXRpb24gSWQ/IEFzIGluIHRoZSBleGFtcGxlIGFib3ZlLCB3b3VsZCBiZSB0aGUg
aW52YWxpZCBjb250ZXh0IGFuZCB0ZXJtaW5hdGlvbiBpZHMgcmVwZWF0ZWQgaW4gdGhlIHJlc3Bv
bnNlIGNvbnRhaW5pbmcgYW4gZXJyb3IgZGVzY3JpcHRvcj8NCg0KSSB0aGluayB0aGUgSC4yNDgu
MSByZWNvbW1lbmRhdGlvbiBpcyBub3Qgc3BlY2lmeSBzdHJpY3RseSB0aGUgZXJyb3IgaGFuZGxp
bmcgaW4gc3VjaCBjYXNlcy4gVGhhdCBtYWtlIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbiBjb3Vs
ZCBhbnN3ZXIgaW4gZGlmZmVyZW50IHdheS4gQXMgSSBhbSBtYWludGFpbmluZyB0aGUgSC4yNDgg
Y29uZm9ybWFuY2UgdGVzdCBzdWl0ZSBpbiBhbiBFVFNpIFNURiwgaXQgaXMgaGFyZCB0byB3cml0
ZSBlcnJvciBoYW5kbGluZyB0ZXN0IGNhc2VzIGlmIHRoZSBoYW5kbGluZyBvZiBhbiBlcnJvciBp
cyBkZXBlbmQgb24gdGhlIGltcGxlbmV0YXRpb24uIFRoYXQgd2FzIHRoZSByZWFzb24gb2YgbXkg
b3JpZ2luYWwgcXVlc3Rpb24uDQoNClRoYW5rcywNCiAgQ3NhYmEuIA0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KRnJvbTogYnZzd2FteUBoc3MuaG5zLmNvbSBbbWFpbHRvOmJ2c3dhbXlA
aHNzLmhucy5jb21dIA0KU2VudDogMTYgSnVseSAyMDA0IDA2OjAxDQpUbzog5p2o5YWI5rOiDQpD
YzogbWVnYWNvLWJvdW5jZXNAaWV0Zi5vcmc7IG1lZ2Fjb0BpZXRmLm9yZzsgS2V2aW4gQm95bGUN
ClN1YmplY3Q6IFJlOiBbTWVnYWNvXSBBZGQgY29tbWFuZCB3aXRoIE5VTEwgY29udGV4dA0KDQoN
Cg0KDQoNCkhpDQogICAgICBOb3Qgb25seSBTZXJ2aWNlQ2hhbmdlIGNvbW1hbmQsIGEgTU9ESUZZ
IGNvbW1hbmQgY2FuIGFsc28gY29tZSB3aXRoIEFMTCwgUGFydGlhbEFMTCwgU3BlY2lmaWMsIE51
bGwgZm9yIGNvbnRleHQgaWRzIGFuZCBBTEwsIFBhcnRpYWxBTEwsIFNwZWNpZmljIGZvciB0ZXJt
aW5hdGlvbklEcy4gQ0hPT1NFIGlzIG5vdCBhIHZhbGlkIG9wdGlvbiBmb3IgTW9kaWZ5IGNvbW1h
bmQgYm90aCBmb3IgQ29udGV4dCBhbmQgVGVybWluYXRpb24gaWRzLg0KDQoNClJlZ2FyZHMNCkIg
VmVua2F0IFMuUiBTd2FteQ0KSHVnaGVzIFNvZnR3YXJlIFN5c3RlbXMNClBob25lOiAgKzkxLTEy
NC0yNDU1NTU1IEV4dG4gMzYyMA0KRmF4OiArOTEtMTI0LTI0NTUzNDUNCndlYjogd3d3Lmhzc3dv
cmxkLmNvbQ0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg5p2o5YWI5rOi
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN
CiAgICAgICAgICAgICA8eXhiQGNwaXQuY29tLmNuPiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIFNlbnQgYnk6ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVG8gDQogICAgICAgICAgICAgbWVn
YWNvLWJvdW5jZXNAaWUgICAgICAgICAiS2V2aW4gQm95bGUiICAgICAgICAgICAgICAgICAgICAg
ICANCiAgICAgICAgICAgICB0Zi5vcmcgICAgICAgICAgICAgICAgICAgIDxrYm95bGVAbm9ydGVs
bmV0d29ya3MuY29tPiwgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPG1lZ2Fjb0BpZXRmLm9yZz4gICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBjYyANCiAgICAgICAgICAgICAwNy8xNi8yMDA0IDA4OjE5ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIEFNICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN1YmplY3QgDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZTogW01lZ2Fjb10gQWRkIGNvbW1hbmQgd2l0
aCBOVUxMICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRleHQg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCg0KDQoNClJpZ2h0LCBzb3Jy
eSwgSSAgaWdub3JlZCB0aGUgY29tbWFuZCBpcyBhZGQsIGlmIHNlcnZpY2VjaGFuZ2UgY29tbWFu
ZCAsaXQgY2FuIGRvDQotLS0tLeWOn+Wni+mCruS7ti0tLS0tDQrlj5Hku7bkuro6IEtldmluIEJv
eWxlICBbbWFpbHRvOmtib3lsZUBub3J0ZWxuZXR3b3Jrcy5jb21dDQrlj5HpgIHml7bpl7Q6IDIw
MDTlubQ35pyIMTbml6UgIDEwOjM5DQrmlLbku7bkuro6IOadqOWFiOazojsgbWVnYWNvQGlldGYu
b3JnDQrkuLvpopg6IFJFOiBbTWVnYWNvXSBBZGQgIGNvbW1hbmQgd2l0aCBOVUxMIGNvbnRleHQN
Cg0KDQoNClJlZ2FyZGxlc3Mgb2Ygd2hpY2ggdGVybWluYXRpb24gaXQgaXMsIEFkZCB0byBOVUxM
IGlzICBpbGxlZ2FsLsKgIEFuIEFkZCBvZiBST09UIHRvIGFueXRoaW5nIGlzIGFsc28gaWxsZWdh
bC7CoCBUaGUgcXVlc3Rpb24gIHdhcyB3aGF0IHRoZSByZXNwb25zZSB0byBzdWNoIGEgY29tbWFu
ZCB3b3VsZCBiZS4NCg0KTm90ZSB0aGF0IGFuIEFkZCB0byBBTEwgaXMgZ3VhcmFudGVlZCB0byBy
ZXR1cm4gYW4gZXJyb3IsICBleGNlcHQgaW4gdGhlIGNhc2Ugb2YgdGhlcmUgYmVpbmcgb25seSBh
IHNpbmdsZSBjb250ZXh0LsKgIFNvIHRoYXQgaXMgYSAgZmFpcmx5IHNpbGx5IGNvbWJpbmF0aW9u
IGFzIHdlbGwuDQoNCktldmluDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAg
eXhiQGNwaXQuY29tLmNuIFttYWlsdG86eXhiQGNwaXQuY29tLmNuXQ0KU2VudDogVGh1cnNkYXks
IEp1bHkgMTUsIDIwMDQgOToxOCBQTQ0KVG86IG1lZ2Fjb0BpZXRmLm9yZw0KU3ViamVjdDogUmU6
IFtNZWdhY29dIEFkZCAgY29tbWFuZCB3aXRoIE5VTEwgY29udGV4dA0KDQpCdXQgYXMgSSBrbm93
LCBpZiB0ZXJtaW5hdGlvbiBpcyBST09ULCBpdCBwcmVzZW50cyB0aGUgTUdXLCBzbyAgY29udGV4
dCBzaG91bGQgYmUgbnVsbCx3aGljaCBpcyBub3QgbmVjZXNzYXJ5OyBpZiBzcGVjaWZpYywgQ0hP
T1NFIG9yIEFMTCwgIGNvbnRleHQgbm90IG51bGwuSnVzdCBteSB2aWV3cG9pbnQuDQoNCi0tLS0t
5Y6f5aeL6YKu5Lu2LS0tLS0NCuWPkeS7tuS6ujogIG1lZ2Fjby1ib3VuY2VzQGlldGYub3JnIFtt
YWlsdG86bWVnYWNvLWJvdW5jZXNAaWV0Zi5vcmdd5Luj6KGoDQptZWdhY28tcmVxdWVzdEBpZXRm
Lm9yZw0K5Y+R6YCB5pe26Ze0OiAyMDA05bm0N+aciDE25pelIDA6MTINCuaUtuS7tuS6ujogbWVn
YWNvQGlldGYub3JnDQrkuLvpopg6IE1lZ2FjbyAgRGlnZXN0LCBWb2wgMywgSXNzdWUgOQ0KDQpT
ZW5kIE1lZ2FjbyBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8NCsKgwqDCoMKgwqDCoMKgIG1l
Z2Fjb0BpZXRmLm9yZw0KDQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3Js
ZCBXaWRlIFdlYiwgIHZpc2l0DQrCoMKgwqDCoMKgwqDCoCBodHRwczovL3d3dzEuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9tZWdhY28NCm9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdp
dGggc3ViamVjdCBvciBib2R5ICdoZWxwJyAgdG8NCsKgwqDCoMKgwqDCoMKgIG1lZ2Fjby1yZXF1
ZXN0QGlldGYub3JnDQoNCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlz
dCBhdA0KwqDCoMKgwqDCoMKgwqAgbWVnYWNvLW93bmVyQGlldGYub3JnDQoNCldoZW4gcmVwbHlp
bmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgIHNwZWNpZmlj
IHRoYW4NCiJSZTogQ29udGVudHMgb2YgTWVnYWNvIGRpZ2VzdC4uLiINCg0KVG9kYXkncyBUb3Bp
Y3M6DQoNCsKgwqAgMS4gUkU6IEFkZCBjb21tYW5kIHdpdGggTlVMTCBjb250ZXh0IChLZXZpbiAg
Qm95bGUpDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KTWVzc2FnZTogMQ0KRGF0ZTogV2VkLCAxNCBKdWwg
MjAwNCAgMTM6MDY6NTEgLTA0MDANCkZyb206ICJLZXZpbiBCb3lsZSIgIDxrYm95bGVAbm9ydGVs
bmV0d29ya3MuY29tPg0KU3ViamVjdDogUkU6ICBbTWVnYWNvXSBBZGQgY29tbWFuZCB3aXRoIE5V
TEwgY29udGV4dA0KVG86IENzYWJhICBLb3BwYW55IDxDc2FiYS5Lb3BwYW55QGV0c2kub3JnPiwg
TWVnYWNvQGlldGYub3JnDQpNZXNzYWdlLUlEOg0KwqDCoMKgwqDCoMKgwqAgPEFCQTIyN0ExNUI4
MEQ1MTFCRDFBMDA1MDhCRjkzQTFDMTI4NDQ1OURAenJ0cGQwanEudXMubm9ydGVsLmNvbT4NCg0K
U2VlbXMgdG8gbWUgdGhhdCB0aGlzIHdvdWxkIGJlIGEgcHJvdG9jb2wgZXJyb3IgKDQwMSkuDQoN
ClRyeTogIS8xIFsxMi4zNC41Ni43OF06Mjk0NCBQPTEwMDAze0M9LXtFUj00MDF7IlRoYXQncyBu
b3QgIGFsbG93ZWQhIn19fQ0KDQpLZXZpbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogQ3NhYmEgIEtvcHBhbnkgW21haWx0bzpDc2FiYS5Lb3BwYW55QGV0c2kub3JnXQ0KU2Vu
dDogV2VkbmVzZGF5LCBKdWx5IDE0LCAyMDA0IDk6MzUgQU0NClRvOiBNZWdhY29AaWV0Zi5vcmcN
ClN1YmplY3Q6IFtNZWdhY29dIEFkZCAgY29tbWFuZCB3aXRoIE5VTEwgY29udGV4dA0KDQpIaSBM
aXN0LA0KDQpjYW4gc29tZW9uZSBjbGFyaWZ5IGhhdCB3b3VsZCBiZSB0aGUgY29ycmVjdCBhbnN3
ZXIgdG8gbWVzc2FnZSAgYmVsb3c/DQoNCg0KTUVHQUNPLzIgWzEyMy4xMjMuMTIzLjRdOjU1NTU1
DQpUcmFuc2FjdGlvbiA9IDEwMDAzIHsNCsKgwqDCoCAgQ29udGV4dCA9IC0gew0KwqDCoMKgwqDC
oMKgIEFkZCAgPSAkIHsNCsKgwqDCoMKgwqDCoMKgwqDCoCAuLi4uDQrCoMKgwqDCoMKgwqAgfQ0K
wqDCoMKgIH0NCn0NCg0KSSBndWVzcyB1c2luZyBOVUxMIGNvbnRleHQgaW4gYW4gYWRkIGNvbW1h
bmQgaXMgYW4gZXJyb3IsICBpbmRlcGVuZGVudGx5IHRoZSB2YWx1ZSBvZiB0aGUgdGVybWluYXRp
b24gSWQuDQpJdCBpcyAgd3JpdHRlbiBoYXQgaWYgdGhlIFJPT1QgdGVybWluYXRpb24gaXMgYWRk
cmVzc2VkIHRoZSA0MTAgIkluY29ycmVjdCBpZGVudGlmaWVyIiBTaGFsbCBiZSByZXR1cm5lZCwg
YnV0IHdoYXQgYXJlIHRoZSBlcnJvciBjb2RlcyBpbiBjYXNlIG9mIHVzaW5nIGEgIHNwZWNpZmlj
LCBDSE9PU0Ugb3IgQUxMIHdpbGRjYXJkcz8NCg0KSXQgaXMgYWxzbyBteSBxdWVzdGlvbiBpZiB0
aGlzIGVycm9yIGRlc2NyaXB0aW9uIHNob3VsZCBiZSBvbiAgdGhlIGNvbW1hbmQgb3IgQWN0aW9u
IGxldmVsLCBhcyBieSB0aGUgc3ludGF4IGl0IGlzIHBvc3NpYmxlIHRvIGluY2x1ZGUgYW4gIGVy
cm9yIGRlc2NyaXB0b3IgaW5zaWRlIHRoZSBBY3Rpb1JlcGx5IHdpdGggYW4gZW1wdHkgbGlzdCBv
ZiAgY29tbWFuZC4NCg0KVGhhbmsgeW91IGZvciBhbnkgc3VnZ2VzdGlvbnMhDQpCZXN0ICByZWdh
cmRzLA0KwqAgQ3NhYmEgS29wcGFueQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KTWVnYWNvIG1haWxpbmcgbGlzdA0KTWVnYWNvQGlldGYub3JnDQpo
dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZWdhY28NCg0KDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCk1lZ2FjbyBtYWlsaW5nIGxpc3QNCk1lZ2Fjb0BpZXRmLm9yZw0K
aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVnYWNvDQoNCkVuZCBvZiBN
ZWdhY28gRGlnZXN0LCBWb2wgMywgSXNzdWUgOQ0KKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQpNZWdhY28gbWFpbGluZyBsaXN0DQpNZWdhY29AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21lZ2Fjbw0KDQoNCg==


--===============0726796962==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============0726796962==--


From megaco-bounces@ietf.org  Fri Jul 16 08:20:42 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25946
	for <megaco-archive@lists.ietf.org>; Fri, 16 Jul 2004 08:20:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BlRdV-0001R3-F6; Fri, 16 Jul 2004 08:16:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BlRb9-00018Q-G0
	for megaco@megatron.ietf.org; Fri, 16 Jul 2004 08:13:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25472
	for <megaco@ietf.org>; Fri, 16 Jul 2004 08:13:54 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BlRb6-0006K7-Of
	for megaco@ietf.org; Fri, 16 Jul 2004 08:13:52 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BlRZU-0005m7-00
	for megaco@ietf.org; Fri, 16 Jul 2004 08:12:13 -0400
Received: from mailrelay2.alcatel.de ([194.113.59.56]
	helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12)
	id 1BlRXD-00058h-00
	for megaco@ietf.org; Fri, 16 Jul 2004 08:09:51 -0400
Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10])
	by mailrelay1.alcatel.de (8.12.10/8.12.10) with ESMTP id
	i6GC9Li8019473; Fri, 16 Jul 2004 12:09:21 GMT
Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by
	ks.sel.alcatel.de with esmtp (Exim 3.31) id 1BlRWj-0003H0-00;
	Fri, 16 Jul 2004 14:09:21 +0200
Received: from slsufnt ([149.204.245.33] helo=alcatel.de) by
	slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id
	1BlRWj-0004r5-00; Fri, 16 Jul 2004 14:09:21 +0200
Message-ID: <40F7C570.4090402@alcatel.de>
Date: Fri, 16 Jul 2004 14:09:20 +0200
From: Juergen Stoetzer <J.Stoetzer@alcatel.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20030906
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Alcanet-virus-scanned: i6GC9Li8019473 at mailrelay1.alcatel.de
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Sequential Signal List Interrupted by an Event
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
Content-Transfer-Encoding: 7bit

Hello,

According to Section 7.1.9 of H.248.1 recognition of an event
causes any active signal to stop unless the KeepActive flag is set
for that event. More specifically, it is said that
"... event recognition may cause currently active signals to stop, ..." and
"Normally, recognition of an event shall cause any active signals to stop."

In both places "active signals" are mentioned.
My question is how this should be applied to sequential signal lists.

Let's assume the corresponding termination has an active Signals descriptor
containing a sequential signal list of two timeout signals S1 and S2.
Let's further assume an event (without set KeepActive flag) occurs
while the first timeout signal S1 is still playing.
It seems to be clear that that currently playing first signal S1 has to
be stopped.

But what about the not yet started second signal S2?
Should this be started at that point anyhow?
Or should it rather be omitted?

More generally, should recognition of an event only cause currently,
at that very point in time active signals to stop without influencing
possibly present not yet started signals in sequential signal lists?
Or should recognition of an event not only cause "currently active"
signals to stop but should rather cause the whole signals descriptor
to become "inactive" (as if replaced with an empty signals descriptor)?

Thanks a lot in advance for comments and ideas on this!

Best Regards,
Juergen Stoetzer



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


From megaco-bounces@ietf.org  Fri Jul 16 08:49:39 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27251
	for <megaco-archive@lists.ietf.org>; Fri, 16 Jul 2004 08:49:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BlS6x-0005DV-FC; Fri, 16 Jul 2004 08:46:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BlS1K-0004dD-So
	for megaco@megatron.ietf.org; Fri, 16 Jul 2004 08:40:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26905
	for <megaco@ietf.org>; Fri, 16 Jul 2004 08:40:57 -0400 (EDT)
From: bvswamy@hss.hns.com
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BlS1I-0007Ko-8i
	for megaco@ietf.org; Fri, 16 Jul 2004 08:40:56 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BlS0K-00070z-00
	for megaco@ietf.org; Fri, 16 Jul 2004 08:39:57 -0400
Received: from spark.hss.co.in ([203.200.71.140])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BlRzL-0006Ny-00; Fri, 16 Jul 2004 08:38:56 -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i6GCaDON029165;
	Fri, 16 Jul 2004 18:06:15 +0530 (IST)
In-Reply-To: <40F7C570.4090402@alcatel.de>
Subject: Re: [Megaco] Sequential Signal List Interrupted by an Event
To: Juergen Stoetzer <J.Stoetzer@alcatel.de>
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OFC4C38A9E.E8496390-ON65256ED3.00446B1A-65256ED3.00454A82@hss.hns.com>
Date: Fri, 16 Jul 2004 18:03:30 +0530
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26,
	2002) at 16/07/2004 05:55:48 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no 
	version=2.60
Cc: megaco@ietf.org, megaco-bounces@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





Hi
      An Event recognition without KeepActive flag  causes the currently
active signal descriptor to be disabled irrespective of the status of the
individual signals in the signal descriptor as if an embedded empty signal
descriptor got invoked.


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




                                                                           
             Juergen Stoetzer                                              
             <J.Stoetzer@alcat                                             
             el.de>                                                     To 
             Sent by:                  megaco@ietf.org                     
             megaco-bounces@ie                                          cc 
             tf.org                                                        
                                                                   Subject 
                                       [Megaco] Sequential Signal List     
             07/16/2004 05:39          Interrupted by an Event             
             PM                                                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hello,

According to Section 7.1.9 of H.248.1 recognition of an event
causes any active signal to stop unless the KeepActive flag is set
for that event. More specifically, it is said that
"... event recognition may cause currently active signals to stop, ..." and
"Normally, recognition of an event shall cause any active signals to stop."

In both places "active signals" are mentioned.
My question is how this should be applied to sequential signal lists.

Let's assume the corresponding termination has an active Signals descriptor
containing a sequential signal list of two timeout signals S1 and S2.
Let's further assume an event (without set KeepActive flag) occurs
while the first timeout signal S1 is still playing.
It seems to be clear that that currently playing first signal S1 has to
be stopped.

But what about the not yet started second signal S2?
Should this be started at that point anyhow?
Or should it rather be omitted?

More generally, should recognition of an event only cause currently,
at that very point in time active signals to stop without influencing
possibly present not yet started signals in sequential signal lists?
Or should recognition of an event not only cause "currently active"
signals to stop but should rather cause the whole signals descriptor
to become "inactive" (as if replaced with an empty signals descriptor)?

Thanks a lot in advance for comments and ideas on this!

Best Regards,
Juergen Stoetzer



_______________________________________________
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 Jul 16 10:02:30 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01932
	for <megaco-archive@lists.ietf.org>; Fri, 16 Jul 2004 10:02:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BlTFa-0005Xa-DJ; Fri, 16 Jul 2004 09:59:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BlTBz-0005D2-TA
	for megaco@megatron.ietf.org; Fri, 16 Jul 2004 09:56:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01539
	for <megaco@ietf.org>; Fri, 16 Jul 2004 09:56:01 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BlTBw-0001Kf-H3
	for megaco@ietf.org; Fri, 16 Jul 2004 09:56:00 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BlTAx-000119-00
	for megaco@ietf.org; Fri, 16 Jul 2004 09:55:00 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12) id 1BlT9x-0000PW-00
	for megaco@ietf.org; Fri, 16 Jul 2004 09:53:57 -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 i6GDrSj09954
	for <megaco@ietf.org>; Fri, 16 Jul 2004 09:53:28 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MXHSZSC0>; Fri, 16 Jul 2004 09:53:28 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C129257AA@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Juergen Stoetzer <J.Stoetzer@alcatel.de>, megaco@ietf.org
Subject: RE: [Megaco] Sequential Signal List Interrupted by an Event
Date: Fri, 16 Jul 2004 09:53:22 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
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

A sequential signal list is treated as if it were a single atomic signal.
In the case you describe, the signal list halts at the time of event
detection, so S1 is clipped and S2 is never started.

Note that in the absence of a signal list, signals play simultaneously, so
any signal that is not active will have already terminated on its own.

Kevin

-----Original Message-----
From: Juergen Stoetzer [mailto:J.Stoetzer@alcatel.de] 
Sent: Friday, July 16, 2004 8:09 AM
To: megaco@ietf.org
Subject: [Megaco] Sequential Signal List Interrupted by an Event

Hello,

According to Section 7.1.9 of H.248.1 recognition of an event causes any
active signal to stop unless the KeepActive flag is set for that event. More
specifically, it is said that "... event recognition may cause currently
active signals to stop, ..." and "Normally, recognition of an event shall
cause any active signals to stop."

In both places "active signals" are mentioned.
My question is how this should be applied to sequential signal lists.

Let's assume the corresponding termination has an active Signals descriptor
containing a sequential signal list of two timeout signals S1 and S2.
Let's further assume an event (without set KeepActive flag) occurs while the
first timeout signal S1 is still playing.
It seems to be clear that that currently playing first signal S1 has to be
stopped.

But what about the not yet started second signal S2?
Should this be started at that point anyhow?
Or should it rather be omitted?

More generally, should recognition of an event only cause currently, at that
very point in time active signals to stop without influencing possibly
present not yet started signals in sequential signal lists?
Or should recognition of an event not only cause "currently active"
signals to stop but should rather cause the whole signals descriptor to
become "inactive" (as if replaced with an empty signals descriptor)?

Thanks a lot in advance for comments and ideas on this!

Best Regards,
Juergen Stoetzer



_______________________________________________
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 Jul 16 10:05:02 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02341
	for <megaco-archive@lists.ietf.org>; Fri, 16 Jul 2004 10:05:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BlTGE-0005l8-St; Fri, 16 Jul 2004 10:00:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BlTCy-0005I3-JL
	for megaco@megatron.ietf.org; Fri, 16 Jul 2004 09:57:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01591
	for <megaco@ietf.org>; Fri, 16 Jul 2004 09:57:02 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BlTCv-0001eM-EJ
	for megaco@ietf.org; Fri, 16 Jul 2004 09:57:01 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BlTC1-0001LM-00
	for megaco@ietf.org; Fri, 16 Jul 2004 09:56:06 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12) id 1BlTBV-00011d-00
	for megaco@ietf.org; Fri, 16 Jul 2004 09:55:33 -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 i6GDt3j10273
	for <megaco@ietf.org>; Fri, 16 Jul 2004 09:55:03 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MXHSZSHC>; Fri, 16 Jul 2004 09:54:54 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C129257BB@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: bvswamy@hss.hns.com, Juergen Stoetzer <J.Stoetzer@alcatel.de>
Subject: RE: [Megaco] Sequential Signal List Interrupted by an Event
Date: Fri, 16 Jul 2004 09:54:50 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Cc: 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

Be careful here.  There is a subtle distinction between active signals and
the Signals descriptor.  I disagree with the idea that an event without a KA
flag is an implied embedded empty signals descriptor, since there may very
well be an embedded signals descriptor on the event.  The signals descriptor
itself is not being replaced -- the atomic signals themselves are stopping.

Kevin

-----Original Message-----
From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] 
Sent: Friday, July 16, 2004 8:34 AM
To: Juergen Stoetzer
Cc: megaco@ietf.org; megaco-bounces@ietf.org
Subject: Re: [Megaco] Sequential Signal List Interrupted by an Event





Hi
      An Event recognition without KeepActive flag  causes the currently
active signal descriptor to be disabled irrespective of the status of the
individual signals in the signal descriptor as if an embedded empty signal
descriptor got invoked.


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




                                                                           
             Juergen Stoetzer                                              
             <J.Stoetzer@alcat                                             
             el.de>                                                     To 
             Sent by:                  megaco@ietf.org                     
             megaco-bounces@ie                                          cc 
             tf.org                                                        
                                                                   Subject 
                                       [Megaco] Sequential Signal List     
             07/16/2004 05:39          Interrupted by an Event             
             PM                                                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hello,

According to Section 7.1.9 of H.248.1 recognition of an event causes any
active signal to stop unless the KeepActive flag is set for that event. More
specifically, it is said that "... event recognition may cause currently
active signals to stop, ..." and "Normally, recognition of an event shall
cause any active signals to stop."

In both places "active signals" are mentioned.
My question is how this should be applied to sequential signal lists.

Let's assume the corresponding termination has an active Signals descriptor
containing a sequential signal list of two timeout signals S1 and S2.
Let's further assume an event (without set KeepActive flag) occurs while the
first timeout signal S1 is still playing.
It seems to be clear that that currently playing first signal S1 has to be
stopped.

But what about the not yet started second signal S2?
Should this be started at that point anyhow?
Or should it rather be omitted?

More generally, should recognition of an event only cause currently, at that
very point in time active signals to stop without influencing possibly
present not yet started signals in sequential signal lists?
Or should recognition of an event not only cause "currently active"
signals to stop but should rather cause the whole signals descriptor to
become "inactive" (as if replaced with an empty signals descriptor)?

Thanks a lot in advance for comments and ideas on this!

Best Regards,
Juergen Stoetzer



_______________________________________________
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 Jul 19 00:43:20 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27538
	for <megaco-archive@lists.ietf.org>; Mon, 19 Jul 2004 00:43:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BmPxV-0000V8-CX; Mon, 19 Jul 2004 00:41:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BmPx8-0000Mc-MT
	for megaco@megatron.ietf.org; Mon, 19 Jul 2004 00:40:38 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27433
	for <megaco@ietf.org>; Mon, 19 Jul 2004 00:40:35 -0400 (EDT)
From: bvswamy@hss.hns.com
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BmPx6-0005FF-N0
	for megaco@ietf.org; Mon, 19 Jul 2004 00:40:36 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BmPwA-00053W-00
	for megaco@ietf.org; Mon, 19 Jul 2004 00:39:39 -0400
Received: from spark.hss.co.in ([203.200.71.140])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BmPvb-0004gW-00; Mon, 19 Jul 2004 00:39:04 -0400
Received: from sandesh.hss.hns.com (sandesh [172.16.32.19])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i6J4aGOP001675;
	Mon, 19 Jul 2004 10:06:25 +0530 (IST)
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C129257BB@zrtpd0jq.us.nortel.com>
Subject: RE: [Megaco] Sequential Signal List Interrupted by an Event
To: "Kevin Boyle" <kboyle@nortelnetworks.com>
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OF2308205B.49B24295-ON65256ED6.00155F9A-65256ED6.001961AC@hss.hns.com>
Date: Mon, 19 Jul 2004 10:03:42 +0530
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26,
	2002) at 19/07/2004 09:55:57 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no 
	version=2.60
Cc: megaco@ietf.org, Juergen Stoetzer <J.Stoetzer@alcatel.de>,
        megaco-bounces@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





Hi
      ACTIVE is the keyword there. Even if there is a embedded signal
descriptor, the currently ACTIVE signal descriptor has to be removed first
and then the embedded signal descriptor gets applied. So the logical steps
in handling a Event indication would be:
1) Report the Event to the Call Agent if the signal completion is armed.
2) Stop the signals thereby disabling the currently active signal
descriptor.
3) If there are any embedded descriptors present then activate them. In the
embedded case, the currently active signal descriptor is infact replaced by
the non-empty embedded signal descriptor.


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





                                                                           
             "Kevin Boyle"                                                 
             <kboyle@nortelnet                                             
             works.com>                                                 To 
             Sent by:                  B Venkat S.R Swamy/HSS@HSS, Juergen 
             megaco-bounces@ie         Stoetzer <J.Stoetzer@alcatel.de>    
             tf.org                                                     cc 
                                       megaco@ietf.org                     
                                                                   Subject 
             07/16/2004 07:24          RE: [Megaco] Sequential Signal List 
             PM                        Interrupted by an Event             
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Be careful here.  There is a subtle distinction between active signals and
the Signals descriptor.  I disagree with the idea that an event without a
KA
flag is an implied embedded empty signals descriptor, since there may very
well be an embedded signals descriptor on the event.  The signals
descriptor
itself is not being replaced -- the atomic signals themselves are stopping.

Kevin

-----Original Message-----
From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com]
Sent: Friday, July 16, 2004 8:34 AM
To: Juergen Stoetzer
Cc: megaco@ietf.org; megaco-bounces@ietf.org
Subject: Re: [Megaco] Sequential Signal List Interrupted by an Event





Hi
      An Event recognition without KeepActive flag  causes the currently
active signal descriptor to be disabled irrespective of the status of the
individual signals in the signal descriptor as if an embedded empty signal
descriptor got invoked.


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





             Juergen Stoetzer
             <J.Stoetzer@alcat
             el.de>                                                     To
             Sent by:                  megaco@ietf.org
             megaco-bounces@ie                                          cc
             tf.org
                                                                   Subject
                                       [Megaco] Sequential Signal List
             07/16/2004 05:39          Interrupted by an Event
             PM









Hello,

According to Section 7.1.9 of H.248.1 recognition of an event causes any
active signal to stop unless the KeepActive flag is set for that event.
More
specifically, it is said that "... event recognition may cause currently
active signals to stop, ..." and "Normally, recognition of an event shall
cause any active signals to stop."

In both places "active signals" are mentioned.
My question is how this should be applied to sequential signal lists.

Let's assume the corresponding termination has an active Signals descriptor
containing a sequential signal list of two timeout signals S1 and S2.
Let's further assume an event (without set KeepActive flag) occurs while
the
first timeout signal S1 is still playing.
It seems to be clear that that currently playing first signal S1 has to be
stopped.

But what about the not yet started second signal S2?
Should this be started at that point anyhow?
Or should it rather be omitted?

More generally, should recognition of an event only cause currently, at
that
very point in time active signals to stop without influencing possibly
present not yet started signals in sequential signal lists?
Or should recognition of an event not only cause "currently active"
signals to stop but should rather cause the whole signals descriptor to
become "inactive" (as if replaced with an empty signals descriptor)?

Thanks a lot in advance for comments and ideas on this!

Best Regards,
Juergen Stoetzer



_______________________________________________
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  Mon Jul 19 12:02:16 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00512
	for <megaco-archive@lists.ietf.org>; Mon, 19 Jul 2004 12:02:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BmaNm-0004aD-Ij; Mon, 19 Jul 2004 11:48:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BmaHn-0003xT-PN
	for megaco@megatron.ietf.org; Mon, 19 Jul 2004 11:42:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28643
	for <megaco@ietf.org>; Mon, 19 Jul 2004 11:42:36 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32) id 1BmaHm-0007ma-Vj
	for megaco@ietf.org; Mon, 19 Jul 2004 11:42:39 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BmaGP-0007Nj-00
	for megaco@ietf.org; Mon, 19 Jul 2004 11:41:14 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12) id 1BmaFB-0006kJ-00
	for megaco@ietf.org; Mon, 19 Jul 2004 11:39:57 -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 i6JFdPw21714
	for <megaco@ietf.org>; Mon, 19 Jul 2004 11:39:25 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MXHS6M3H>; Mon, 19 Jul 2004 11:39:26 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C129D6EB8@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: bvswamy@hss.hns.com
Subject: RE: [Megaco] Sequential Signal List Interrupted by an Event
Date: Mon, 19 Jul 2004 11:39:23 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Cc: megaco@ietf.org, Juergen Stoetzer <J.Stoetzer@alcatel.de>
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

Stop sending to megaco-bounces.  That is an admin interface to help weed out
spam.

The event reporting would occur AFTER the signal is stopped, not before.

You are talking about actual physical steps an MG might take to replace a
signals descriptor.  From a protocol point of view, however, a embedded
signals descriptor replaces the existing descriptor in a single step.
Speaking from the higher level view of the protocol:

1) The signals descriptor is replaced, halting any signals that are not
present in the new signals descriptor with the KA flag.
2) Notifications for any requested complete signals are sent.

As far as detection of an event, the signals descriptor is not replaced.
The signals are just halted (if the event does not contain the KA flag),
with the subsequent event notification for requested signal completion
following thereafter.

Kevin


-----Original Message-----
From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] 
Sent: Monday, July 19, 2004 12:34 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: Juergen Stoetzer; megaco@ietf.org; megaco-bounces@ietf.org
Subject: RE: [Megaco] Sequential Signal List Interrupted by an Event





Hi
      ACTIVE is the keyword there. Even if there is a embedded signal
descriptor, the currently ACTIVE signal descriptor has to be removed first
and then the embedded signal descriptor gets applied. So the logical steps
in handling a Event indication would be:
1) Report the Event to the Call Agent if the signal completion is armed.
2) Stop the signals thereby disabling the currently active signal
descriptor.
3) If there are any embedded descriptors present then activate them. In the
embedded case, the currently active signal descriptor is infact replaced by
the non-empty embedded signal descriptor.


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





                                                                           
             "Kevin Boyle"                                                 
             <kboyle@nortelnet                                             
             works.com>                                                 To 
             Sent by:                  B Venkat S.R Swamy/HSS@HSS, Juergen 
             megaco-bounces@ie         Stoetzer <J.Stoetzer@alcatel.de>    
             tf.org                                                     cc 
                                       megaco@ietf.org                     
                                                                   Subject 
             07/16/2004 07:24          RE: [Megaco] Sequential Signal List 
             PM                        Interrupted by an Event             
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Be careful here.  There is a subtle distinction between active signals and
the Signals descriptor.  I disagree with the idea that an event without a KA
flag is an implied embedded empty signals descriptor, since there may very
well be an embedded signals descriptor on the event.  The signals descriptor
itself is not being replaced -- the atomic signals themselves are stopping.

Kevin

-----Original Message-----
From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com]
Sent: Friday, July 16, 2004 8:34 AM
To: Juergen Stoetzer
Cc: megaco@ietf.org; megaco-bounces@ietf.org
Subject: Re: [Megaco] Sequential Signal List Interrupted by an Event





Hi
      An Event recognition without KeepActive flag  causes the currently
active signal descriptor to be disabled irrespective of the status of the
individual signals in the signal descriptor as if an embedded empty signal
descriptor got invoked.


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





             Juergen Stoetzer
             <J.Stoetzer@alcat
             el.de>                                                     To
             Sent by:                  megaco@ietf.org
             megaco-bounces@ie                                          cc
             tf.org
                                                                   Subject
                                       [Megaco] Sequential Signal List
             07/16/2004 05:39          Interrupted by an Event
             PM









Hello,

According to Section 7.1.9 of H.248.1 recognition of an event causes any
active signal to stop unless the KeepActive flag is set for that event.
More
specifically, it is said that "... event recognition may cause currently
active signals to stop, ..." and "Normally, recognition of an event shall
cause any active signals to stop."

In both places "active signals" are mentioned.
My question is how this should be applied to sequential signal lists.

Let's assume the corresponding termination has an active Signals descriptor
containing a sequential signal list of two timeout signals S1 and S2.
Let's further assume an event (without set KeepActive flag) occurs while the
first timeout signal S1 is still playing.
It seems to be clear that that currently playing first signal S1 has to be
stopped.

But what about the not yet started second signal S2?
Should this be started at that point anyhow?
Or should it rather be omitted?

More generally, should recognition of an event only cause currently, at that
very point in time active signals to stop without influencing possibly
present not yet started signals in sequential signal lists?
Or should recognition of an event not only cause "currently active"
signals to stop but should rather cause the whole signals descriptor to
become "inactive" (as if replaced with an empty signals descriptor)?

Thanks a lot in advance for comments and ideas on this!

Best Regards,
Juergen Stoetzer



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


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

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


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


From megaco-bounces@ietf.org  Tue Jul 20 05:58:26 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04592
	for <megaco-archive@lists.ietf.org>; Tue, 20 Jul 2004 05:58:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BmrMt-0006CZ-NN; Tue, 20 Jul 2004 05:57:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BmrHc-0004aN-Qi
	for megaco@megatron.ietf.org; Tue, 20 Jul 2004 05:51:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04300
	for <megaco@ietf.org>; Tue, 20 Jul 2004 05:51:34 -0400 (EDT)
Received: from mail.utstar.com ([216.37.114.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmrHj-0005I4-1E
	for megaco@ietf.org; Tue, 20 Jul 2004 05:51:44 -0400
Received: from balanew (balanew [172.16.40.58])
	by mail.utstar.com (8.12.10/8.12.10) with ESMTP id i6K9pRWM021418;
	Tue, 20 Jul 2004 05:51:27 -0400 (EDT)
From: "Balasubramanian Pitchandi" <bs@utstar.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>, <megaco@ietf.org>
Subject: =?utf-8?Q?RE:_=C2=B4=C3=B0=C2=B8=C2=B4:_=5BMegaco=5D_ABNF_encoding_of_?=
	=?utf-8?Q?Boolean_Values?=
Date: Tue, 20 Jul 2004 05:49:25 -0400
Organization: UTStarcom Inc
Message-ID: <002301c46e3e$dac7ee60$3a2810ac@balanew>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <CDEHKEMIAMIJHBPOGCFFCEANCCAA.atto.mu@utstar.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Content-Transfer-Encoding: quoted-printable
Cc: "'atto'" <atto.mu@utstar.com>
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bs@utstar.com
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
Content-Transfer-Encoding: quoted-printable

Kevin/List,

Would you please clarify this confusion regarding the encoding of =
Boolean values?
=20
Thanks,
Bala
=20

-----Original Message-----
From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf =
Of atto
Sent: Tuesday, July 13, 2004 1:26 AM
To: Kevin Boyle
Cc: bala; megaco@ietf.org
Subject: =E7=AD=94=E5=A4=8D: [Megaco] ABNF encoding of Boolean Values

hi, kevin,

I am confused by some conflict in rfc3525.

by B.2 comment, the text encoding boolean should be "on"/"off",=20

but by definition of  cd/on{init}, the value of boolean is  =
"true"/"false".

	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.

and some examples of cd/on{init} also show  that "true"/"false" should =
be used. (in rfc3525 page 186/191/193)

MEGACO/1 [125.125.125.111]:55555 Transaction =3D 50008 {
      Context =3D 5000 {
          Notify =3D A5555 {ObservedEvents =3D1235 {
             19990729T24020002:al/on(init=3Dfalse)}
          }
      } }

is it a mistake of rfc3525?=20
or the boolean can be either on/off or true/false, just according by the =
definition?

thanks
atto

-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: megaco-bounces@ietf.org =
[mailto:megaco-bounces@ietf.org]=E4=BB=A3=E8=A1=A8
Kevin Boyle
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2004=E5=B9=B47=E6=9C=8811=E6=97=A5 =
0:06
=E6=94=B6=E4=BB=B6=E4=BA=BA: bs@utstar.com; megaco@ietf.org
=E6=8A=84=E9=80=81: wei.zhao@utstar.com; tiger.pi@utstar.com
=E4=B8=BB=E9=A2=98: RE: [Megaco] ABNF encoding of Boolean Values


Appendix A is binary encoding, not text encoding.  Appendix B is text
encoding.  The sections are not contradictory.

Kevin=20

-----Original Message-----
From: Balasubramanian Pitchandi [mailto:bs@utstar.com]=20
Sent: Saturday, July 10, 2004 8:39 AM
To: megaco@ietf.org
Cc: wei.zhao@utstar.com; tiger.pi@utstar.com
Subject: [Megaco] ABNF encoding of Boolean Values

Hello,

RFC3525 has two contradicting sections (A.1.2 & B.2) with respect to the
encoding of boolean values.

A.1.2 states that ObservedEvents parameter should be encoded as

init =3D false

whereas the section B.2 clearly states that all boolean values should be
encoded as either "on" or "off", which would mean that the same would be
encoded as

init =3D off

Which one of this is correct?

Thanks
Bala


_______________________________________________
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 Jul 20 07:14:01 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09324
	for <megaco-archive@lists.ietf.org>; Tue, 20 Jul 2004 07:14:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BmsVK-0006vL-KW; Tue, 20 Jul 2004 07:09:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BmsSS-00067g-P0
	for megaco@megatron.ietf.org; Tue, 20 Jul 2004 07:06: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 HAA08954
	for <megaco@ietf.org>; Tue, 20 Jul 2004 07:06:49 -0400 (EDT)
Received: from albatross.ericsson.se ([193.180.251.49])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmsSM-0006EH-5a
	for megaco@ietf.org; Tue, 20 Jul 2004 07:07:00 -0400
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121])
	by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id
	i6KB6aWR017580
	for <megaco@ietf.org>; Tue, 20 Jul 2004 13:06:36 +0200 (MEST)
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by
	esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	Tue, 20 Jul 2004 13:06:36 +0200
Received: from ESEALNT744.al.sw.ericsson.se ([153.88.251.4]) by
	esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange
	Internet Mail Service Version 5.5.2657.72)
	id 32RBFS11; Tue, 20 Jul 2004 13:06:35 +0200
Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service
	(5.5.2653.19) id <J4K84JLZ>; Tue, 20 Jul 2004 13:06:35 +0200
Message-ID: <FBB5E93ACF0CD51188D20002A55CBC980A36C4FD@edeacnt101.eed.ericsson.se>
X-Sybari-Trust: c9f1f52f 100f6658 82cab426 00000138
From: "Michael Weilandt (AC/EDD)" <michael.weilandt@ericsson.com>
To: megaco@ietf.org
Date: Tue, 20 Jul 2004 13:06:35 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="utf-8"
X-OriginalArrivalTime: 20 Jul 2004 11:06:36.0012 (UTC)
	FILETIME=[9F74DAC0:01C46E49]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Subject: [Megaco] GCP Message Priority handling
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,

to my knowledge there is no mention in H.248.5 of a dedicated
setting of the MTP message priority when sending a GCP message over
MTP3b.
For ANSI ISUP such concept is used to give messages associated with
an ongoing or already establish call higher priority. In other words
IAM message may be dropped or treated with lower priority.

Has there ever been considerations to give a lower priority to
an ADD than to a MOD or SUB command; or in general to make some
distinction between "new" requests towards the MG as opposed to
"modfications" of existing contexts?

Best regards,
/Michael

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


From megaco-bounces@ietf.org  Tue Jul 20 11:49:29 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29445
	for <megaco-archive@lists.ietf.org>; Tue, 20 Jul 2004 11:49:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Bmwjf-0006Sv-W6; Tue, 20 Jul 2004 11:40:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BmwVT-0002TO-Ns
	for megaco@megatron.ietf.org; Tue, 20 Jul 2004 11:26: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 LAA27939
	for <megaco@ietf.org>; Tue, 20 Jul 2004 11:26:13 -0400 (EDT)
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmwVc-0001mm-Nv
	for megaco@ietf.org; Tue, 20 Jul 2004 11:26:26 -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 i6KFPfs23684
	for <megaco@ietf.org>; Tue, 20 Jul 2004 11:25:41 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MXHS70DM>; Tue, 20 Jul 2004 11:25:41 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C12A9E57E@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Michael Weilandt (AC/EDD)" <michael.weilandt@ericsson.com>,
        megaco@ietf.org
Subject: RE: [Megaco] GCP Message Priority handling
Date: Tue, 20 Jul 2004 11:25:40 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
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

Messages do not have a priority that is transmitted via protocol.  The
priority of a context can be set freely.

The determination to shed particular messages would be an implementation
detail of the overload protection function of the entity in question.

Kevin 

-----Original Message-----
From: Michael Weilandt (AC/EDD) [mailto:michael.weilandt@ericsson.com] 
Sent: Tuesday, July 20, 2004 7:07 AM
To: megaco@ietf.org
Subject: [Megaco] GCP Message Priority handling

Hello,

to my knowledge there is no mention in H.248.5 of a dedicated setting of the
MTP message priority when sending a GCP message over MTP3b.
For ANSI ISUP such concept is used to give messages associated with an
ongoing or already establish call higher priority. In other words IAM
message may be dropped or treated with lower priority.

Has there ever been considerations to give a lower priority to an ADD than
to a MOD or SUB command; or in general to make some distinction between
"new" requests towards the MG as opposed to "modfications" of existing
contexts?

Best regards,
/Michael

_______________________________________________
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 Jul 21 20:38:02 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11952
	for <megaco-archive@lists.ietf.org>; Wed, 21 Jul 2004 20:38:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BnR7r-0002PF-St; Wed, 21 Jul 2004 20:07:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BnPJn-0007tY-S1
	for megaco@megatron.ietf.org; Wed, 21 Jul 2004 18:12:07 -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 SAA11528
	for <megaco@ietf.org>; Wed, 21 Jul 2004 18:12:02 -0400 (EDT)
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnPKB-0006Eq-Mb
	for megaco@ietf.org; Wed, 21 Jul 2004 18:12:32 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <NKV4S71L>; Wed, 21 Jul 2004 18:11:20 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA0535E5D8@wench.telica.com>
From: Brad Steinka <bsteinka@telica.com>
To: megaco@ietf.org
Date: Wed, 21 Jul 2004 18:11:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Subject: [Megaco] ToS byte marking
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="===============0177535718=="
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.

--===============0177535718==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C46F6F.A4635DC8"

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_01C46F6F.A4635DC8
Content-Type: text/plain

Hi,

 

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

 

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

 

Thanks

brad


------_=_NextPart_001_01C46F6F.A4635DC8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Is there a mechanism in place either in a MEGACO =
package or
through SDP to specify what the TOS byte should be set too on packets
transmitted by an MG&nbsp; to facilitate DIFFServ/Qos behavior in the =
core network? &nbsp;&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I looked that the SDP attributes at IANA and =
didn&#8217;t
see anything that fit the bill.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>brad<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C46F6F.A4635DC8--


--===============0177535718==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============0177535718==--



From megaco-bounces@ietf.org  Wed Jul 21 21:28:08 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20532
	for <megaco-archive@lists.ietf.org>; Wed, 21 Jul 2004 21:28:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BnSE1-0008IZ-V7; Wed, 21 Jul 2004 21:18:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BnRsa-0001tH-7w
	for megaco@megatron.ietf.org; Wed, 21 Jul 2004 20:56:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15260
	for <megaco@ietf.org>; Wed, 21 Jul 2004 20:56:10 -0400 (EDT)
Received: from eagle.ericsson.se ([193.180.251.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnRsr-0006zv-65
	for megaco@ietf.org; Wed, 21 Jul 2004 20:56:40 -0400
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id
	i6M0tvAh022698 for <megaco@ietf.org>; Thu, 22 Jul 2004 02:55:57 +0200
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by
	esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	Thu, 22 Jul 2004 02:55:57 +0200
Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by
	esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange
	Internet Mail Service Version 5.5.2657.72)
	id 32393MD1; Thu, 22 Jul 2004 02:55:47 +0200
Received: from ericsson.com (ewgp.epa.ericsson.se [146.11.22.18]) by
	eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange
	Internet Mail Service Version 5.5.2657.72)
	id PGMB7H4T; Thu, 22 Jul 2004 10:55:44 +1000
Message-ID: <40FF1091.3000509@ericsson.com>
Date: Thu, 22 Jul 2004 10:55:45 +1000
X-Sybari-Trust: 2cc42246 c1e9ff4f e3907297 00000139
From: Christian Groves <christian.groves@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brad Steinka <bsteinka@telica.com>
Subject: Re: [Megaco] ToS byte marking
References: <C9AFC8E904D49C4593EB077A2E8402BA0535E5D8@wench.telica.com>
In-Reply-To: <C9AFC8E904D49C4593EB077A2E8402BA0535E5D8@wench.telica.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
X-OriginalArrivalTime: 22 Jul 2004 00:55:57.0182 (UTC)
	FILETIME=[A5D691E0:01C46F86]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id
	i6M0tvAh022698
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
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 <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
Content-Transfer-Encoding: quoted-printable

Hello Brad,

I believe the ETSI Gate Control package contains a package that allows th=
e=20
setting of Diffserv codepoints. The reference to this package should be o=
n the=20
IANA package for H.248 package registrations.

Regards, Christian

Brad Steinka wrote:
> Hi,
>=20
> =20
>=20
> Is there a mechanism in place either in a MEGACO package or through SDP=
=20
> to specify what the TOS byte should be set too on packets transmitted b=
y=20
> an MG  to facilitate DIFFServ/Qos behavior in the core network?  =20
>=20
> =20
>=20
> I looked that the SDP attributes at IANA and didn=92t see anything that=
=20
> fit the bill.
>=20
> =20
>=20
> Thanks
>=20
> brad
>=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 Jul 22 04:57:58 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01431
	for <megaco-archive@lists.ietf.org>; Thu, 22 Jul 2004 04:57:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BnZKO-0005oN-LC; Thu, 22 Jul 2004 04:53:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BnZJK-0005Oi-PU
	for megaco@megatron.ietf.org; Thu, 22 Jul 2004 04:52: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 EAA01118
	for <megaco@ietf.org>; Thu, 22 Jul 2004 04:52:16 -0400 (EDT)
Received: from eagle.ericsson.se ([193.180.251.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnZJp-0005oM-CN
	for megaco@ietf.org; Thu, 22 Jul 2004 04:52:51 -0400
Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id
	i6M8qEAh019562 for <megaco@ietf.org>; Thu, 22 Jul 2004 10:52:14 +0200
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by
	esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0);
	Thu, 22 Jul 2004 10:52:14 +0200
Received: from ESEALNT744.al.sw.ericsson.se ([153.88.251.4]) by
	esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange
	Internet Mail Service Version 5.5.2657.72)
	id 3239SAFR; Thu, 22 Jul 2004 10:52:13 +0200
Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service
	(5.5.2653.19) id <J4K84XZ3>; Thu, 22 Jul 2004 10:52:13 +0200
Message-ID: <FBB5E93ACF0CD51188D20002A55CBC980A36C50A@edeacnt101.eed.ericsson.se>
X-Sybari-Trust: 14b0f4e5 c1e9ff4f 2f3a7209 00000139
From: "Michael Weilandt (AC/EDD)" <michael.weilandt@ericsson.com>
To: megaco@ietf.org
Subject: RE: [Megaco] GCP Message Priority handling
Date: Thu, 22 Jul 2004 10:52:13 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-OriginalArrivalTime: 22 Jul 2004 08:52:14.0217 (UTC)
	FILETIME=[2F140F90:01C46FC9]
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
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="===============0801756958=="
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.

--===============0801756958==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C46FC9.2E7D1814"

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_01C46FC9.2E7D1814
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi Kevin,
 
what I meant here was not the context-related priority >inside< the GCP transaction
but the priority scheme offered by MTP, i.e. the signalling transport for GCP. Please
read for example ITU-T Q.704 (chapter 2.3.5) or Q.2150.1.
 
In high-load situation in the signalling network, when (e.g.) an STP may decide to discard
messages, it could indead be better to through away GCP transactions requesting a new
context rather than transactions that modifiy or subtract an existing context. The MTP priority
setting would be up to the MGC which should have an idea on what requests belong to
an "ongoing call" an which belong to a new one "to be established".
 
BR,
/Michael

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Tuesday, July 20, 2004 5:26 PM
To: Michael Weilandt (AC/EDD); megaco@ietf.org
Subject: RE: [Megaco] GCP Message Priority handling



Messages do not have a priority that is transmitted via protocol.  The priority of a context can be set freely. 

The determination to shed particular messages would be an implementation detail of the overload protection function of the entity in question.

Kevin 

-----Original Message----- 
From: Michael Weilandt (AC/EDD) [ mailto:michael.weilandt@ericsson.com <mailto:michael.weilandt@ericsson.com> ] 
Sent: Tuesday, July 20, 2004 7:07 AM 
To: megaco@ietf.org 
Subject: [Megaco] GCP Message Priority handling 

Hello, 

to my knowledge there is no mention in H.248.5 of a dedicated setting of the MTP message priority when sending a GCP message over MTP3b.

For ANSI ISUP such concept is used to give messages associated with an ongoing or already establish call higher priority. In other words IAM message may be dropped or treated with lower priority.

Has there ever been considerations to give a lower priority to an ADD than to a MOD or SUB command; or in general to make some distinction between "new" requests towards the MG as opposed to "modfications" of existing contexts?

Best regards, 
/Michael 

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


------_=_NextPart_001_01C46FC9.2E7D1814
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<TITLE>RE: [Megaco] GCP Message Priority handling</TITLE>

<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=199092408-22072004>Hi 
Kevin,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=199092408-22072004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=199092408-22072004>what&nbsp;I meant here was not the context-related 
priority &gt;inside&lt; the GCP transaction</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=199092408-22072004>but 
the priority scheme offered by MTP, i.e. the signalling transport for GCP. 
Please</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=199092408-22072004>read 
f</SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN 
class=199092408-22072004>or example ITU-T Q.704 (chapter 2.3.5) or 
Q.2150.1.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=199092408-22072004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=199092408-22072004>In 
high-load situation in the signalling network, when (e.g.) an STP may decide to 
discard</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=199092408-22072004>messages, it could indead be better to through away GCP 
transactions requesting a new</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=199092408-22072004>context rather than transactions that modifiy or 
subtract an existing context. The MTP priority</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=199092408-22072004>setting would be up to the MGC which should have an 
idea on what requests belong to</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=199092408-22072004>an 
"ongoing call" an which belong to a new one "to 
be&nbsp;established".</SPAN></FONT></DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=2><SPAN 
class=199092408-22072004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=199092408-22072004>BR,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=199092408-22072004>/Michael</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Kevin Boyle 
  [mailto:kboyle@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, July 20, 2004 5:26 
  PM<BR><B>To:</B> Michael Weilandt (AC/EDD); megaco@ietf.org<BR><B>Subject:</B> 
  RE: [Megaco] GCP Message Priority handling<BR><BR></FONT></DIV>
  <P><FONT size=2>Messages do not have a priority that is transmitted via 
  protocol.&nbsp; The priority of a context can be set freely.</FONT> </P>
  <P><FONT size=2>The determination to shed particular messages would be an 
  implementation detail of the overload protection function of the entity in 
  question.</FONT></P>
  <P><FONT size=2>Kevin </FONT></P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
  Michael Weilandt (AC/EDD) [<A 
  href="mailto:michael.weilandt@ericsson.com">mailto:michael.weilandt@ericsson.com</A>] 
  </FONT><BR><FONT size=2>Sent: Tuesday, July 20, 2004 7:07 AM</FONT> <BR><FONT 
  size=2>To: megaco@ietf.org</FONT> <BR><FONT size=2>Subject: [Megaco] GCP 
  Message Priority handling</FONT> </P>
  <P><FONT size=2>Hello,</FONT> </P>
  <P><FONT size=2>to my knowledge there is no mention in H.248.5 of a dedicated 
  setting of the MTP message priority when sending a GCP message over 
  MTP3b.</FONT></P>
  <P><FONT size=2>For ANSI ISUP such concept is used to give messages associated 
  with an ongoing or already establish call higher priority. In other words IAM 
  message may be dropped or treated with lower priority.</FONT></P>
  <P><FONT size=2>Has there ever been considerations to give a lower priority to 
  an ADD than to a MOD or SUB command; or in general to make some distinction 
  between "new" requests towards the MG as opposed to "modfications" of existing 
  contexts?</FONT></P>
  <P><FONT size=2>Best regards,</FONT> <BR><FONT size=2>/Michael</FONT> </P>
  <P><FONT size=2>_______________________________________________</FONT> 
  <BR><FONT size=2>Megaco mailing list</FONT> <BR><FONT 
  size=2>Megaco@ietf.org</FONT> <BR><FONT size=2><A 
  href="https://www1.ietf.org/mailman/listinfo/megaco" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C46FC9.2E7D1814--


--===============0801756958==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============0801756958==--



From megaco-bounces@ietf.org  Thu Jul 22 10:00:25 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21374
	for <megaco-archive@lists.ietf.org>; Thu, 22 Jul 2004 10:00:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Bne0f-0006PI-HS; Thu, 22 Jul 2004 09:53:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BndmI-0000qG-AS
	for megaco@megatron.ietf.org; Thu, 22 Jul 2004 09:38:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19665
	for <megaco@ietf.org>; Thu, 22 Jul 2004 09:38:28 -0400 (EDT)
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bndmo-0001VH-I7
	for megaco@ietf.org; Thu, 22 Jul 2004 09:39:05 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id i6MDbsx16367
	for <megaco@ietf.org>; Thu, 22 Jul 2004 09:37:54 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MXHS0YJZ>; Thu, 22 Jul 2004 09:37:55 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C12B9C3CD@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Michael Weilandt (AC/EDD)" <michael.weilandt@ericsson.com>,
        megaco@ietf.org
Subject: RE: [Megaco] GCP Message Priority handling
Date: Thu, 22 Jul 2004 09:37:51 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
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

MTP priority handling is outside the scope of H.248.  If your implementation
wishes to distinguish between Adds and other kinds of H.248 commands to
determine how to set the priority indicator in MTP, then great.
 
I don't see where it is our place to specify overload control behavior with
regard to which commands are more acceptable to throw away (if any).  That
would depend heavily upon the details of a particular implementation.
 
Kevin


  _____  

From: Michael Weilandt (AC/EDD) [mailto:michael.weilandt@ericsson.com] 
Sent: Thursday, July 22, 2004 4:52 AM
To: megaco@ietf.org
Subject: RE: [Megaco] GCP Message Priority handling


Hi Kevin,
 
what I meant here was not the context-related priority >inside< the GCP
transaction
but the priority scheme offered by MTP, i.e. the signalling transport for
GCP. Please
read for example ITU-T Q.704 (chapter 2.3.5) or Q.2150.1.
 
In high-load situation in the signalling network, when (e.g.) an STP may
decide to discard
messages, it could indead be better to through away GCP transactions
requesting a new
context rather than transactions that modifiy or subtract an existing
context. The MTP priority
setting would be up to the MGC which should have an idea on what requests
belong to
an "ongoing call" an which belong to a new one "to be established".
 
BR,
/Michael

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Tuesday, July 20, 2004 5:26 PM
To: Michael Weilandt (AC/EDD); megaco@ietf.org
Subject: RE: [Megaco] GCP Message Priority handling



Messages do not have a priority that is transmitted via protocol.  The
priority of a context can be set freely. 

The determination to shed particular messages would be an implementation
detail of the overload protection function of the entity in question.

Kevin 

-----Original Message----- 
From: Michael Weilandt (AC/EDD) [mailto:michael.weilandt@ericsson.com
<mailto:michael.weilandt@ericsson.com> ] 
Sent: Tuesday, July 20, 2004 7:07 AM 
To: megaco@ietf.org 
Subject: [Megaco] GCP Message Priority handling 

Hello, 

to my knowledge there is no mention in H.248.5 of a dedicated setting of the
MTP message priority when sending a GCP message over MTP3b.

For ANSI ISUP such concept is used to give messages associated with an
ongoing or already establish call higher priority. In other words IAM
message may be dropped or treated with lower priority.

Has there ever been considerations to give a lower priority to an ADD than
to a MOD or SUB command; or in general to make some distinction between
"new" requests towards the MG as opposed to "modfications" of existing
contexts?

Best regards, 
/Michael 

_______________________________________________ 
Megaco mailing list 
Megaco@ietf.org 
https://www1.ietf.org/mailman/listinfo/megaco
<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 Jul 25 09:59:28 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09685
	for <megaco-archive@lists.ietf.org>; Sun, 25 Jul 2004 09:59:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BojVb-0004s6-Ow; Sun, 25 Jul 2004 09:57:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BojUn-0004jW-Aw
	for megaco@megatron.ietf.org; Sun, 25 Jul 2004 09:56: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 JAA09615
	for <megaco@ietf.org>; Sun, 25 Jul 2004 09:56:51 -0400 (EDT)
Received: from astra.telenet-ops.be ([195.130.132.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BojVs-0006is-6A
	for megaco@ietf.org; Sun, 25 Jul 2004 09:58:07 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by astra.telenet-ops.be (Postfix) with SMTP id B4270328122
	for <megaco@ietf.org>; Sun, 25 Jul 2004 15:56:47 +0200 (MEST)
Received: from pas (D577883B.kabel.telenet.be [213.119.136.59])
	by astra.telenet-ops.be (Postfix) with SMTP id 97A933280FD
	for <megaco@ietf.org>; Sun, 25 Jul 2004 15:56:47 +0200 (MEST)
Message-ID: <005601c4724f$8ad1bac0$c400a8c0@pandora.be>
From: "Pascal Lambers" <pascal.lambers@pandora.be>
To: <megaco@ietf.org>
Date: Sun, 25 Jul 2004 15:59:02 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Subject: [Megaco] AuditValue of termination hook status
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Pascal Lambers <pascal.lambers@pandora.be>
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="===============0717679562=="
Sender: megaco-bounces@ietf.org
Errors-To: megaco-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0717679562==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0053_01C47260.4E38F900"

This is a multi-part message in MIME format.

------=_NextPart_000_0053_01C47260.4E38F900
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

Megaco's AuditValue message does not provide a direct waf of Auditing =
the Hook Status of a termination. Correct?


Pascal


------=_NextPart_000_0053_01C47260.4E38F900
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Megaco's AuditValue message does not =
provide a=20
direct waf of Auditing the Hook Status of&nbsp;a termination.=20
Correct?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Pascal</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0053_01C47260.4E38F900--



--===============0717679562==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============0717679562==--




From megaco-bounces@ietf.org  Mon Jul 26 09:28:23 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25107
	for <megaco-archive@lists.ietf.org>; Mon, 26 Jul 2004 09:28:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Bp5Ms-0006uM-KC; Mon, 26 Jul 2004 09:18:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp5Gy-0005Zf-Al
	for megaco@megatron.ietf.org; Mon, 26 Jul 2004 09:12: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 JAA23561
	for <megaco@ietf.org>; Mon, 26 Jul 2004 09:12:06 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp5IM-0006L6-5h
	for megaco@ietf.org; Mon, 26 Jul 2004 09:13:35 -0400
Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59])
	by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id i6QDBYl07825
	for <megaco@ietf.org>; Mon, 26 Jul 2004 09:11:34 -0400 (EDT)
Received: from [47.130.16.253] (acart07y.ca.nortel.com [47.130.16.253]) by
	zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2653.13)
	id NALTC7DL; Mon, 26 Jul 2004 09:11:34 -0400
Message-ID: <41050305.1050300@nortelnetworks.com>
Date: Mon, 26 Jul 2004 09:11:33 -0400
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Naming Pattern Package
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
Content-Transfer-Encoding: 7bit

The Megaco WG has had the naming pattern package as a milestone for years.  Anyone 
object if we drop it?

I'm proposing to finish the MIB and call flows work by the end of September, and 
update the Megaco v2 draft by substituting the new version including corrections 
agreed by SG 16 this year.  We would therefore wind up the Megaco WG (but keep the 
list active) some time this fall.

Tom Taylor

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


From megaco-bounces@ietf.org  Mon Jul 26 09:34:48 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25580
	for <megaco-archive@lists.ietf.org>; Mon, 26 Jul 2004 09:34:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Bp5YC-0000lX-Mz; Mon, 26 Jul 2004 09:29:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp5SS-0007yZ-1W
	for megaco@megatron.ietf.org; Mon, 26 Jul 2004 09:24:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24715
	for <megaco@ietf.org>; Mon, 26 Jul 2004 09:23:58 -0400 (EDT)
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp5To-0006f8-V7
	for megaco@ietf.org; Mon, 26 Jul 2004 09:25:27 -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 i6QDNPf26240
	for <megaco@ietf.org>; Mon, 26 Jul 2004 09:23:25 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MXHTCYHN>; Mon, 26 Jul 2004 09:23:26 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C12CAABC3@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Pascal Lambers <pascal.lambers@pandora.be>, megaco@ietf.org
Subject: RE: [Megaco] AuditValue of termination hook status
Date: Mon, 26 Jul 2004 09:23:24 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
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

The hook status of an analog line termination (Note that not all
terminations have a hook status), can be determined by just applying the
event you are looking for and setting the strict parm appropriately.
Because hook status is a binary function, and the event allows reporting of
a termination that had previously transitioned to a state, there is no need
for a property that can be audited.
 
Kevin


  _____  

From: Pascal Lambers [mailto:pascal.lambers@pandora.be] 
Sent: Sunday, July 25, 2004 9:59 AM
To: megaco@ietf.org
Subject: [Megaco] AuditValue of termination hook status


Hello,
 
Megaco's AuditValue message does not provide a direct waf of Auditing the
Hook Status of a termination. Correct?
 
 
Pascal
 
 


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


From megaco-bounces@ietf.org  Mon Jul 26 11:32:32 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15254
	for <megaco-archive@lists.ietf.org>; Mon, 26 Jul 2004 11:32:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Bp7Js-0006Zs-7J; Mon, 26 Jul 2004 11:23:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp79q-000407-2z
	for megaco@megatron.ietf.org; Mon, 26 Jul 2004 11:12: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 LAA11582
	for <megaco@ietf.org>; Mon, 26 Jul 2004 11:12:51 -0400 (EDT)
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp7BF-0005ML-3S
	for megaco@ietf.org; Mon, 26 Jul 2004 11:14:22 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id i6QFCKv17703
	for <megaco@ietf.org>; Mon, 26 Jul 2004 11:12:20 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MXHTDCFH>; Mon, 26 Jul 2004 11:12:21 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C12CAB111@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: bs@utstar.com, megaco@ietf.org
Subject: RE: ´ð¸´: [Megaco] ABNF encoding of Boolean Values
Date: Mon, 26 Jul 2004 11:08:45 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 2.7 (++)
X-NONENGLISH: Subject contains non-English characters
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: "'atto'" <atto.mu@utstar.com>
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

The encoding should be as stated in Annex B.  Bring any discrepancies to my
attention and I will add them to the Implementors' Guide.

Kevin 

-----Original Message-----
From: Balasubramanian Pitchandi [mailto:bs@utstar.com] 
Sent: Tuesday, July 20, 2004 5:49 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Cc: 'atto'
Subject: RE: ´ð¸´: [Megaco] ABNF encoding of Boolean Values

Kevin/List,

Would you please clarify this confusion regarding the encoding of Boolean
values?
 
Thanks,
Bala
 

-----Original Message-----
From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of
atto
Sent: Tuesday, July 13, 2004 1:26 AM
To: Kevin Boyle
Cc: bala; megaco@ietf.org
Subject: 答复: [Megaco] ABNF encoding of Boolean Values

hi, kevin,

I am confused by some conflict in rfc3525.

by B.2 comment, the text encoding boolean should be "on"/"off", 

but by definition of  cd/on{init}, the value of boolean is  "true"/"false".

	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.

and some examples of cd/on{init} also show  that "true"/"false" should be
used. (in rfc3525 page 186/191/193)

MEGACO/1 [125.125.125.111]:55555 Transaction = 50008 {
      Context = 5000 {
          Notify = A5555 {ObservedEvents =1235 {
             19990729T24020002:al/on(init=false)}
          }
      } }

is it a mistake of rfc3525? 
or the boolean can be either on/off or true/false, just according by the
definition?

thanks
atto

-----原始邮件-----
发件人: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]代表
Kevin Boyle
发送时间: 2004年7月11日 0:06
收件人: bs@utstar.com; megaco@ietf.org
抄送: wei.zhao@utstar.com; tiger.pi@utstar.com
主题: RE: [Megaco] ABNF encoding of Boolean Values


Appendix A is binary encoding, not text encoding.  Appendix B is text
encoding.  The sections are not contradictory.

Kevin 

-----Original Message-----
From: Balasubramanian Pitchandi [mailto:bs@utstar.com]
Sent: Saturday, July 10, 2004 8:39 AM
To: megaco@ietf.org
Cc: wei.zhao@utstar.com; tiger.pi@utstar.com
Subject: [Megaco] ABNF encoding of Boolean Values

Hello,

RFC3525 has two contradicting sections (A.1.2 & B.2) with respect to the
encoding of boolean values.

A.1.2 states that ObservedEvents parameter should be encoded as

init = false

whereas the section B.2 clearly states that all boolean values should be
encoded as either "on" or "off", which would mean that the same would be
encoded as

init = off

Which one of this is correct?

Thanks
Bala


_______________________________________________
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 Jul 27 23:59:58 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02810
	for <megaco-archive@lists.ietf.org>; Tue, 27 Jul 2004 23:59:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BpfaF-0001aO-LJ; Tue, 27 Jul 2004 23:58:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BpfRZ-0000iZ-10
	for megaco@megatron.ietf.org; Tue, 27 Jul 2004 23:49: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 XAA02430
	for <megaco@ietf.org>; Tue, 27 Jul 2004 23:49:26 -0400 (EDT)
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpfTH-0005kV-TO
	for megaco@ietf.org; Tue, 27 Jul 2004 23:51:17 -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 i6S3mod11472
	for <megaco@ietf.org>; Tue, 27 Jul 2004 23:48:50 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MXHTFXQQ>; Tue, 27 Jul 2004 23:48:51 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C12DB0992@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Nurit Shenhar <NuritS@audiocodes.com>, megaco@ietf.org
Date: Tue, 27 Jul 2004 23:48:50 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Subject: [Megaco] RE: MEGACO: Question about H.248.25 - bcasaddr package
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control <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

Signals and events are different namespaces.  The ordering in one is
completely independent of the other.  Given that this has been published and
there are implementations in existence, I think it would be detrimental to
alter the ordering, especially since they are not related to each other.

Kevin

-----Original Message-----
From: Nurit Shenhar [mailto:NuritS@audiocodes.com] 
Sent: Tuesday, July 27, 2004 9:58 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: MEGACO: Question about H.248.25 - bcasaddr package



Hi

While looking at H.248.25 and the correction to it from the ITU site
(published at 03/2004), I found out that the list of address coding in the
'addr' event parameter and the 'addr' signal parameter is not the same. In
the signal it is:
   DTMF 0x0001
   MF   0x0002
   DP   0x0003

While in the event:
   MF   0x0001
   DTMF 0x0002
   DP   0x0003

Is it intentional? If not, can it be corrected to be the same order?

Thanks,

Nurit

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

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


****************************************************************************
*******************************

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


From megaco-bounces@ietf.org  Thu Jul 29 10:59:18 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17034
	for <megaco-archive@lists.ietf.org>; Thu, 29 Jul 2004 10:59:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BqBfb-00020h-Eo; Thu, 29 Jul 2004 10:14:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BqB46-0008Cu-85
	for megaco@megatron.ietf.org; Thu, 29 Jul 2004 09:35: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 FAA28010
	for <megaco@ietf.org>; Thu, 29 Jul 2004 05:10:06 -0400 (EDT)
Received: from mailrelay1.alcatel.de ([194.113.59.55]
	helo=mailrelay2.alcatel.de)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bq6xP-0000nN-Rq
	for megaco@ietf.org; Thu, 29 Jul 2004 05:12:13 -0400
Received: from [149.204.189.77] (sls1cd.ad1.ad.alcatel.com [149.204.189.77])
	by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i6T8xpRE001557;
	Thu, 29 Jul 2004 08:59:51 GMT
Message-ID: <4108BC88.9020906@alcatel.de>
Date: Thu, 29 Jul 2004 10:59:52 +0200
From: Carsten Waitzmann <cwaitzmann@alcatel.de>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco@ietf.org
References: <ABA227A15B80D511BD1A00508BF93A1C12DB0992@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C12DB0992@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Alcanet-virus-scanned: i6T8xpRE001557 at mailrelay2.alcatel.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Question about network package, ServiceChange
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control <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
Content-Transfer-Encoding: 7bit

<<< No Message Collected >>>

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


From megaco-bounces@ietf.org  Thu Jul 29 11:11:47 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17535
	for <megaco-archive@lists.ietf.org>; Thu, 29 Jul 2004 11:11:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BqBfq-0002FF-Mr; Thu, 29 Jul 2004 10:14:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BqB4m-0000MU-C8
	for megaco@megatron.ietf.org; Thu, 29 Jul 2004 09:36:04 -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 FAA27588
	for <megaco@ietf.org>; Thu, 29 Jul 2004 05:00:27 -0400 (EDT)
Received: from mailrelay1.alcatel.de ([194.113.59.55]
	helo=mailrelay2.alcatel.de)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bq6o0-0000fS-RK
	for megaco@ietf.org; Thu, 29 Jul 2004 05:02:34 -0400
Received: from [149.204.189.77] (sls1cd.ad1.ad.alcatel.com [149.204.189.77])
	by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i6T8xpRE001557;
	Thu, 29 Jul 2004 08:59:51 GMT
Message-ID: <4108BC88.9020906@alcatel.de>
Date: Thu, 29 Jul 2004 10:59:52 +0200
From: Carsten Waitzmann <cwaitzmann@alcatel.de>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco@ietf.org
References: <ABA227A15B80D511BD1A00508BF93A1C12DB0992@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C12DB0992@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Alcanet-virus-scanned: i6T8xpRE001557 at mailrelay2.alcatel.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Question about network package, ServiceChange
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control <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
Content-Transfer-Encoding: 7bit

Hi,

A MGW with transmission ports houses mulitple "network terminations" 
(terminology according to E.11 network package).
The terminology of network termination is exclusivly used in the textual 
description of this package, thus one could conclude that this packet 
applies to:
- Packet (IP, ATM or possibly others) *network terminations* as well as
- Switched Circuit *network terminations*.
Looking to the package itself, it looks to me that the intention of the 
package is in fact more packet network termination related.
Is it allowed to apply the package for switched circuit network 
terminations as well?
If not, my suggestion is to add "packet" to the description: "This 
package defines properties of *packet* network terminations independent 
of network type".

The network package defines properties, events and statistics. The 
netfail event especially is used to notify per termination (if the MGC 
previously has subscribed for) the MGC "upon detection of a failure due 
to external or internal network reasons".
Assuming that a transmission port of the MGW fails the MG will send a 
bunch of netfail events related to all concerned network terminations. 
Additionally I assume that the MG will notify the MGC by means of 
ServiceChange (Method=Forced, Reason=transmission failure) for all 
concerned network terminations.
Is a netfail event subscription by the MGC making it obsolete for the MG 
to send ServiceChange?
If not, what is in general the added value of the netfail event compared 
to an anyhow sent ServiceChange notification?

thanks
Carsten



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


From megaco-bounces@ietf.org  Thu Jul 29 12:29:55 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22897
	for <megaco-archive@lists.ietf.org>; Thu, 29 Jul 2004 12:29:55 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BqCwS-0001Bp-Uv; Thu, 29 Jul 2004 11:35:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BqA1S-0000t6-GN
	for megaco@megatron.ietf.org; Thu, 29 Jul 2004 08:28: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 IAA06815
	for <megaco@ietf.org>; Thu, 29 Jul 2004 08:28:27 -0400 (EDT)
Received: from gate2.itcnetworks.ro ([80.96.82.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqA3N-0003Tq-O8
	for megaco@ietf.org; Thu, 29 Jul 2004 08:30:35 -0400
Message-ID: <007501c47567$88d49150$d105020a@neluc>
From: "Nelu Cirstea" <neluc@itcnetworks.ro>
To: <megaco@ietf.org>
Date: Thu, 29 Jul 2004 15:28:20 +0300
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.3 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
X-Mailman-Approved-At: Thu, 29 Jul 2004 11:35:35 -0400
Subject: [Megaco] H248 Audit *
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="===============1240949097=="
Sender: megaco-bounces@ietf.org
Errors-To: megaco-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1240949097==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0072_01C47580.AE1F7F60"

This is a multi-part message in MIME format.

------=_NextPart_000_0072_01C47580.AE1F7F60
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Hello,

I have 4 context's created context1 - first created, context2 - second =
created, context3 - third created and context4 - last created. I would =
like to Audit all of them. For this I do:

#send
MEGACO/1 {pop mgcMid}
Transaction =3D {var transId =3D newtransid} {
        Context =3D * {
            AuditValue =3D root {
                    Audit { }
            }
        }
}
#;

I would like to know the order of context's in the answer. Is this =
specified in standard?=20
Thank you,
Best Regards,
Nelu Cirstea
Software developer
ITC Networks Romania
Nortel Networks subsidiary
------=_NextPart_000_0072_01C47580.AE1F7F60
Content-Type: text/html;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-2">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have 4 context's created context1 - =
first=20
created, context2 -&nbsp;second created, context3 - third created and =
context4 -=20
last created. I would like to Audit all of them. For this I =
do:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#ff0000 size=3D2>#send</FONT></DIV>
<DIV><FONT color=3D#ff0000 size=3D2>MEGACO/1 {pop mgcMid}</FONT></DIV>
<DIV><FONT color=3D#ff0000 size=3D2>Transaction =3D {var transId =3D =
newtransid}=20
{</FONT></DIV>
<DIV><FONT color=3D#ff0000 size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; Context =3D=20
* {</FONT></DIV>
<DIV><FONT color=3D#ff0000 size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; AuditValue =3D root {</FONT></DIV>
<DIV><FONT color=3D#ff0000 size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Audit { =
}</FONT></DIV>
<DIV><FONT color=3D#ff0000 size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; }</FONT></DIV>
<DIV><FONT color=3D#ff0000 size=3D2>&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
}</FONT></DIV>
<DIV><FONT color=3D#ff0000 size=3D2>}</FONT></DIV>
<DIV><FONT color=3D#ff0000 size=3D2>#;</FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DArial></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DArial>I would like to know the order of =
context's=20
in the answer. Is this specified in standard? </FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DArial>Thank you,</FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DArial>Best Regards,</FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DArial>Nelu Cirstea</FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DArial>Software =
developer</FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DArial>ITC Networks =
Romania</FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DArial>Nortel Networks=20
subsidiary</FONT></DIV></FONT></BODY></HTML>

------=_NextPart_000_0072_01C47580.AE1F7F60--



--===============1240949097==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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

--===============1240949097==--




From megaco-bounces@ietf.org  Thu Jul 29 14:40:50 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00679
	for <megaco-archive@lists.ietf.org>; Thu, 29 Jul 2004 14:40:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1BqFSD-0004eH-2a; Thu, 29 Jul 2004 14:16:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1BqEzG-0000N7-J6
	for megaco@megatron.ietf.org; Thu, 29 Jul 2004 13:46:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27718
	for <megaco@ietf.org>; Thu, 29 Jul 2004 13:46:31 -0400 (EDT)
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqF1E-0000SZ-Ni
	for megaco@ietf.org; Thu, 29 Jul 2004 13:48:41 -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 i6THjxG10979
	for <megaco@ietf.org>; Thu, 29 Jul 2004 13:45:59 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MXHT2C34>; Thu, 29 Jul 2004 13:45:58 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C12E94C00@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: megaco@ietf.org
Subject: RE: [Megaco] H248 Audit *
Date: Thu, 29 Jul 2004 13:45:55 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
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

The order is unspecified in the spec and is at the discretion of the MG.
 
Kevin


  _____  

From: Cirstea, Nelu [Business:ITC:HF11] 
Sent: Thursday, July 29, 2004 8:28 AM
To: megaco@ietf.org
Subject: [Megaco] H248 Audit *


Hello,
 
I have 4 context's created context1 - first created, context2 - second
created, context3 - third created and context4 - last created. I would like
to Audit all of them. For this I do:
 
#send
MEGACO/1 {pop mgcMid}
Transaction = {var transId = newtransid} {
        Context = * {
            AuditValue = root {
                    Audit { }
            }
        }
}
#;
 
I would like to know the order of context's in the answer. Is this specified
in standard? 
Thank you,
Best Regards,
Nelu Cirstea
Software developer
ITC Networks Romania
Nortel Networks subsidiary


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