From megaco-admin@ietf.org  Mon Dec  1 09:04:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10661
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 09:04:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQoef-0000EL-PA; Mon, 01 Dec 2003 09:04:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQl4N-0000V3-O1
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 05:14:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04263
	for <megaco@ietf.org>; Mon, 1 Dec 2003 05:14:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQl4K-0006ns-00
	for megaco@ietf.org; Mon, 01 Dec 2003 05:14:16 -0500
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQl4J-0006no-00
	for megaco@ietf.org; Mon, 01 Dec 2003 05:14:15 -0500
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hB1AEGY03665
	for <megaco@ietf.org>; Mon, 1 Dec 2003 11:14:16 +0100 (MET)
Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206])
	by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id hB1AEBj02278
	for <megaco@ietf.org>; Mon, 1 Dec 2003 11:14:11 +0100 (MET)
Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84])
	by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA23109
	for <megaco@ietf.org>; Mon, 1 Dec 2003 11:14:06 +0100 (MET)
Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59)
	id <VKY8A4W5>; Mon, 1 Dec 2003 11:14:07 +0100
Message-ID: <2F0349FB836CD411AB1D00508B95270306DE74D6@mchh268e.mchh.siemens.de>
From: Tegeler Juergen <juergen.tegeler@siemens.com>
To: megaco@ietf.org
Date: Mon, 1 Dec 2003 11:14:07 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Megaco] Digit Map Completion Event
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Hi all,

the following question about Digit Map Completion Event came up 
while reading H.248.1 (05/2002):

Chapter 7.1.14.4:
..
Upon completion, a digit map completion event as defined in the package providing the events being mapped into the digit map shall be generated. At that point the digit map is deactivated. Subsequent events in the package are processed as follows:
*	If EventBufferControl is ON, subsequent digit events are processed in the same way as any other events;
..

Isn' t that a contradiction? What to do with digits received in the MGC after reception of Digit Map Completion event?


Best regards,

Juergen Tegeler  







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


From exim@www1.ietf.org  Mon Dec  1 09:04:28 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10679
	for <megaco-archive@odin.ietf.org>; Mon, 1 Dec 2003 09:04:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQoes-0000Fs-1q
	for megaco-archive@odin.ietf.org; Mon, 01 Dec 2003 09:04:14 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1E4ELW000966
	for megaco-archive@odin.ietf.org; Mon, 1 Dec 2003 09:04:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQoer-0000FV-To
	for megaco-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 09:04:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10652
	for <megaco-web-archive@ietf.org>; Mon, 1 Dec 2003 09:03:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQoeo-00021o-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 09:04:11 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQoeo-00021h-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 09:04:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQoef-0000EL-PA; Mon, 01 Dec 2003 09:04:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQl4N-0000V3-O1
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 05:14:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04263
	for <megaco@ietf.org>; Mon, 1 Dec 2003 05:14:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQl4K-0006ns-00
	for megaco@ietf.org; Mon, 01 Dec 2003 05:14:16 -0500
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQl4J-0006no-00
	for megaco@ietf.org; Mon, 01 Dec 2003 05:14:15 -0500
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hB1AEGY03665
	for <megaco@ietf.org>; Mon, 1 Dec 2003 11:14:16 +0100 (MET)
Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206])
	by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id hB1AEBj02278
	for <megaco@ietf.org>; Mon, 1 Dec 2003 11:14:11 +0100 (MET)
Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84])
	by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA23109
	for <megaco@ietf.org>; Mon, 1 Dec 2003 11:14:06 +0100 (MET)
Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59)
	id <VKY8A4W5>; Mon, 1 Dec 2003 11:14:07 +0100
Message-ID: <2F0349FB836CD411AB1D00508B95270306DE74D6@mchh268e.mchh.siemens.de>
From: Tegeler Juergen <juergen.tegeler@siemens.com>
To: megaco@ietf.org
Date: Mon, 1 Dec 2003 11:14:07 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Megaco] Digit Map Completion Event
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Hi all,

the following question about Digit Map Completion Event came up 
while reading H.248.1 (05/2002):

Chapter 7.1.14.4:
..
Upon completion, a digit map completion event as defined in the package providing the events being mapped into the digit map shall be generated. At that point the digit map is deactivated. Subsequent events in the package are processed as follows:
*	If EventBufferControl is ON, subsequent digit events are processed in the same way as any other events;
..

Isn' t that a contradiction? What to do with digits received in the MGC after reception of Digit Map Completion event?


Best regards,

Juergen Tegeler  







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



From megaco-admin@ietf.org  Mon Dec  1 09:18:17 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11214
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 09:18:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQosC-0001AH-QJ; Mon, 01 Dec 2003 09:18:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQorW-00015i-R3
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 09:17:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11155
	for <megaco@ietf.org>; Mon, 1 Dec 2003 09:17:04 -0500 (EST)
From: shashi.kumar@wipro.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQorV-0002FY-00
	for megaco@ietf.org; Mon, 01 Dec 2003 09:17:17 -0500
Received: from wiproecmx2.wipro.com ([164.164.31.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQorT-0002D7-00
	for megaco@ietf.org; Mon, 01 Dec 2003 09:17:16 -0500
Received: from ec-vwall-wd.wipro.com (ecvwall7.wipro.com [10.200.52.125])
	by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id hB1EGfAj021786
	for <megaco@ietf.org>; Mon, 1 Dec 2003 19:46:41 +0530 (IST)
Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Mon, 01 Dec 2003 19:50:47 +0530
Received: from blr-ec-msg02.wipro.com ([10.200.51.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 1 Dec 2003 19:44:45 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Megaco] Digit Map Completion Event
Date: Mon, 1 Dec 2003 19:44:45 +0530
Message-ID: <E26955DC2678894D9A5C3EB4C0892F2F9922CB@blr-ec-msg02.wipro.com>
Thread-Topic: [Megaco] Digit Map Completion Event
Thread-Index: AcO4E/q2VYeXnt+lTyy0RNtIbInRoQAAJadw
To: <juergen.tegeler@siemens.com>, <megaco@ietf.org>
X-OriginalArrivalTime: 01 Dec 2003 14:14:45.0577 (UTC) FILETIME=[78B9C390:01C3B815]
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: quoted-printable

Hi,

  The statement in the RFC is to address more than one digit event being =
active and processing subsequent digit map completion events.  I believe =
there was some discussion on the list in this regard (I do not remember =
the thread though)

  Hope this helps...
 =20
Thanks,
Shashi


-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Tegeler Juergen
Sent: Monday, December 01, 2003 3:44 PM
To: megaco@ietf.org
Subject: [Megaco] Digit Map Completion Event


Hi all,

the following question about Digit Map Completion Event came up=20
while reading H.248.1 (05/2002):

Chapter 7.1.14.4:
..
Upon completion, a digit map completion event as defined in the package =
providing the events being mapped into the digit map shall be generated. =
At that point the digit map is deactivated. Subsequent events in the =
package are processed as follows:
*	If EventBufferControl is ON, subsequent digit events are processed in =
the same way as any other events;
..

Isn' t that a contradiction? What to do with digits received in the MGC =
after reception of Digit Map Completion event?


Best regards,

Juergen Tegeler =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 exim@www1.ietf.org  Mon Dec  1 09:18:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11229
	for <megaco-archive@odin.ietf.org>; Mon, 1 Dec 2003 09:18:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQosF-0001Bl-21
	for megaco-archive@odin.ietf.org; Mon, 01 Dec 2003 09:18:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1EI3XS004565
	for megaco-archive@odin.ietf.org; Mon, 1 Dec 2003 09:18:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQosE-0001BY-Tn
	for megaco-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 09:18:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11190
	for <megaco-web-archive@ietf.org>; Mon, 1 Dec 2003 09:17:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQosD-0002G9-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 09:18:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQosC-0002G6-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 09:18:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQosC-0001AH-QJ; Mon, 01 Dec 2003 09:18:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQorW-00015i-R3
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 09:17:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11155
	for <megaco@ietf.org>; Mon, 1 Dec 2003 09:17:04 -0500 (EST)
From: shashi.kumar@wipro.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQorV-0002FY-00
	for megaco@ietf.org; Mon, 01 Dec 2003 09:17:17 -0500
Received: from wiproecmx2.wipro.com ([164.164.31.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQorT-0002D7-00
	for megaco@ietf.org; Mon, 01 Dec 2003 09:17:16 -0500
Received: from ec-vwall-wd.wipro.com (ecvwall7.wipro.com [10.200.52.125])
	by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id hB1EGfAj021786
	for <megaco@ietf.org>; Mon, 1 Dec 2003 19:46:41 +0530 (IST)
Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Mon, 01 Dec 2003 19:50:47 +0530
Received: from blr-ec-msg02.wipro.com ([10.200.51.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 1 Dec 2003 19:44:45 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Megaco] Digit Map Completion Event
Date: Mon, 1 Dec 2003 19:44:45 +0530
Message-ID: <E26955DC2678894D9A5C3EB4C0892F2F9922CB@blr-ec-msg02.wipro.com>
Thread-Topic: [Megaco] Digit Map Completion Event
Thread-Index: AcO4E/q2VYeXnt+lTyy0RNtIbInRoQAAJadw
To: <juergen.tegeler@siemens.com>, <megaco@ietf.org>
X-OriginalArrivalTime: 01 Dec 2003 14:14:45.0577 (UTC) FILETIME=[78B9C390:01C3B815]
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi,

  The statement in the RFC is to address more than one digit event being =
active and processing subsequent digit map completion events.  I believe =
there was some discussion on the list in this regard (I do not remember =
the thread though)

  Hope this helps...
 =20
Thanks,
Shashi


-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Tegeler Juergen
Sent: Monday, December 01, 2003 3:44 PM
To: megaco@ietf.org
Subject: [Megaco] Digit Map Completion Event


Hi all,

the following question about Digit Map Completion Event came up=20
while reading H.248.1 (05/2002):

Chapter 7.1.14.4:
..
Upon completion, a digit map completion event as defined in the package =
providing the events being mapped into the digit map shall be generated. =
At that point the digit map is deactivated. Subsequent events in the =
package are processed as follows:
*	If EventBufferControl is ON, subsequent digit events are processed in =
the same way as any other events;
..

Isn' t that a contradiction? What to do with digits received in the MGC =
after reception of Digit Map Completion event?


Best regards,

Juergen Tegeler =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-admin@ietf.org  Mon Dec  1 11:54:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17471
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 11:54:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQrJB-0001JX-FQ; Mon, 01 Dec 2003 11:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQrIi-0001Is-0z
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 11:53:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17451
	for <megaco@ietf.org>; Mon, 1 Dec 2003 11:53:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQrIg-00055S-00
	for megaco@ietf.org; Mon, 01 Dec 2003 11:53:30 -0500
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQrIf-00054z-00
	for megaco@ietf.org; Mon, 01 Dec 2003 11:53:30 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB1GqiS06628
	for <megaco@ietf.org>; Mon, 1 Dec 2003 10:52:47 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA01856; Mon, 1 Dec 2003 11:53:05 -0500 (EST)
Cc: megaco@ietf.org
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA01847; Mon, 1 Dec 2003 11:53:04 -0500 (EST)
Message-ID: <3FCB724E.8080003@bell-labs.com>
Date: Mon, 01 Dec 2003 11:54:38 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
Original-CC: megaco@ietf.org
Subject: Re: [Megaco] Embedded Events Behaviour
References: <ABA227A15B80D511BD1A00508BF93A1C0CE5A3DE@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0CE5A3DE@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Kevin Boyle wrote:

> Your description is correct -- all events must be reported when detected,
> regardless of whether the event has signals and/or events embedded on it.  I
> believe others have described the text where this is stated.
> 
> I would point out that there are many differences between MGCP and H.248 --
> this being one of the smaller differences.  As for why, it is illegal to
> send a single Notify command with two Events descriptors.  This means that
> the MG would have to build messages with two commands, and so really isn't
> saving much over sending one message at the time of each event detection.
> Further, I cannot understand why it is good practice for the MG to hold onto
> event notifications for any length of time.  

Here's one:  Section 9.1 says that (for UDP) there should be at most one
outstanding Notify per Termination.  This is in order to guarantee that
the events reach the MGC in the right order.  This implies waiting for an ACK
before transmitting the next Notify.

What is the MG doing with events during this time?  Are the Notifies queued
for transmission regardless of whatever RequestedEvent descriptors are received
before they are transmitted?

-troy

> If the MGC wants to know an
> event occurred, then why wouldn't the MG send the event right away? The MGC
> may want to take action based upon the event, even if it had already
> embedded the next processing step.  By holding onto the notification, the MG
> is limiting the MGC's abilities.





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


From exim@www1.ietf.org  Mon Dec  1 11:54:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17486
	for <megaco-archive@odin.ietf.org>; Mon, 1 Dec 2003 11:54:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQrJG-0001KJ-3J
	for megaco-archive@odin.ietf.org; Mon, 01 Dec 2003 11:54:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1Gs62t005095
	for megaco-archive@odin.ietf.org; Mon, 1 Dec 2003 11:54:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQrJE-0001K6-J8
	for megaco-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 11:54:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17456
	for <megaco-web-archive@ietf.org>; Mon, 1 Dec 2003 11:53:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQrJD-00055c-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 11:54:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQrJC-00055Z-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 11:54:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQrJB-0001JX-FQ; Mon, 01 Dec 2003 11:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQrIi-0001Is-0z
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 11:53:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17451
	for <megaco@ietf.org>; Mon, 1 Dec 2003 11:53:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQrIg-00055S-00
	for megaco@ietf.org; Mon, 01 Dec 2003 11:53:30 -0500
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQrIf-00054z-00
	for megaco@ietf.org; Mon, 01 Dec 2003 11:53:30 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB1GqiS06628
	for <megaco@ietf.org>; Mon, 1 Dec 2003 10:52:47 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA01856; Mon, 1 Dec 2003 11:53:05 -0500 (EST)
Cc: megaco@ietf.org
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id LAA01847; Mon, 1 Dec 2003 11:53:04 -0500 (EST)
Message-ID: <3FCB724E.8080003@bell-labs.com>
Date: Mon, 01 Dec 2003 11:54:38 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
Original-CC: megaco@ietf.org
Subject: Re: [Megaco] Embedded Events Behaviour
References: <ABA227A15B80D511BD1A00508BF93A1C0CE5A3DE@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0CE5A3DE@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Kevin Boyle wrote:

> Your description is correct -- all events must be reported when detected,
> regardless of whether the event has signals and/or events embedded on it.  I
> believe others have described the text where this is stated.
> 
> I would point out that there are many differences between MGCP and H.248 --
> this being one of the smaller differences.  As for why, it is illegal to
> send a single Notify command with two Events descriptors.  This means that
> the MG would have to build messages with two commands, and so really isn't
> saving much over sending one message at the time of each event detection.
> Further, I cannot understand why it is good practice for the MG to hold onto
> event notifications for any length of time.  

Here's one:  Section 9.1 says that (for UDP) there should be at most one
outstanding Notify per Termination.  This is in order to guarantee that
the events reach the MGC in the right order.  This implies waiting for an ACK
before transmitting the next Notify.

What is the MG doing with events during this time?  Are the Notifies queued
for transmission regardless of whatever RequestedEvent descriptors are received
before they are transmitted?

-troy

> If the MGC wants to know an
> event occurred, then why wouldn't the MG send the event right away? The MGC
> may want to take action based upon the event, even if it had already
> embedded the next processing step.  By holding onto the notification, the MG
> is limiting the MGC's abilities.





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



From megaco-admin@ietf.org  Mon Dec  1 13:17:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20852
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 13:17:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQsbX-0007LV-9T; Mon, 01 Dec 2003 13:17:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQsbA-0007Er-IG
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 13:16:40 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20746
	for <megaco@ietf.org>; Mon, 1 Dec 2003 13:16:24 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQsb8-0006C5-00
	for megaco@ietf.org; Mon, 01 Dec 2003 13:16:38 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQsb7-0006Bh-00
	for megaco@ietf.org; Mon, 01 Dec 2003 13:16:37 -0500
Received: from cisco.com (171.68.223.138)
  by sj-iport-5.cisco.com with ESMTP; 01 Dec 2003 10:15:30 -0800
Received: from sampathkw2k02 (dhcp-171-71-248-87.cisco.com [171.71.248.87])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hB1IFsiN001403
	for <megaco@ietf.org>; Mon, 1 Dec 2003 10:15:54 -0800 (PST)
From: "Sampath Komanduri" <sampathk@cisco.com>
To: <megaco@ietf.org>
Subject: RE: [Megaco] Descriptor processing on Termination OOS
Date: Mon, 1 Dec 2003 10:15:50 -0800
Message-ID: <000701c3b837$29902350$57f847ab@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <003301c3b2f5$d9c16e10$c80947ab@amer.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hi all,
Could someone pls. answer my question?

Thanks,
Sampath


-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Sampath Komanduri
Sent: Monday, November 24, 2003 5:46 PM
To: megaco@ietf.org
Subject: [Megaco] Descriptor processing on Termination OOS


Hi,
What should be the descriptors state when a termination is service
changed to state OOS? 
Is it ok to remove all the descriptors that are currently applied on the
termination or 
should MG keep the information of descriptors so that they can be
re-applied if the termination comes to in-service state again.

Thanks,
Sampath


_______________________________________________
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 exim@www1.ietf.org  Mon Dec  1 13:17:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20867
	for <megaco-archive@odin.ietf.org>; Mon, 1 Dec 2003 13:17:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQsbd-0007R1-Oh
	for megaco-archive@odin.ietf.org; Mon, 01 Dec 2003 13:17:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1IH9LS028573
	for megaco-archive@odin.ietf.org; Mon, 1 Dec 2003 13:17:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQsbd-0007Qm-Hp
	for megaco-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 13:17:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20782
	for <megaco-web-archive@ietf.org>; Mon, 1 Dec 2003 13:16:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQsbb-0006CS-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 13:17:07 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQsbb-0006CO-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 13:17:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQsbX-0007LV-9T; Mon, 01 Dec 2003 13:17:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQsbA-0007Er-IG
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 13:16:40 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20746
	for <megaco@ietf.org>; Mon, 1 Dec 2003 13:16:24 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQsb8-0006C5-00
	for megaco@ietf.org; Mon, 01 Dec 2003 13:16:38 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQsb7-0006Bh-00
	for megaco@ietf.org; Mon, 01 Dec 2003 13:16:37 -0500
Received: from cisco.com (171.68.223.138)
  by sj-iport-5.cisco.com with ESMTP; 01 Dec 2003 10:15:30 -0800
Received: from sampathkw2k02 (dhcp-171-71-248-87.cisco.com [171.71.248.87])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hB1IFsiN001403
	for <megaco@ietf.org>; Mon, 1 Dec 2003 10:15:54 -0800 (PST)
From: "Sampath Komanduri" <sampathk@cisco.com>
To: <megaco@ietf.org>
Subject: RE: [Megaco] Descriptor processing on Termination OOS
Date: Mon, 1 Dec 2003 10:15:50 -0800
Message-ID: <000701c3b837$29902350$57f847ab@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <003301c3b2f5$d9c16e10$c80947ab@amer.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi all,
Could someone pls. answer my question?

Thanks,
Sampath


-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Sampath Komanduri
Sent: Monday, November 24, 2003 5:46 PM
To: megaco@ietf.org
Subject: [Megaco] Descriptor processing on Termination OOS


Hi,
What should be the descriptors state when a termination is service
changed to state OOS? 
Is it ok to remove all the descriptors that are currently applied on the
termination or 
should MG keep the information of descriptors so that they can be
re-applied if the termination comes to in-service state again.

Thanks,
Sampath


_______________________________________________
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-admin@ietf.org  Mon Dec  1 13:23:17 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21307
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 13:23:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQshJ-00088t-U6; Mon, 01 Dec 2003 13:23:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQshC-00088M-OP
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 13:22:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21291
	for <megaco@ietf.org>; Mon, 1 Dec 2003 13:22:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQshA-0006JL-00
	for megaco@ietf.org; Mon, 01 Dec 2003 13:22:52 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQshA-0006Ic-00
	for megaco@ietf.org; Mon, 01 Dec 2003 13:22:52 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB1IM4U05868;
	Mon, 1 Dec 2003 13:22:04 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLY2CL1Y; Mon, 1 Dec 2003 13:22:04 -0500
Received: from nortelnetworks.com (acart1d3.ca.nortel.com [47.129.129.79]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLPWM8LS; Mon, 1 Dec 2003 13:22:05 -0500
Message-ID: <3FCB86CB.9090701@nortelnetworks.com>
Date: Mon, 01 Dec 2003 13:22:03 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sampath Komanduri <sampathk@cisco.com>
CC: megaco@ietf.org
Subject: Re: [Megaco] Descriptor processing on Termination OOS
References: <000701c3b837$29902350$57f847ab@amer.cisco.com>
In-Reply-To: <000701c3b837$29902350$57f847ab@amer.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

The descriptors (aside from TerminationState) remain unchanged until 
either the MGC changes them or the MG undergoes a cold restart.

Sampath Komanduri wrote:

> Hi all,
> Could someone pls. answer my question?
> 
> Thanks,
> Sampath
> 
> 
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
> Sampath Komanduri
> Sent: Monday, November 24, 2003 5:46 PM
> To: megaco@ietf.org
> Subject: [Megaco] Descriptor processing on Termination OOS
> 
> 
> Hi,
> What should be the descriptors state when a termination is service
> changed to state OOS? 
> Is it ok to remove all the descriptors that are currently applied on the
> termination or 
> should MG keep the information of descriptors so that they can be
> re-applied if the termination comes to in-service state again.
> 
> Thanks,
> Sampath
> 
> 
> _______________________________________________
> 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-admin@ietf.org  Mon Dec  1 15:27:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26830
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 15:27:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQudJ-0006go-U2; Mon, 01 Dec 2003 15:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQucS-0006fY-LV
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 15:26:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26787
	for <megaco@ietf.org>; Mon, 1 Dec 2003 15:25:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQucR-0007h6-00
	for megaco@ietf.org; Mon, 01 Dec 2003 15:26:07 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQucQ-0007h3-00
	for megaco@ietf.org; Mon, 01 Dec 2003 15:26:06 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Mon, 1 Dec 2003 15:25:57 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZSSF7>; Mon, 1 Dec 2003 15:25:57 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B09EB@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: megaco@ietf.org
Date: Mon, 1 Dec 2003 15:25:56 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B849.532BD210"
Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (L), & Short T
 imers (S)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3B849.532BD210
Content-Type: text/plain;
	charset="iso-8859-1"

 
According to the syntax in RFCs 3015 & 3525 the long duration modifier (Z),
Long Timers (L), & Short Timers (S) in digit maps can appear in a digit
range.  For example (where Z is 1000ms):
    "135[2Z46]"
 
Is this valid?  If it is valid, does this mean that the fourth digit event
must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
 
How does long timer (L) and short timer (S) in a digit range apply?
 
--Stephen
 
 

------_=_NextPart_001_01C3B849.532BD210
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">


<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial size=2>According to the 
syntax in RFCs 3015 &amp; 3525 the long duration modifier (Z),  Long Timers (L), 
&amp; Short Timers (S) in digit maps can appear in a digit range.&nbsp; For 
example (where Z is 1000ms):</FONT></SPAN></DIV>
<DIV><SPAN class=695380620-01122003>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
size=2>"135[2Z46]"</FONT></SPAN></DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial size=2>Is this valid?&nbsp; 
If it is valid, does this mean that the fourth digit event must be either 2, 6 
(held for any duration) or 4 held for 1000 ms?</FONT></SPAN></DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial size=2>How does long timer 
(L) and short timer (S) in a digit range apply?</FONT></SPAN></DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial 
size=2>--Stephen</FONT></SPAN></DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C3B849.532BD210--

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


From exim@www1.ietf.org  Mon Dec  1 15:27:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26845
	for <megaco-archive@odin.ietf.org>; Mon, 1 Dec 2003 15:27:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQudN-0006hY-88
	for megaco-archive@odin.ietf.org; Mon, 01 Dec 2003 15:27:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1KR58b025761
	for megaco-archive@odin.ietf.org; Mon, 1 Dec 2003 15:27:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQudN-0006hQ-2E
	for megaco-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 15:27:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26821
	for <megaco-web-archive@ietf.org>; Mon, 1 Dec 2003 15:26:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQudL-0007ho-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 15:27:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQudL-0007hl-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 15:27:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQudJ-0006go-U2; Mon, 01 Dec 2003 15:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQucS-0006fY-LV
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 15:26:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26787
	for <megaco@ietf.org>; Mon, 1 Dec 2003 15:25:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQucR-0007h6-00
	for megaco@ietf.org; Mon, 01 Dec 2003 15:26:07 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQucQ-0007h3-00
	for megaco@ietf.org; Mon, 01 Dec 2003 15:26:06 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Mon, 1 Dec 2003 15:25:57 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZSSF7>; Mon, 1 Dec 2003 15:25:57 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B09EB@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: megaco@ietf.org
Date: Mon, 1 Dec 2003 15:25:56 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B849.532BD210"
Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (L), & Short T
 imers (S)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3B849.532BD210
Content-Type: text/plain;
	charset="iso-8859-1"

 
According to the syntax in RFCs 3015 & 3525 the long duration modifier (Z),
Long Timers (L), & Short Timers (S) in digit maps can appear in a digit
range.  For example (where Z is 1000ms):
    "135[2Z46]"
 
Is this valid?  If it is valid, does this mean that the fourth digit event
must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
 
How does long timer (L) and short timer (S) in a digit range apply?
 
--Stephen
 
 

------_=_NextPart_001_01C3B849.532BD210
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">


<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial size=2>According to the 
syntax in RFCs 3015 &amp; 3525 the long duration modifier (Z),  Long Timers (L), 
&amp; Short Timers (S) in digit maps can appear in a digit range.&nbsp; For 
example (where Z is 1000ms):</FONT></SPAN></DIV>
<DIV><SPAN class=695380620-01122003>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
size=2>"135[2Z46]"</FONT></SPAN></DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial size=2>Is this valid?&nbsp; 
If it is valid, does this mean that the fourth digit event must be either 2, 6 
(held for any duration) or 4 held for 1000 ms?</FONT></SPAN></DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial size=2>How does long timer 
(L) and short timer (S) in a digit range apply?</FONT></SPAN></DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial 
size=2>--Stephen</FONT></SPAN></DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=695380620-01122003><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C3B849.532BD210--

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



From megaco-admin@ietf.org  Mon Dec  1 16:55:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03265
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 16:55:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQw0U-0005QO-Gs; Mon, 01 Dec 2003 16:55:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQw01-0005Pm-KF
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 16:54:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03218
	for <megaco@ietf.org>; Mon, 1 Dec 2003 16:54:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQvzn-0002bL-00
	for megaco@ietf.org; Mon, 01 Dec 2003 16:54:19 -0500
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQvzm-0002ae-00
	for megaco@ietf.org; Mon, 01 Dec 2003 16:54:18 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB1Lrgg23116
	for <megaco@ietf.org>; Mon, 1 Dec 2003 15:53:43 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA04840; Mon, 1 Dec 2003 16:53:51 -0500 (EST)
Cc: megaco@ietf.org
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA04831; Mon, 1 Dec 2003 16:53:49 -0500 (EST)
Message-ID: <3FCBB8CA.9000306@bell-labs.com>
Date: Mon, 01 Dec 2003 16:55:22 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steve Cipolli <SCipolli@radvision.com>
Original-CC: megaco@ietf.org
Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (L),
 & Short T imers (S)
References: <A3851AA1B761E944912B20D1E95A7EFE0B09EB@radvpost.radvision.com>
In-Reply-To: <A3851AA1B761E944912B20D1E95A7EFE0B09EB@radvpost.radvision.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Steve Cipolli wrote:

> 
>  
> According to the syntax in RFCs 3015 & 3525 the long duration modifier 
> (Z), Long Timers (L), & Short Timers (S) in digit maps can appear in a 
> digit range.  For example (where Z is 1000ms):
>     "135[2Z46]"
>  
> Is this valid?  If it is valid, does this mean that the fourth digit 
> event must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
>  
> How does long timer (L) and short timer (S) in a digit range apply?
>  
> --Stephen
>  
>  


 From H.248.1

> In addition to these event symbols, the string may contain "S" and "L" 
 > inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
 > respectively indicate that the MG should use the short (S) timer or the
 > long (L) timer for subsequent events, overriding the timing rules
 > described above. If an explicit timing specifier is in effect in one
 > alternative event sequence, but none is given in any other candidate
 > alternative, the timer value set by the explicit timing specifier must be
 > used. If all sequences with explicit timing controls are dropped from the
 > candidate set, timing reverts to the default rules given above. Finally,
 > if conflicting timing specifiers are in effect in different alternative
 > sequences, the long timer shall be used.
 >
> A "Z" designates a long duration event: placed in front of the symbol(s) 
 > designating the event(s) which satisfy a given digit position, it indicates
> that that position is satisfied only if the duration of the event exceeds 
> the long-duration threshold. The value of this threshold is assumed to be 
> provisioned in the MG.



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


From exim@www1.ietf.org  Mon Dec  1 16:55:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03280
	for <megaco-archive@odin.ietf.org>; Mon, 1 Dec 2003 16:55:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQw0Y-0005RP-6R
	for megaco-archive@odin.ietf.org; Mon, 01 Dec 2003 16:55:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1Lt6QR020911
	for megaco-archive@odin.ietf.org; Mon, 1 Dec 2003 16:55:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQw0Y-0005RC-3Q
	for megaco-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 16:55:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03250
	for <megaco-web-archive@ietf.org>; Mon, 1 Dec 2003 16:54:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQw0V-0002c0-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 16:55:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQw0V-0002bx-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 16:55:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQw0U-0005QO-Gs; Mon, 01 Dec 2003 16:55:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQw01-0005Pm-KF
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 16:54:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03218
	for <megaco@ietf.org>; Mon, 1 Dec 2003 16:54:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQvzn-0002bL-00
	for megaco@ietf.org; Mon, 01 Dec 2003 16:54:19 -0500
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQvzm-0002ae-00
	for megaco@ietf.org; Mon, 01 Dec 2003 16:54:18 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB1Lrgg23116
	for <megaco@ietf.org>; Mon, 1 Dec 2003 15:53:43 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA04840; Mon, 1 Dec 2003 16:53:51 -0500 (EST)
Cc: megaco@ietf.org
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA04831; Mon, 1 Dec 2003 16:53:49 -0500 (EST)
Message-ID: <3FCBB8CA.9000306@bell-labs.com>
Date: Mon, 01 Dec 2003 16:55:22 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steve Cipolli <SCipolli@radvision.com>
Original-CC: megaco@ietf.org
Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (L),
 & Short T imers (S)
References: <A3851AA1B761E944912B20D1E95A7EFE0B09EB@radvpost.radvision.com>
In-Reply-To: <A3851AA1B761E944912B20D1E95A7EFE0B09EB@radvpost.radvision.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Steve Cipolli wrote:

> 
>  
> According to the syntax in RFCs 3015 & 3525 the long duration modifier 
> (Z), Long Timers (L), & Short Timers (S) in digit maps can appear in a 
> digit range.  For example (where Z is 1000ms):
>     "135[2Z46]"
>  
> Is this valid?  If it is valid, does this mean that the fourth digit 
> event must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
>  
> How does long timer (L) and short timer (S) in a digit range apply?
>  
> --Stephen
>  
>  


 From H.248.1

> In addition to these event symbols, the string may contain "S" and "L" 
 > inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
 > respectively indicate that the MG should use the short (S) timer or the
 > long (L) timer for subsequent events, overriding the timing rules
 > described above. If an explicit timing specifier is in effect in one
 > alternative event sequence, but none is given in any other candidate
 > alternative, the timer value set by the explicit timing specifier must be
 > used. If all sequences with explicit timing controls are dropped from the
 > candidate set, timing reverts to the default rules given above. Finally,
 > if conflicting timing specifiers are in effect in different alternative
 > sequences, the long timer shall be used.
 >
> A "Z" designates a long duration event: placed in front of the symbol(s) 
 > designating the event(s) which satisfy a given digit position, it indicates
> that that position is satisfied only if the duration of the event exceeds 
> the long-duration threshold. The value of this threshold is assumed to be 
> provisioned in the MG.



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



From megaco-admin@ietf.org  Mon Dec  1 17:05:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04476
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 17:05:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwAA-00064T-FN; Mon, 01 Dec 2003 17:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQw9i-00063k-Tr
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 17:04:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04370
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:04:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQw9g-00035R-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:04:32 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQw9f-00033Q-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:04:31 -0500
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 hB1M3r016572
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:03:53 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <WTQH9QAF>; Mon, 1 Dec 2003 17:03:53 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0CF02F0A@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Troy Cauble <troy@bell-labs.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Embedded Events Behaviour
Date: Mon, 1 Dec 2003 17:03:53 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Well... You caught me!  Indeed, for non-reliable transports then the MG has
to wait for the ACK between Notifies.  I would point out that for most call
processing functions, however, the speed at which things like this have to
be processed would produce the "event holding" scenario rarely, if at all.

Well, unless you're trying to run the control association over the wilds of
the internet or some other lossy, low reliability network. :)

While awaiting transmission of a Notify, the MG would be queuing subsequent
ObservedEvents based upon the current Events descriptor awaiting the next
opportunity to send a Notify.  If EventBuffering is enabled, then the MG
would be buffering Events based on the current EB descriptor to see if the
next Events descriptor would cause any matches and, therefore, Notifies.

Kevin

-----Original Message-----
From: Troy Cauble [mailto:troy@bell-labs.com] 
Sent: Monday, December 01, 2003 11:55 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: Re: [Megaco] Embedded Events Behaviour

Kevin Boyle wrote:

> Your description is correct -- all events must be reported when 
> detected, regardless of whether the event has signals and/or events 
> embedded on it.  I believe others have described the text where this is
stated.
> 
> I would point out that there are many differences between MGCP and 
> H.248 -- this being one of the smaller differences.  As for why, it is 
> illegal to send a single Notify command with two Events descriptors.  
> This means that the MG would have to build messages with two commands, 
> and so really isn't saving much over sending one message at the time of
each event detection.
> Further, I cannot understand why it is good practice for the MG to 
> hold onto event notifications for any length of time.

Here's one:  Section 9.1 says that (for UDP) there should be at most one
outstanding Notify per Termination.  This is in order to guarantee that the
events reach the MGC in the right order.  This implies waiting for an ACK
before transmitting the next Notify.

What is the MG doing with events during this time?  Are the Notifies queued
for transmission regardless of whatever RequestedEvent descriptors are
received before they are transmitted?

-troy

> If the MGC wants to know an
> event occurred, then why wouldn't the MG send the event right away? 
> The MGC may want to take action based upon the event, even if it had 
> already embedded the next processing step.  By holding onto the 
> notification, the MG is limiting the MGC's abilities.





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


From exim@www1.ietf.org  Mon Dec  1 17:05:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04536
	for <megaco-archive@odin.ietf.org>; Mon, 1 Dec 2003 17:05:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwAM-000679-W3
	for megaco-archive@odin.ietf.org; Mon, 01 Dec 2003 17:05:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1M5Era023497
	for megaco-archive@odin.ietf.org; Mon, 1 Dec 2003 17:05:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwAM-00066u-Re
	for megaco-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 17:05:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04452
	for <megaco-web-archive@ietf.org>; Mon, 1 Dec 2003 17:04:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwAK-00036t-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 17:05:12 -0500
Received: from manatick.foretec.com ([4.17.168.5] helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwAJ-00036q-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 17:05:12 -0500
Received: from [132.151.6.22] (helo=optimus.ietf.org)
	by manatick with esmtp (Exim 4.24)
	id 1AQwAG-0005ym-Ng
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 17:05:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwAA-00064T-FN; Mon, 01 Dec 2003 17:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQw9i-00063k-Tr
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 17:04:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04370
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:04:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQw9g-00035R-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:04:32 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQw9f-00033Q-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:04:31 -0500
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 hB1M3r016572
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:03:53 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <WTQH9QAF>; Mon, 1 Dec 2003 17:03:53 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0CF02F0A@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Troy Cauble <troy@bell-labs.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Embedded Events Behaviour
Date: Mon, 1 Dec 2003 17:03:53 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Well... You caught me!  Indeed, for non-reliable transports then the MG has
to wait for the ACK between Notifies.  I would point out that for most call
processing functions, however, the speed at which things like this have to
be processed would produce the "event holding" scenario rarely, if at all.

Well, unless you're trying to run the control association over the wilds of
the internet or some other lossy, low reliability network. :)

While awaiting transmission of a Notify, the MG would be queuing subsequent
ObservedEvents based upon the current Events descriptor awaiting the next
opportunity to send a Notify.  If EventBuffering is enabled, then the MG
would be buffering Events based on the current EB descriptor to see if the
next Events descriptor would cause any matches and, therefore, Notifies.

Kevin

-----Original Message-----
From: Troy Cauble [mailto:troy@bell-labs.com] 
Sent: Monday, December 01, 2003 11:55 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: Re: [Megaco] Embedded Events Behaviour

Kevin Boyle wrote:

> Your description is correct -- all events must be reported when 
> detected, regardless of whether the event has signals and/or events 
> embedded on it.  I believe others have described the text where this is
stated.
> 
> I would point out that there are many differences between MGCP and 
> H.248 -- this being one of the smaller differences.  As for why, it is 
> illegal to send a single Notify command with two Events descriptors.  
> This means that the MG would have to build messages with two commands, 
> and so really isn't saving much over sending one message at the time of
each event detection.
> Further, I cannot understand why it is good practice for the MG to 
> hold onto event notifications for any length of time.

Here's one:  Section 9.1 says that (for UDP) there should be at most one
outstanding Notify per Termination.  This is in order to guarantee that the
events reach the MGC in the right order.  This implies waiting for an ACK
before transmitting the next Notify.

What is the MG doing with events during this time?  Are the Notifies queued
for transmission regardless of whatever RequestedEvent descriptors are
received before they are transmitted?

-troy

> If the MGC wants to know an
> event occurred, then why wouldn't the MG send the event right away? 
> The MGC may want to take action based upon the event, even if it had 
> already embedded the next processing step.  By holding onto the 
> notification, the MG is limiting the MGC's abilities.





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



From megaco-admin@ietf.org  Mon Dec  1 17:10:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04924
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 17:10:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwF0-0006ew-IZ; Mon, 01 Dec 2003 17:10:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwEt-0006eU-Vy
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 17:09:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04886
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:09:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwEr-0003HM-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:09:53 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwEr-0003GE-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:09:53 -0500
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 hB1M9M016854
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:09:22 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <WTQH9Q11>; Mon, 1 Dec 2003 17:09:22 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0CF02F2A@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Tegeler Juergen <juergen.tegeler@siemens.com>, megaco@ietf.org
Subject: RE: [Megaco] Digit Map Completion Event
Date: Mon, 1 Dec 2003 17:09:20 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

No, it is not a contradiction.  If EventBuffering is enabled, then
subsequent digit events are compared to the current EB descriptor.  If the
digit event is in the EB descriptor, then it is saved pending the next
Events descriptor.  If it is not, then it is discarded.

Remember that digitmaps are not the only mechanism for collecting digit
events.

Kevin

-----Original Message-----
From: Tegeler Juergen [mailto:juergen.tegeler@siemens.com] 
Sent: Monday, December 01, 2003 5:14 AM
To: megaco@ietf.org
Subject: [Megaco] Digit Map Completion Event

Hi all,

the following question about Digit Map Completion Event came up while
reading H.248.1 (05/2002):

Chapter 7.1.14.4:
..
Upon completion, a digit map completion event as defined in the package
providing the events being mapped into the digit map shall be generated. At
that point the digit map is deactivated. Subsequent events in the package
are processed as follows:
*	If EventBufferControl is ON, subsequent digit events are processed
in the same way as any other events;
..

Isn' t that a contradiction? What to do with digits received in the MGC
after reception of Digit Map Completion event?


Best regards,

Juergen Tegeler  







_______________________________________________
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 exim@www1.ietf.org  Mon Dec  1 17:10:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04940
	for <megaco-archive@odin.ietf.org>; Mon, 1 Dec 2003 17:10:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwF3-0006gT-02
	for megaco-archive@odin.ietf.org; Mon, 01 Dec 2003 17:10:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1MA45R025687
	for megaco-archive@odin.ietf.org; Mon, 1 Dec 2003 17:10:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwF2-0006gE-KA
	for megaco-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 17:10:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04898
	for <megaco-web-archive@ietf.org>; Mon, 1 Dec 2003 17:09:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwF0-0003Hl-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 17:10:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwEz-0003Hi-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 17:10:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwF0-0006ew-IZ; Mon, 01 Dec 2003 17:10:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwEt-0006eU-Vy
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 17:09:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04886
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:09:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwEr-0003HM-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:09:53 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwEr-0003GE-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:09:53 -0500
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 hB1M9M016854
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:09:22 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <WTQH9Q11>; Mon, 1 Dec 2003 17:09:22 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0CF02F2A@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Tegeler Juergen <juergen.tegeler@siemens.com>, megaco@ietf.org
Subject: RE: [Megaco] Digit Map Completion Event
Date: Mon, 1 Dec 2003 17:09:20 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

No, it is not a contradiction.  If EventBuffering is enabled, then
subsequent digit events are compared to the current EB descriptor.  If the
digit event is in the EB descriptor, then it is saved pending the next
Events descriptor.  If it is not, then it is discarded.

Remember that digitmaps are not the only mechanism for collecting digit
events.

Kevin

-----Original Message-----
From: Tegeler Juergen [mailto:juergen.tegeler@siemens.com] 
Sent: Monday, December 01, 2003 5:14 AM
To: megaco@ietf.org
Subject: [Megaco] Digit Map Completion Event

Hi all,

the following question about Digit Map Completion Event came up while
reading H.248.1 (05/2002):

Chapter 7.1.14.4:
..
Upon completion, a digit map completion event as defined in the package
providing the events being mapped into the digit map shall be generated. At
that point the digit map is deactivated. Subsequent events in the package
are processed as follows:
*	If EventBufferControl is ON, subsequent digit events are processed
in the same way as any other events;
..

Isn' t that a contradiction? What to do with digits received in the MGC
after reception of Digit Map Completion event?


Best regards,

Juergen Tegeler  







_______________________________________________
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-admin@ietf.org  Mon Dec  1 17:16:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05428
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 17:16:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwKo-00072b-3W; Mon, 01 Dec 2003 17:16:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwKN-00072F-S0
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 17:15:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05362
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:15:20 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwKL-0003Rn-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:15:33 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwKK-0003QK-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:15:32 -0500
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 hB1MF1017113
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:15:01 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <WTQH9Q2K>; Mon, 1 Dec 2003 17:15:01 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0CF02F55@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Steve Cipolli <SCipolli@radvision.com>, megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	L), & Short T imers (S)
Date: Mon, 1 Dec 2003 17:15:01 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Your interpretation is correct.  Because Z changes how a digit is matched,
it makes sense within a range.  Think of Z as part of the digit it modifies,
rather than a separate symbol.
 
The L and S timers within a digitmap give specific instruction as to which
timer to run at that point in the digitmap.  While allowed in a range, I
don't think they provide much value within a range since they do not
actually match anything.  For effective use, they should be outside the
range.
 
Kevin


  _____  

From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Monday, December 01, 2003 3:26 PM
To: megaco@ietf.org
Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (L), &
Short T imers (S)


 
According to the syntax in RFCs 3015 & 3525 the long duration modifier (Z),
Long Timers (L), & Short Timers (S) in digit maps can appear in a digit
range.  For example (where Z is 1000ms):
    "135[2Z46]"
 
Is this valid?  If it is valid, does this mean that the fourth digit event
must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
 
How does long timer (L) and short timer (S) in a digit range apply?
 
--Stephen
 
 


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


From exim@www1.ietf.org  Mon Dec  1 17:16:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05446
	for <megaco-archive@odin.ietf.org>; Mon, 1 Dec 2003 17:16:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwKq-000748-Ua
	for megaco-archive@odin.ietf.org; Mon, 01 Dec 2003 17:16:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1MG4tj027154
	for megaco-archive@odin.ietf.org; Mon, 1 Dec 2003 17:16:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwKq-00073t-Pg
	for megaco-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 17:16:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05402
	for <megaco-web-archive@ietf.org>; Mon, 1 Dec 2003 17:15:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwKo-0003Te-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 17:16:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwKo-0003Tb-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 17:16:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwKo-00072b-3W; Mon, 01 Dec 2003 17:16:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwKN-00072F-S0
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 17:15:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05362
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:15:20 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwKL-0003Rn-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:15:33 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwKK-0003QK-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:15:32 -0500
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 hB1MF1017113
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:15:01 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <WTQH9Q2K>; Mon, 1 Dec 2003 17:15:01 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0CF02F55@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Steve Cipolli <SCipolli@radvision.com>, megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	L), & Short T imers (S)
Date: Mon, 1 Dec 2003 17:15:01 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Your interpretation is correct.  Because Z changes how a digit is matched,
it makes sense within a range.  Think of Z as part of the digit it modifies,
rather than a separate symbol.
 
The L and S timers within a digitmap give specific instruction as to which
timer to run at that point in the digitmap.  While allowed in a range, I
don't think they provide much value within a range since they do not
actually match anything.  For effective use, they should be outside the
range.
 
Kevin


  _____  

From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Monday, December 01, 2003 3:26 PM
To: megaco@ietf.org
Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (L), &
Short T imers (S)


 
According to the syntax in RFCs 3015 & 3525 the long duration modifier (Z),
Long Timers (L), & Short Timers (S) in digit maps can appear in a digit
range.  For example (where Z is 1000ms):
    "135[2Z46]"
 
Is this valid?  If it is valid, does this mean that the fourth digit event
must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
 
How does long timer (L) and short timer (S) in a digit range apply?
 
--Stephen
 
 


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



From megaco-admin@ietf.org  Mon Dec  1 17:23:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06131
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 17:23:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwRZ-0007Pp-NX; Mon, 01 Dec 2003 17:23:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwR0-0007Mn-PS
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 17:22:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06023
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:22:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwQy-0003jH-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:22:24 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwQx-0003j9-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:22:24 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Mon, 1 Dec 2003 17:22:13 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZSSQC>; Mon, 1 Dec 2003 17:22:13 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B09ED@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>, megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 	L), & Short T imers (S)
Date: Mon, 1 Dec 2003 17:22:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B859.911F8CF0"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3B859.911F8CF0
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks for the feedback.  
 
Just to make sure I understand the L and S cases:
They are syntactically legal in a range specification, but semantically they
have no effect.  Correct?
 
--Stephen

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, December 01, 2003 5:15 PM
To: Steve Cipolli; megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


Your interpretation is correct.  Because Z changes how a digit is matched,
it makes sense within a range.  Think of Z as part of the digit it modifies,
rather than a separate symbol.
 
The L and S timers within a digitmap give specific instruction as to which
timer to run at that point in the digitmap.  While allowed in a range, I
don't think they provide much value within a range since they do not
actually match anything.  For effective use, they should be outside the
range.
 
Kevin


  _____  

From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Monday, December 01, 2003 3:26 PM
To: megaco@ietf.org
Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (L), &
Short T imers (S)


 
According to the syntax in RFCs 3015 & 3525 the long duration modifier (Z),
Long Timers (L), & Short Timers (S) in digit maps can appear in a digit
range.  For example (where Z is 1000ms):
    "135[2Z46]"
 
Is this valid?  If it is valid, does this mean that the fourth digit event
must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
 
How does long timer (L) and short timer (S) in a digit range apply?
 
--Stephen
 
 


------_=_NextPart_001_01C3B859.911F8CF0
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">


<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=406151822-01122003>Thanks 
for the feedback.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=406151822-01122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=406151822-01122003>Just 
to make sure I understand the L and S cases:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=406151822-01122003>They 
are syntactically legal in a range specification, but semantically they have no 
effect.&nbsp; Correct?</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=406151822-01122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=406151822-01122003>--Stephen</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; 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> Monday, December 01, 2003 
  5:15 PM<BR><B>To:</B> Steve Cipolli; megaco@ietf.org<BR><B>Subject:</B> RE: 
  [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers ( L), &amp; Short 
  T imers (S)<BR><BR></FONT></DIV>
  <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
  class=931160822-01122003>Your interpretation is correct.&nbsp; <SPAN 
  class=931160822-01122003>Because Z changes how a digit is matched, it makes 
  sense within a range.&nbsp; Think of Z as part of the digit it modifies, 
  rather than a separate symbol.</SPAN></SPAN></FONT></DIV>
  <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
  class=931160822-01122003></SPAN></FONT>&nbsp;</DIV>
  <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
  class=931160822-01122003>The L and S timers within a digitmap give specific 
  instruction as to which timer to run at that point in the digitmap.&nbsp; 
  While allowed in a range, I don't think they provide much value within a range 
  since they do not actually match anything.&nbsp; For effective use, they 
  should be outside the range.</SPAN></FONT></DIV>
  <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
  class=931160822-01122003></SPAN></FONT>&nbsp;</DIV>
  <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
  class=931160822-01122003>Kevin</SPAN></FONT></DIV><BR>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
    <HR tabIndex=-1>
    <FONT face=Tahoma size=2><B>From:</B> Steve Cipolli 
    [mailto:SCipolli@radvision.com] <BR><B>Sent:</B> Monday, December 01, 2003 
    3:26 PM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco] Digit 
    Maps: Long Duration Modifier(Z), Long Timers (L), &amp; Short T imers 
    (S)<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial size=2>According to the 
    syntax in RFCs 3015 &amp; 3525 the long duration modifier (Z), Long Timers 
    (L), &amp; Short Timers (S) in digit maps can appear in a digit range.&nbsp; 
    For example (where Z is 1000ms):</FONT></SPAN></DIV>
    <DIV><SPAN class=695380620-01122003>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
    size=2>"135[2Z46]"</FONT></SPAN></DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial size=2>Is this 
    valid?&nbsp; If it is valid, does this mean that the fourth digit event must 
    be either 2, 6 (held for any duration) or 4 held for 1000 
    ms?</FONT></SPAN></DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial size=2>How does long 
    timer (L) and short timer (S) in a digit range apply?</FONT></SPAN></DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial 
    size=2>--Stephen</FONT></SPAN></DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3B859.911F8CF0--


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


From exim@www1.ietf.org  Mon Dec  1 17:23:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06158
	for <megaco-archive@odin.ietf.org>; Mon, 1 Dec 2003 17:23:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwRe-0007RC-6I
	for megaco-archive@odin.ietf.org; Mon, 01 Dec 2003 17:23:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1MN6xX028584
	for megaco-archive@odin.ietf.org; Mon, 1 Dec 2003 17:23:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwRd-0007Qx-Ul
	for megaco-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 17:23:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06089
	for <megaco-web-archive@ietf.org>; Mon, 1 Dec 2003 17:22:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwRb-0003kw-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 17:23:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwRb-0003kt-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 17:23:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwRZ-0007Pp-NX; Mon, 01 Dec 2003 17:23:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwR0-0007Mn-PS
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 17:22:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06023
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:22:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwQy-0003jH-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:22:24 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwQx-0003j9-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:22:24 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Mon, 1 Dec 2003 17:22:13 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZSSQC>; Mon, 1 Dec 2003 17:22:13 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B09ED@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>, megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 	L), & Short T imers (S)
Date: Mon, 1 Dec 2003 17:22:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B859.911F8CF0"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3B859.911F8CF0
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks for the feedback.  
 
Just to make sure I understand the L and S cases:
They are syntactically legal in a range specification, but semantically they
have no effect.  Correct?
 
--Stephen

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, December 01, 2003 5:15 PM
To: Steve Cipolli; megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


Your interpretation is correct.  Because Z changes how a digit is matched,
it makes sense within a range.  Think of Z as part of the digit it modifies,
rather than a separate symbol.
 
The L and S timers within a digitmap give specific instruction as to which
timer to run at that point in the digitmap.  While allowed in a range, I
don't think they provide much value within a range since they do not
actually match anything.  For effective use, they should be outside the
range.
 
Kevin


  _____  

From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Monday, December 01, 2003 3:26 PM
To: megaco@ietf.org
Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (L), &
Short T imers (S)


 
According to the syntax in RFCs 3015 & 3525 the long duration modifier (Z),
Long Timers (L), & Short Timers (S) in digit maps can appear in a digit
range.  For example (where Z is 1000ms):
    "135[2Z46]"
 
Is this valid?  If it is valid, does this mean that the fourth digit event
must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
 
How does long timer (L) and short timer (S) in a digit range apply?
 
--Stephen
 
 


------_=_NextPart_001_01C3B859.911F8CF0
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">


<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=406151822-01122003>Thanks 
for the feedback.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=406151822-01122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=406151822-01122003>Just 
to make sure I understand the L and S cases:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=406151822-01122003>They 
are syntactically legal in a range specification, but semantically they have no 
effect.&nbsp; Correct?</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=406151822-01122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=406151822-01122003>--Stephen</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; 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> Monday, December 01, 2003 
  5:15 PM<BR><B>To:</B> Steve Cipolli; megaco@ietf.org<BR><B>Subject:</B> RE: 
  [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers ( L), &amp; Short 
  T imers (S)<BR><BR></FONT></DIV>
  <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
  class=931160822-01122003>Your interpretation is correct.&nbsp; <SPAN 
  class=931160822-01122003>Because Z changes how a digit is matched, it makes 
  sense within a range.&nbsp; Think of Z as part of the digit it modifies, 
  rather than a separate symbol.</SPAN></SPAN></FONT></DIV>
  <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
  class=931160822-01122003></SPAN></FONT>&nbsp;</DIV>
  <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
  class=931160822-01122003>The L and S timers within a digitmap give specific 
  instruction as to which timer to run at that point in the digitmap.&nbsp; 
  While allowed in a range, I don't think they provide much value within a range 
  since they do not actually match anything.&nbsp; For effective use, they 
  should be outside the range.</SPAN></FONT></DIV>
  <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
  class=931160822-01122003></SPAN></FONT>&nbsp;</DIV>
  <DIV dir=ltr align=left><FONT face=Arial size=2><SPAN 
  class=931160822-01122003>Kevin</SPAN></FONT></DIV><BR>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
    <HR tabIndex=-1>
    <FONT face=Tahoma size=2><B>From:</B> Steve Cipolli 
    [mailto:SCipolli@radvision.com] <BR><B>Sent:</B> Monday, December 01, 2003 
    3:26 PM<BR><B>To:</B> megaco@ietf.org<BR><B>Subject:</B> [Megaco] Digit 
    Maps: Long Duration Modifier(Z), Long Timers (L), &amp; Short T imers 
    (S)<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial size=2>According to the 
    syntax in RFCs 3015 &amp; 3525 the long duration modifier (Z), Long Timers 
    (L), &amp; Short Timers (S) in digit maps can appear in a digit range.&nbsp; 
    For example (where Z is 1000ms):</FONT></SPAN></DIV>
    <DIV><SPAN class=695380620-01122003>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
    size=2>"135[2Z46]"</FONT></SPAN></DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial size=2>Is this 
    valid?&nbsp; If it is valid, does this mean that the fourth digit event must 
    be either 2, 6 (held for any duration) or 4 held for 1000 
    ms?</FONT></SPAN></DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial size=2>How does long 
    timer (L) and short timer (S) in a digit range apply?</FONT></SPAN></DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial 
    size=2>--Stephen</FONT></SPAN></DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=695380620-01122003><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3B859.911F8CF0--


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



From megaco-admin@ietf.org  Mon Dec  1 17:30:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06849
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 17:30:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwYM-0007hT-3o; Mon, 01 Dec 2003 17:30:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwXc-0007f8-7E
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 17:29:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06818
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:29:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwXZ-00041q-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:29:13 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwXY-000411-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:29:12 -0500
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 hB1MSfc01775
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:28:41 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <WTQH9QQ2>; Mon, 1 Dec 2003 17:28:41 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0CF02FA7@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Steve Cipolli <SCipolli@radvision.com>, megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 L), & Short T imers (S)
Date: Mon, 1 Dec 2003 17:28:41 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Since a range means "match one of these", I would agree with the assessment
that L and S are meaningless within a range.
 
Kevin


  _____  

From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Monday, December 01, 2003 5:22 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


Thanks for the feedback.  
 
Just to make sure I understand the L and S cases:
They are syntactically legal in a range specification, but semantically they
have no effect.  Correct?
 
--Stephen

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, December 01, 2003 5:15 PM
To: Steve Cipolli; megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


Your interpretation is correct.  Because Z changes how a digit is matched,
it makes sense within a range.  Think of Z as part of the digit it modifies,
rather than a separate symbol.
 
The L and S timers within a digitmap give specific instruction as to which
timer to run at that point in the digitmap.  While allowed in a range, I
don't think they provide much value within a range since they do not
actually match anything.  For effective use, they should be outside the
range.
 
Kevin


  _____  

From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Monday, December 01, 2003 3:26 PM
To: megaco@ietf.org
Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (L), &
Short T imers (S)


 
According to the syntax in RFCs 3015 & 3525 the long duration modifier (Z),
Long Timers (L), & Short Timers (S) in digit maps can appear in a digit
range.  For example (where Z is 1000ms):
    "135[2Z46]"
 
Is this valid?  If it is valid, does this mean that the fourth digit event
must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
 
How does long timer (L) and short timer (S) in a digit range apply?
 
--Stephen
 
 


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


From exim@www1.ietf.org  Mon Dec  1 17:30:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06864
	for <megaco-archive@odin.ietf.org>; Mon, 1 Dec 2003 17:30:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwYP-0007is-36
	for megaco-archive@odin.ietf.org; Mon, 01 Dec 2003 17:30:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1MU5pX029680
	for megaco-archive@odin.ietf.org; Mon, 1 Dec 2003 17:30:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwYO-0007id-Uq
	for megaco-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 17:30:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06839
	for <megaco-web-archive@ietf.org>; Mon, 1 Dec 2003 17:29:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwYM-00042E-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 17:30:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwYL-00042B-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 17:30:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwYM-0007hT-3o; Mon, 01 Dec 2003 17:30:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQwXc-0007f8-7E
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 17:29:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06818
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:29:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwXZ-00041q-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:29:13 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQwXY-000411-00
	for megaco@ietf.org; Mon, 01 Dec 2003 17:29:12 -0500
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 hB1MSfc01775
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:28:41 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <WTQH9QQ2>; Mon, 1 Dec 2003 17:28:41 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0CF02FA7@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Steve Cipolli <SCipolli@radvision.com>, megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 L), & Short T imers (S)
Date: Mon, 1 Dec 2003 17:28:41 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Since a range means "match one of these", I would agree with the assessment
that L and S are meaningless within a range.
 
Kevin


  _____  

From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Monday, December 01, 2003 5:22 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


Thanks for the feedback.  
 
Just to make sure I understand the L and S cases:
They are syntactically legal in a range specification, but semantically they
have no effect.  Correct?
 
--Stephen

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Monday, December 01, 2003 5:15 PM
To: Steve Cipolli; megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)


Your interpretation is correct.  Because Z changes how a digit is matched,
it makes sense within a range.  Think of Z as part of the digit it modifies,
rather than a separate symbol.
 
The L and S timers within a digitmap give specific instruction as to which
timer to run at that point in the digitmap.  While allowed in a range, I
don't think they provide much value within a range since they do not
actually match anything.  For effective use, they should be outside the
range.
 
Kevin


  _____  

From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Monday, December 01, 2003 3:26 PM
To: megaco@ietf.org
Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (L), &
Short T imers (S)


 
According to the syntax in RFCs 3015 & 3525 the long duration modifier (Z),
Long Timers (L), & Short Timers (S) in digit maps can appear in a digit
range.  For example (where Z is 1000ms):
    "135[2Z46]"
 
Is this valid?  If it is valid, does this mean that the fourth digit event
must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
 
How does long timer (L) and short timer (S) in a digit range apply?
 
--Stephen
 
 


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



From megaco-admin@ietf.org  Mon Dec  1 18:33:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11500
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 18:33:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQxXJ-0003CR-D2; Mon, 01 Dec 2003 18:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQxX9-0003Bh-1f
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 18:32:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11369
	for <megaco@ietf.org>; Mon, 1 Dec 2003 18:32:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQxX6-0005Pr-00
	for megaco@ietf.org; Mon, 01 Dec 2003 18:32:48 -0500
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQxX5-0005PL-00
	for megaco@ietf.org; Mon, 01 Dec 2003 18:32:47 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB1NVT420510
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:31:41 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id SAA05361; Mon, 1 Dec 2003 18:31:38 -0500 (EST)
Cc: megaco@ietf.org
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id SAA05352; Mon, 1 Dec 2003 18:31:37 -0500 (EST)
Message-ID: <3FCBCFB7.8060602@bell-labs.com>
Date: Mon, 01 Dec 2003 18:33:11 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
Original-CC: megaco@ietf.org
Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
  L), & Short T imers (S)
References: <ABA227A15B80D511BD1A00508BF93A1C0CF02FA7@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0CF02FA7@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit



I disagree that "L" and "S" are meaningless within a range.

"L" and "S" are used to specify the timer used for "subsequent events".

I would argue that the "5" is a subsequent event in
"[34L]5", just as it is in "[34]L5".

I would also argue that the "4" in "[3L4]5" is NOT a "subsequent event",
although one might debate the definition of "subsequent".

In summary, I think "[L34]5", "[3L4]5", "[34L]5", and "[34]L5" are all
the same. (And the "L" is not meaningless.)


Note that section 7.1.14.3 does bother to specify what happens when explicit
timing specifiers are only active in some "alternatives", or when they
differ in among alternatives -- the same timer value is used for all
alternatives.


7.1.14.3:

 > In addition to these event symbols, the string may contain "S" and "L"
 > inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
 > respectively indicate that the MG should use the short (S) timer or the
 > long (L) timer for subsequent events, overriding the timing rules
 > described above. If an explicit timing specifier is in effect in one
 > alternative event sequence, but none is given in any other candidate
 > alternative, the timer value set by the explicit timing specifier must be
 > used. If all sequences with explicit timing controls are dropped from the
 > candidate set, timing reverts to the default rules given above. Finally,
 > if conflicting timing specifiers are in effect in different alternative
 > sequences, the long timer shall be used.


-troy



Kevin Boyle wrote:

> Since a range means "match one of these", I would agree with the assessment
> that L and S are meaningless within a range.
>  
> Kevin
> 
> 
>   _____  
> 
> From: Steve Cipolli [mailto:SCipolli@radvision.com] 
> Sent: Monday, December 01, 2003 5:22 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
> Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
> L), & Short T imers (S)
> 
> 
> Thanks for the feedback.  
>  
> Just to make sure I understand the L and S cases:
> They are syntactically legal in a range specification, but semantically they
> have no effect.  Correct?
>  
> --Stephen
> 
> -----Original Message-----
> From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
> Sent: Monday, December 01, 2003 5:15 PM
> To: Steve Cipolli; megaco@ietf.org
> Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
> L), & Short T imers (S)
> 
> 
> Your interpretation is correct.  Because Z changes how a digit is matched,
> it makes sense within a range.  Think of Z as part of the digit it modifies,
> rather than a separate symbol.
>  
> The L and S timers within a digitmap give specific instruction as to which
> timer to run at that point in the digitmap.  While allowed in a range, I
> don't think they provide much value within a range since they do not
> actually match anything.  For effective use, they should be outside the
> range.
>  
> Kevin
> 
> 
>   _____  
> 
> From: Steve Cipolli [mailto:SCipolli@radvision.com] 
> Sent: Monday, December 01, 2003 3:26 PM
> To: megaco@ietf.org
> Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (L), &
> Short T imers (S)
> 
> 
>  
> According to the syntax in RFCs 3015 & 3525 the long duration modifier (Z),
> Long Timers (L), & Short Timers (S) in digit maps can appear in a digit
> range.  For example (where Z is 1000ms):
>     "135[2Z46]"
>  
> Is this valid?  If it is valid, does this mean that the fourth digit event
> must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
>  
> How does long timer (L) and short timer (S) in a digit range apply?
>  
> --Stephen
>  
>  
> 
> 
> _______________________________________________
> 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 exim@www1.ietf.org  Mon Dec  1 18:33:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11519
	for <megaco-archive@odin.ietf.org>; Mon, 1 Dec 2003 18:33:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQxXU-0003ED-0K
	for megaco-archive@odin.ietf.org; Mon, 01 Dec 2003 18:33:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1NXBMH012408
	for megaco-archive@odin.ietf.org; Mon, 1 Dec 2003 18:33:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQxXT-0003E3-TF
	for megaco-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 18:33:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11434
	for <megaco-web-archive@ietf.org>; Mon, 1 Dec 2003 18:32:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQxXQ-0005RN-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 18:33:08 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQxXQ-0005RJ-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 18:33:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQxXJ-0003CR-D2; Mon, 01 Dec 2003 18:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQxX9-0003Bh-1f
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 18:32:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11369
	for <megaco@ietf.org>; Mon, 1 Dec 2003 18:32:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQxX6-0005Pr-00
	for megaco@ietf.org; Mon, 01 Dec 2003 18:32:48 -0500
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQxX5-0005PL-00
	for megaco@ietf.org; Mon, 01 Dec 2003 18:32:47 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB1NVT420510
	for <megaco@ietf.org>; Mon, 1 Dec 2003 17:31:41 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id SAA05361; Mon, 1 Dec 2003 18:31:38 -0500 (EST)
Cc: megaco@ietf.org
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id SAA05352; Mon, 1 Dec 2003 18:31:37 -0500 (EST)
Message-ID: <3FCBCFB7.8060602@bell-labs.com>
Date: Mon, 01 Dec 2003 18:33:11 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
Original-CC: megaco@ietf.org
Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
  L), & Short T imers (S)
References: <ABA227A15B80D511BD1A00508BF93A1C0CF02FA7@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0CF02FA7@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



I disagree that "L" and "S" are meaningless within a range.

"L" and "S" are used to specify the timer used for "subsequent events".

I would argue that the "5" is a subsequent event in
"[34L]5", just as it is in "[34]L5".

I would also argue that the "4" in "[3L4]5" is NOT a "subsequent event",
although one might debate the definition of "subsequent".

In summary, I think "[L34]5", "[3L4]5", "[34L]5", and "[34]L5" are all
the same. (And the "L" is not meaningless.)


Note that section 7.1.14.3 does bother to specify what happens when explicit
timing specifiers are only active in some "alternatives", or when they
differ in among alternatives -- the same timer value is used for all
alternatives.


7.1.14.3:

 > In addition to these event symbols, the string may contain "S" and "L"
 > inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
 > respectively indicate that the MG should use the short (S) timer or the
 > long (L) timer for subsequent events, overriding the timing rules
 > described above. If an explicit timing specifier is in effect in one
 > alternative event sequence, but none is given in any other candidate
 > alternative, the timer value set by the explicit timing specifier must be
 > used. If all sequences with explicit timing controls are dropped from the
 > candidate set, timing reverts to the default rules given above. Finally,
 > if conflicting timing specifiers are in effect in different alternative
 > sequences, the long timer shall be used.


-troy



Kevin Boyle wrote:

> Since a range means "match one of these", I would agree with the assessment
> that L and S are meaningless within a range.
>  
> Kevin
> 
> 
>   _____  
> 
> From: Steve Cipolli [mailto:SCipolli@radvision.com] 
> Sent: Monday, December 01, 2003 5:22 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
> Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
> L), & Short T imers (S)
> 
> 
> Thanks for the feedback.  
>  
> Just to make sure I understand the L and S cases:
> They are syntactically legal in a range specification, but semantically they
> have no effect.  Correct?
>  
> --Stephen
> 
> -----Original Message-----
> From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
> Sent: Monday, December 01, 2003 5:15 PM
> To: Steve Cipolli; megaco@ietf.org
> Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
> L), & Short T imers (S)
> 
> 
> Your interpretation is correct.  Because Z changes how a digit is matched,
> it makes sense within a range.  Think of Z as part of the digit it modifies,
> rather than a separate symbol.
>  
> The L and S timers within a digitmap give specific instruction as to which
> timer to run at that point in the digitmap.  While allowed in a range, I
> don't think they provide much value within a range since they do not
> actually match anything.  For effective use, they should be outside the
> range.
>  
> Kevin
> 
> 
>   _____  
> 
> From: Steve Cipolli [mailto:SCipolli@radvision.com] 
> Sent: Monday, December 01, 2003 3:26 PM
> To: megaco@ietf.org
> Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (L), &
> Short T imers (S)
> 
> 
>  
> According to the syntax in RFCs 3015 & 3525 the long duration modifier (Z),
> Long Timers (L), & Short Timers (S) in digit maps can appear in a digit
> range.  For example (where Z is 1000ms):
>     "135[2Z46]"
>  
> Is this valid?  If it is valid, does this mean that the fourth digit event
> must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
>  
> How does long timer (L) and short timer (S) in a digit range apply?
>  
> --Stephen
>  
>  
> 
> 
> _______________________________________________
> 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-admin@ietf.org  Mon Dec  1 20:02:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14759
	for <megaco-archive@lists.ietf.org>; Mon, 1 Dec 2003 20:02:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQyvR-0000j1-2s; Mon, 01 Dec 2003 20:02:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQyuv-0000iT-Hq
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 20:01:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14709
	for <megaco@ietf.org>; Mon, 1 Dec 2003 20:01:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQyut-0006lQ-00
	for megaco@ietf.org; Mon, 01 Dec 2003 20:01:27 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQyut-0006lG-00
	for megaco@ietf.org; Mon, 01 Dec 2003 20:01:27 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Mon, 1 Dec 2003 20:01:18 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZSSX5>; Mon, 1 Dec 2003 20:01:17 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B09F4@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Troy Cauble'" <troy@bell-labs.com>,
        Kevin Boyle
	 <kboyle@nortelnetworks.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	   L), & Short T imers (S)
Date: Mon, 1 Dec 2003 20:01:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Part of the problem is the term "alternatives" is not clear.  The text in
7.1.14.3 says of "alternatives":
A DigitMap, according to this syntax, is defined either by a string or by a
list of strings.  Each string in the list is an alternative event sequence,
specified either as a sequence of digit map symbols or as a regular
expression of digit map symbols.

My reading of this is that "alternatives" are each string and not the
possible sequences through a range, but admittedly this is not clear. 

The section doesn't seem to explain other odd sequences like "123Z".
Presumably the "Z" is simply ignored although an error could also be
considered the proper outcome.

I must say I prefer an interpretation in which the number of possible ways
to perform the same action is as close to 1 and possible.  Therefore, I'd
prefer to ban (or at least ignore) "L" and "S" within ranges.

--Stephen

> -----Original Message-----
> From: Troy Cauble [mailto:troy@bell-labs.com]
> Sent: Monday, December 01, 2003 6:33 PM
> To: Kevin Boyle
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), 
> Long Timers
> ( L), & Short T imers (S)
> 
> 
> 
> 
> I disagree that "L" and "S" are meaningless within a range.
> 
> "L" and "S" are used to specify the timer used for 
> "subsequent events".
> 
> I would argue that the "5" is a subsequent event in
> "[34L]5", just as it is in "[34]L5".
> 
> I would also argue that the "4" in "[3L4]5" is NOT a 
> "subsequent event",
> although one might debate the definition of "subsequent".
> 
> In summary, I think "[L34]5", "[3L4]5", "[34L]5", and "[34]L5" are all
> the same. (And the "L" is not meaningless.)
> 
> 
> Note that section 7.1.14.3 does bother to specify what 
> happens when explicit
> timing specifiers are only active in some "alternatives", or when they
> differ in among alternatives -- the same timer value is used for all
> alternatives.
> 
> 
> 7.1.14.3:
> 
>  > In addition to these event symbols, the string may contain 
> "S" and "L"
>  > inter-event timing specifiers and the "Z" duration 
> modifier. "S" and "L"
>  > respectively indicate that the MG should use the short (S) 
> timer or the
>  > long (L) timer for subsequent events, overriding the timing rules
>  > described above. If an explicit timing specifier is in 
> effect in one
>  > alternative event sequence, but none is given in any other 
> candidate
>  > alternative, the timer value set by the explicit timing 
> specifier must be
>  > used. If all sequences with explicit timing controls are 
> dropped from the
>  > candidate set, timing reverts to the default rules given 
> above. Finally,
>  > if conflicting timing specifiers are in effect in 
> different alternative
>  > sequences, the long timer shall be used.
> 
> 
> -troy
> 
> 
> 
> Kevin Boyle wrote:
> 
> > Since a range means "match one of these", I would agree 
> with the assessment
> > that L and S are meaningless within a range.
> >  
> > Kevin
> > 
> > 
> >   _____  
> > 
> > From: Steve Cipolli [mailto:SCipolli@radvision.com] 
> > Sent: Monday, December 01, 2003 5:22 PM
> > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
> > Subject: RE: [Megaco] Digit Maps: Long Duration 
> Modifier(Z), Long Timers (
> > L), & Short T imers (S)
> > 
> > 
> > Thanks for the feedback.  
> >  
> > Just to make sure I understand the L and S cases:
> > They are syntactically legal in a range specification, but 
> semantically they
> > have no effect.  Correct?
> >  
> > --Stephen
> > 
> > -----Original Message-----
> > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
> > Sent: Monday, December 01, 2003 5:15 PM
> > To: Steve Cipolli; megaco@ietf.org
> > Subject: RE: [Megaco] Digit Maps: Long Duration 
> Modifier(Z), Long Timers (
> > L), & Short T imers (S)
> > 
> > 
> > Your interpretation is correct.  Because Z changes how a 
> digit is matched,
> > it makes sense within a range.  Think of Z as part of the 
> digit it modifies,
> > rather than a separate symbol.
> >  
> > The L and S timers within a digitmap give specific 
> instruction as to which
> > timer to run at that point in the digitmap.  While allowed 
> in a range, I
> > don't think they provide much value within a range since they do not
> > actually match anything.  For effective use, they should be 
> outside the
> > range.
> >  
> > Kevin
> > 
> > 
> >   _____  
> > 
> > From: Steve Cipolli [mailto:SCipolli@radvision.com] 
> > Sent: Monday, December 01, 2003 3:26 PM
> > To: megaco@ietf.org
> > Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), 
> Long Timers (L), &
> > Short T imers (S)
> > 
> > 
> >  
> > According to the syntax in RFCs 3015 & 3525 the long 
> duration modifier (Z),
> > Long Timers (L), & Short Timers (S) in digit maps can 
> appear in a digit
> > range.  For example (where Z is 1000ms):
> >     "135[2Z46]"
> >  
> > Is this valid?  If it is valid, does this mean that the 
> fourth digit event
> > must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
> >  
> > How does long timer (L) and short timer (S) in a digit range apply?
> >  
> > --Stephen
> >  
> >  
> > 
> > 
> > _______________________________________________
> > 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 exim@www1.ietf.org  Mon Dec  1 20:02:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14774
	for <megaco-archive@odin.ietf.org>; Mon, 1 Dec 2003 20:02:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQyvV-0000kj-Sd
	for megaco-archive@odin.ietf.org; Mon, 01 Dec 2003 20:02:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2125pn002887
	for megaco-archive@odin.ietf.org; Mon, 1 Dec 2003 20:02:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQyvV-0000kU-PA
	for megaco-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 20:02:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14740
	for <megaco-web-archive@ietf.org>; Mon, 1 Dec 2003 20:01:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQyvT-0006ln-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 20:02:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQyvT-0006lk-00
	for megaco-web-archive@ietf.org; Mon, 01 Dec 2003 20:02:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQyvR-0000j1-2s; Mon, 01 Dec 2003 20:02:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQyuv-0000iT-Hq
	for megaco@optimus.ietf.org; Mon, 01 Dec 2003 20:01:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14709
	for <megaco@ietf.org>; Mon, 1 Dec 2003 20:01:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQyut-0006lQ-00
	for megaco@ietf.org; Mon, 01 Dec 2003 20:01:27 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQyut-0006lG-00
	for megaco@ietf.org; Mon, 01 Dec 2003 20:01:27 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Mon, 1 Dec 2003 20:01:18 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZSSX5>; Mon, 1 Dec 2003 20:01:17 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B09F4@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Troy Cauble'" <troy@bell-labs.com>,
        Kevin Boyle
	 <kboyle@nortelnetworks.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	   L), & Short T imers (S)
Date: Mon, 1 Dec 2003 20:01:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Part of the problem is the term "alternatives" is not clear.  The text in
7.1.14.3 says of "alternatives":
A DigitMap, according to this syntax, is defined either by a string or by a
list of strings.  Each string in the list is an alternative event sequence,
specified either as a sequence of digit map symbols or as a regular
expression of digit map symbols.

My reading of this is that "alternatives" are each string and not the
possible sequences through a range, but admittedly this is not clear. 

The section doesn't seem to explain other odd sequences like "123Z".
Presumably the "Z" is simply ignored although an error could also be
considered the proper outcome.

I must say I prefer an interpretation in which the number of possible ways
to perform the same action is as close to 1 and possible.  Therefore, I'd
prefer to ban (or at least ignore) "L" and "S" within ranges.

--Stephen

> -----Original Message-----
> From: Troy Cauble [mailto:troy@bell-labs.com]
> Sent: Monday, December 01, 2003 6:33 PM
> To: Kevin Boyle
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), 
> Long Timers
> ( L), & Short T imers (S)
> 
> 
> 
> 
> I disagree that "L" and "S" are meaningless within a range.
> 
> "L" and "S" are used to specify the timer used for 
> "subsequent events".
> 
> I would argue that the "5" is a subsequent event in
> "[34L]5", just as it is in "[34]L5".
> 
> I would also argue that the "4" in "[3L4]5" is NOT a 
> "subsequent event",
> although one might debate the definition of "subsequent".
> 
> In summary, I think "[L34]5", "[3L4]5", "[34L]5", and "[34]L5" are all
> the same. (And the "L" is not meaningless.)
> 
> 
> Note that section 7.1.14.3 does bother to specify what 
> happens when explicit
> timing specifiers are only active in some "alternatives", or when they
> differ in among alternatives -- the same timer value is used for all
> alternatives.
> 
> 
> 7.1.14.3:
> 
>  > In addition to these event symbols, the string may contain 
> "S" and "L"
>  > inter-event timing specifiers and the "Z" duration 
> modifier. "S" and "L"
>  > respectively indicate that the MG should use the short (S) 
> timer or the
>  > long (L) timer for subsequent events, overriding the timing rules
>  > described above. If an explicit timing specifier is in 
> effect in one
>  > alternative event sequence, but none is given in any other 
> candidate
>  > alternative, the timer value set by the explicit timing 
> specifier must be
>  > used. If all sequences with explicit timing controls are 
> dropped from the
>  > candidate set, timing reverts to the default rules given 
> above. Finally,
>  > if conflicting timing specifiers are in effect in 
> different alternative
>  > sequences, the long timer shall be used.
> 
> 
> -troy
> 
> 
> 
> Kevin Boyle wrote:
> 
> > Since a range means "match one of these", I would agree 
> with the assessment
> > that L and S are meaningless within a range.
> >  
> > Kevin
> > 
> > 
> >   _____  
> > 
> > From: Steve Cipolli [mailto:SCipolli@radvision.com] 
> > Sent: Monday, December 01, 2003 5:22 PM
> > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
> > Subject: RE: [Megaco] Digit Maps: Long Duration 
> Modifier(Z), Long Timers (
> > L), & Short T imers (S)
> > 
> > 
> > Thanks for the feedback.  
> >  
> > Just to make sure I understand the L and S cases:
> > They are syntactically legal in a range specification, but 
> semantically they
> > have no effect.  Correct?
> >  
> > --Stephen
> > 
> > -----Original Message-----
> > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
> > Sent: Monday, December 01, 2003 5:15 PM
> > To: Steve Cipolli; megaco@ietf.org
> > Subject: RE: [Megaco] Digit Maps: Long Duration 
> Modifier(Z), Long Timers (
> > L), & Short T imers (S)
> > 
> > 
> > Your interpretation is correct.  Because Z changes how a 
> digit is matched,
> > it makes sense within a range.  Think of Z as part of the 
> digit it modifies,
> > rather than a separate symbol.
> >  
> > The L and S timers within a digitmap give specific 
> instruction as to which
> > timer to run at that point in the digitmap.  While allowed 
> in a range, I
> > don't think they provide much value within a range since they do not
> > actually match anything.  For effective use, they should be 
> outside the
> > range.
> >  
> > Kevin
> > 
> > 
> >   _____  
> > 
> > From: Steve Cipolli [mailto:SCipolli@radvision.com] 
> > Sent: Monday, December 01, 2003 3:26 PM
> > To: megaco@ietf.org
> > Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), 
> Long Timers (L), &
> > Short T imers (S)
> > 
> > 
> >  
> > According to the syntax in RFCs 3015 & 3525 the long 
> duration modifier (Z),
> > Long Timers (L), & Short Timers (S) in digit maps can 
> appear in a digit
> > range.  For example (where Z is 1000ms):
> >     "135[2Z46]"
> >  
> > Is this valid?  If it is valid, does this mean that the 
> fourth digit event
> > must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
> >  
> > How does long timer (L) and short timer (S) in a digit range apply?
> >  
> > --Stephen
> >  
> >  
> > 
> > 
> > _______________________________________________
> > 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-admin@ietf.org  Tue Dec  2 14:41:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04208
	for <megaco-archive@lists.ietf.org>; Tue, 2 Dec 2003 14:41:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARGOM-0003xK-CH; Tue, 02 Dec 2003 14:41:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARGOC-0003wu-VT
	for megaco@optimus.ietf.org; Tue, 02 Dec 2003 14:40:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04156
	for <megaco@ietf.org>; Tue, 2 Dec 2003 14:40:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARGOA-0006uA-00
	for megaco@ietf.org; Tue, 02 Dec 2003 14:40:50 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARGO9-0006u7-00
	for megaco@ietf.org; Tue, 02 Dec 2003 14:40:49 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Tue, 2 Dec 2003 14:40:35 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZS4HV>; Tue, 2 Dec 2003 14:40:35 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B09FD@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Troy Cauble'" <troy@bell-labs.com>,
        Kevin Boyle
	 <kboyle@nortelnetworks.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 	   L), & Short T imers (S)
Date: Tue, 2 Dec 2003 14:40:29 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Perhaps I moved us off track a bit.  It is clear that there is more than one
interpretation of the specification with regard to L, S, and to a lesser
extent Z.  Can the authors comment on what the intent of the specification
was and then perhaps we can reach some conclusion?

Here is a partial list of odd digitmaps that seem to defy interpretation:
	"123Z"   			- "Z" ignored or error?
	"123S"			- "S" (or "L") ignored or error?
	"1ZZ23"			- First "Z" ignored or error?
	"1ZSSSSSSSSS23"		- "Z" applied to the "2" or ignored or
error?
	"135[2Z46]"			- "Z" applied to "4" or to all in
the range (246) or ignored or error?
	"135[246Z]79"		- "Z" applied to "7" or ignored or error?
	"135[2S46]"			- "S" (or "L") applied to all in
range (246) or ignored or error?
	"135[2L4S6]"		- "L" or "S" applied or both (somehow?) or
ignored or error?

Thanks,
--Stephen

	

> -----Original Message-----
> From: Steve Cipolli [mailto:SCipolli@radvision.com]
> Sent: Monday, December 01, 2003 8:01 PM
> To: 'Troy Cauble'; Kevin Boyle
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), 
> Long Timers
> ( L), & Short T imers (S)
> 
> 
> Part of the problem is the term "alternatives" is not clear.  
> The text in
> 7.1.14.3 says of "alternatives":
> A DigitMap, according to this syntax, is defined either by a 
> string or by a
> list of strings.  Each string in the list is an alternative 
> event sequence,
> specified either as a sequence of digit map symbols or as a regular
> expression of digit map symbols.
> 
> My reading of this is that "alternatives" are each string and not the
> possible sequences through a range, but admittedly this is not clear. 
> 
> The section doesn't seem to explain other odd sequences like "123Z".
> Presumably the "Z" is simply ignored although an error could also be
> considered the proper outcome.
> 
> I must say I prefer an interpretation in which the number of 
> possible ways
> to perform the same action is as close to 1 and possible.  
> Therefore, I'd
> prefer to ban (or at least ignore) "L" and "S" within ranges.
> 
> --Stephen
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@bell-labs.com]
> > Sent: Monday, December 01, 2003 6:33 PM
> > To: Kevin Boyle
> > Cc: megaco@ietf.org
> > Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), 
> > Long Timers
> > ( L), & Short T imers (S)
> > 
> > 
> > 
> > 
> > I disagree that "L" and "S" are meaningless within a range.
> > 
> > "L" and "S" are used to specify the timer used for 
> > "subsequent events".
> > 
> > I would argue that the "5" is a subsequent event in
> > "[34L]5", just as it is in "[34]L5".
> > 
> > I would also argue that the "4" in "[3L4]5" is NOT a 
> > "subsequent event",
> > although one might debate the definition of "subsequent".
> > 
> > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and 
> "[34]L5" are all
> > the same. (And the "L" is not meaningless.)
> > 
> > 
> > Note that section 7.1.14.3 does bother to specify what 
> > happens when explicit
> > timing specifiers are only active in some "alternatives", 
> or when they
> > differ in among alternatives -- the same timer value is used for all
> > alternatives.
> > 
> > 
> > 7.1.14.3:
> > 
> >  > In addition to these event symbols, the string may contain 
> > "S" and "L"
> >  > inter-event timing specifiers and the "Z" duration 
> > modifier. "S" and "L"
> >  > respectively indicate that the MG should use the short (S) 
> > timer or the
> >  > long (L) timer for subsequent events, overriding the timing rules
> >  > described above. If an explicit timing specifier is in 
> > effect in one
> >  > alternative event sequence, but none is given in any other 
> > candidate
> >  > alternative, the timer value set by the explicit timing 
> > specifier must be
> >  > used. If all sequences with explicit timing controls are 
> > dropped from the
> >  > candidate set, timing reverts to the default rules given 
> > above. Finally,
> >  > if conflicting timing specifiers are in effect in 
> > different alternative
> >  > sequences, the long timer shall be used.
> > 
> > 
> > -troy
> > 
> > 
> > 
> > Kevin Boyle wrote:
> > 
> > > Since a range means "match one of these", I would agree 
> > with the assessment
> > > that L and S are meaningless within a range.
> > >  
> > > Kevin
> > > 
> > > 
> > >   _____  
> > > 
> > > From: Steve Cipolli [mailto:SCipolli@radvision.com] 
> > > Sent: Monday, December 01, 2003 5:22 PM
> > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
> > > Subject: RE: [Megaco] Digit Maps: Long Duration 
> > Modifier(Z), Long Timers (
> > > L), & Short T imers (S)
> > > 
> > > 
> > > Thanks for the feedback.  
> > >  
> > > Just to make sure I understand the L and S cases:
> > > They are syntactically legal in a range specification, but 
> > semantically they
> > > have no effect.  Correct?
> > >  
> > > --Stephen
> > > 
> > > -----Original Message-----
> > > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
> > > Sent: Monday, December 01, 2003 5:15 PM
> > > To: Steve Cipolli; megaco@ietf.org
> > > Subject: RE: [Megaco] Digit Maps: Long Duration 
> > Modifier(Z), Long Timers (
> > > L), & Short T imers (S)
> > > 
> > > 
> > > Your interpretation is correct.  Because Z changes how a 
> > digit is matched,
> > > it makes sense within a range.  Think of Z as part of the 
> > digit it modifies,
> > > rather than a separate symbol.
> > >  
> > > The L and S timers within a digitmap give specific 
> > instruction as to which
> > > timer to run at that point in the digitmap.  While allowed 
> > in a range, I
> > > don't think they provide much value within a range since 
> they do not
> > > actually match anything.  For effective use, they should be 
> > outside the
> > > range.
> > >  
> > > Kevin
> > > 
> > > 
> > >   _____  
> > > 
> > > From: Steve Cipolli [mailto:SCipolli@radvision.com] 
> > > Sent: Monday, December 01, 2003 3:26 PM
> > > To: megaco@ietf.org
> > > Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), 
> > Long Timers (L), &
> > > Short T imers (S)
> > > 
> > > 
> > >  
> > > According to the syntax in RFCs 3015 & 3525 the long 
> > duration modifier (Z),
> > > Long Timers (L), & Short Timers (S) in digit maps can 
> > appear in a digit
> > > range.  For example (where Z is 1000ms):
> > >     "135[2Z46]"
> > >  
> > > Is this valid?  If it is valid, does this mean that the 
> > fourth digit event
> > > must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
> > >  
> > > How does long timer (L) and short timer (S) in a digit 
> range apply?
> > >  
> > > --Stephen
> > >  
> > >  
> > > 
> > > 
> > > _______________________________________________
> > > 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 exim@www1.ietf.org  Tue Dec  2 14:41:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04223
	for <megaco-archive@odin.ietf.org>; Tue, 2 Dec 2003 14:41:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARGOR-0003yI-KJ
	for megaco-archive@odin.ietf.org; Tue, 02 Dec 2003 14:41:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Jf7GG015263
	for megaco-archive@odin.ietf.org; Tue, 2 Dec 2003 14:41:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARGOR-0003y6-FQ
	for megaco-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 14:41:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04175
	for <megaco-web-archive@ietf.org>; Tue, 2 Dec 2003 14:40:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARGOO-0006uf-00
	for megaco-web-archive@ietf.org; Tue, 02 Dec 2003 14:41:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARGOO-0006ub-00
	for megaco-web-archive@ietf.org; Tue, 02 Dec 2003 14:41:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARGOM-0003xK-CH; Tue, 02 Dec 2003 14:41:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARGOC-0003wu-VT
	for megaco@optimus.ietf.org; Tue, 02 Dec 2003 14:40:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04156
	for <megaco@ietf.org>; Tue, 2 Dec 2003 14:40:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARGOA-0006uA-00
	for megaco@ietf.org; Tue, 02 Dec 2003 14:40:50 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARGO9-0006u7-00
	for megaco@ietf.org; Tue, 02 Dec 2003 14:40:49 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Tue, 2 Dec 2003 14:40:35 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZS4HV>; Tue, 2 Dec 2003 14:40:35 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B09FD@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Troy Cauble'" <troy@bell-labs.com>,
        Kevin Boyle
	 <kboyle@nortelnetworks.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 	   L), & Short T imers (S)
Date: Tue, 2 Dec 2003 14:40:29 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Perhaps I moved us off track a bit.  It is clear that there is more than one
interpretation of the specification with regard to L, S, and to a lesser
extent Z.  Can the authors comment on what the intent of the specification
was and then perhaps we can reach some conclusion?

Here is a partial list of odd digitmaps that seem to defy interpretation:
	"123Z"   			- "Z" ignored or error?
	"123S"			- "S" (or "L") ignored or error?
	"1ZZ23"			- First "Z" ignored or error?
	"1ZSSSSSSSSS23"		- "Z" applied to the "2" or ignored or
error?
	"135[2Z46]"			- "Z" applied to "4" or to all in
the range (246) or ignored or error?
	"135[246Z]79"		- "Z" applied to "7" or ignored or error?
	"135[2S46]"			- "S" (or "L") applied to all in
range (246) or ignored or error?
	"135[2L4S6]"		- "L" or "S" applied or both (somehow?) or
ignored or error?

Thanks,
--Stephen

	

> -----Original Message-----
> From: Steve Cipolli [mailto:SCipolli@radvision.com]
> Sent: Monday, December 01, 2003 8:01 PM
> To: 'Troy Cauble'; Kevin Boyle
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), 
> Long Timers
> ( L), & Short T imers (S)
> 
> 
> Part of the problem is the term "alternatives" is not clear.  
> The text in
> 7.1.14.3 says of "alternatives":
> A DigitMap, according to this syntax, is defined either by a 
> string or by a
> list of strings.  Each string in the list is an alternative 
> event sequence,
> specified either as a sequence of digit map symbols or as a regular
> expression of digit map symbols.
> 
> My reading of this is that "alternatives" are each string and not the
> possible sequences through a range, but admittedly this is not clear. 
> 
> The section doesn't seem to explain other odd sequences like "123Z".
> Presumably the "Z" is simply ignored although an error could also be
> considered the proper outcome.
> 
> I must say I prefer an interpretation in which the number of 
> possible ways
> to perform the same action is as close to 1 and possible.  
> Therefore, I'd
> prefer to ban (or at least ignore) "L" and "S" within ranges.
> 
> --Stephen
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@bell-labs.com]
> > Sent: Monday, December 01, 2003 6:33 PM
> > To: Kevin Boyle
> > Cc: megaco@ietf.org
> > Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), 
> > Long Timers
> > ( L), & Short T imers (S)
> > 
> > 
> > 
> > 
> > I disagree that "L" and "S" are meaningless within a range.
> > 
> > "L" and "S" are used to specify the timer used for 
> > "subsequent events".
> > 
> > I would argue that the "5" is a subsequent event in
> > "[34L]5", just as it is in "[34]L5".
> > 
> > I would also argue that the "4" in "[3L4]5" is NOT a 
> > "subsequent event",
> > although one might debate the definition of "subsequent".
> > 
> > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and 
> "[34]L5" are all
> > the same. (And the "L" is not meaningless.)
> > 
> > 
> > Note that section 7.1.14.3 does bother to specify what 
> > happens when explicit
> > timing specifiers are only active in some "alternatives", 
> or when they
> > differ in among alternatives -- the same timer value is used for all
> > alternatives.
> > 
> > 
> > 7.1.14.3:
> > 
> >  > In addition to these event symbols, the string may contain 
> > "S" and "L"
> >  > inter-event timing specifiers and the "Z" duration 
> > modifier. "S" and "L"
> >  > respectively indicate that the MG should use the short (S) 
> > timer or the
> >  > long (L) timer for subsequent events, overriding the timing rules
> >  > described above. If an explicit timing specifier is in 
> > effect in one
> >  > alternative event sequence, but none is given in any other 
> > candidate
> >  > alternative, the timer value set by the explicit timing 
> > specifier must be
> >  > used. If all sequences with explicit timing controls are 
> > dropped from the
> >  > candidate set, timing reverts to the default rules given 
> > above. Finally,
> >  > if conflicting timing specifiers are in effect in 
> > different alternative
> >  > sequences, the long timer shall be used.
> > 
> > 
> > -troy
> > 
> > 
> > 
> > Kevin Boyle wrote:
> > 
> > > Since a range means "match one of these", I would agree 
> > with the assessment
> > > that L and S are meaningless within a range.
> > >  
> > > Kevin
> > > 
> > > 
> > >   _____  
> > > 
> > > From: Steve Cipolli [mailto:SCipolli@radvision.com] 
> > > Sent: Monday, December 01, 2003 5:22 PM
> > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
> > > Subject: RE: [Megaco] Digit Maps: Long Duration 
> > Modifier(Z), Long Timers (
> > > L), & Short T imers (S)
> > > 
> > > 
> > > Thanks for the feedback.  
> > >  
> > > Just to make sure I understand the L and S cases:
> > > They are syntactically legal in a range specification, but 
> > semantically they
> > > have no effect.  Correct?
> > >  
> > > --Stephen
> > > 
> > > -----Original Message-----
> > > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
> > > Sent: Monday, December 01, 2003 5:15 PM
> > > To: Steve Cipolli; megaco@ietf.org
> > > Subject: RE: [Megaco] Digit Maps: Long Duration 
> > Modifier(Z), Long Timers (
> > > L), & Short T imers (S)
> > > 
> > > 
> > > Your interpretation is correct.  Because Z changes how a 
> > digit is matched,
> > > it makes sense within a range.  Think of Z as part of the 
> > digit it modifies,
> > > rather than a separate symbol.
> > >  
> > > The L and S timers within a digitmap give specific 
> > instruction as to which
> > > timer to run at that point in the digitmap.  While allowed 
> > in a range, I
> > > don't think they provide much value within a range since 
> they do not
> > > actually match anything.  For effective use, they should be 
> > outside the
> > > range.
> > >  
> > > Kevin
> > > 
> > > 
> > >   _____  
> > > 
> > > From: Steve Cipolli [mailto:SCipolli@radvision.com] 
> > > Sent: Monday, December 01, 2003 3:26 PM
> > > To: megaco@ietf.org
> > > Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), 
> > Long Timers (L), &
> > > Short T imers (S)
> > > 
> > > 
> > >  
> > > According to the syntax in RFCs 3015 & 3525 the long 
> > duration modifier (Z),
> > > Long Timers (L), & Short Timers (S) in digit maps can 
> > appear in a digit
> > > range.  For example (where Z is 1000ms):
> > >     "135[2Z46]"
> > >  
> > > Is this valid?  If it is valid, does this mean that the 
> > fourth digit event
> > > must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
> > >  
> > > How does long timer (L) and short timer (S) in a digit 
> range apply?
> > >  
> > > --Stephen
> > >  
> > >  
> > > 
> > > 
> > > _______________________________________________
> > > 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-admin@ietf.org  Tue Dec  2 15:19:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07594
	for <megaco-archive@lists.ietf.org>; Tue, 2 Dec 2003 15:19:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARGz6-00063H-K0; Tue, 02 Dec 2003 15:19:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARGz4-00062m-CI
	for megaco@optimus.ietf.org; Tue, 02 Dec 2003 15:18:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07564
	for <megaco@ietf.org>; Tue, 2 Dec 2003 15:18:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARGz3-0007kA-00
	for megaco@ietf.org; Tue, 02 Dec 2003 15:18:57 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARGz2-0007jQ-00
	for megaco@ietf.org; Tue, 02 Dec 2003 15:18:56 -0500
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 hB2KIP712016
	for <megaco@ietf.org>; Tue, 2 Dec 2003 15:18:25 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <WTQH0DBJ>; Tue, 2 Dec 2003 15:18:21 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0CF4F290@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Steve Cipolli <SCipolli@radvision.com>,
        "'Troy Cauble'"
	 <troy@bell-labs.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 L), & Short T imers (S)
Date: Tue, 2 Dec 2003 15:18:11 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Comments inline. [KJBII]

Kevin 

-----Original Message-----
From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Tuesday, December 02, 2003 2:40 PM
To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)

Perhaps I moved us off track a bit.  It is clear that there is more than one
interpretation of the specification with regard to L, S, and to a lesser
extent Z.  Can the authors comment on what the intent of the specification
was and then perhaps we can reach some conclusion?

Here is a partial list of odd digitmaps that seem to defy interpretation:
	"123Z"   			- "Z" ignored or error?
[KJBII] Z here has nothing to modify.  Error.

	"123S"			- "S" (or "L") ignored or error?
[KJBII] In this instance, the digitmap switches to short interdigit timing
after detecting "123".  So, neither.

	"1ZZ23"			- First "Z" ignored or error?
[KJBII] Because Z is defined as modifying the following digit, and Z cannot
modify Z, this should be an error.

	"1ZSSSSSSSSS23"		- "Z" applied to the "2" or ignored or
error?
[KJBII] See above.  Error as Z cannot modify S (or L).

	"135[2Z46]"			- "Z" applied to "4" or to all in
the range (246) or ignored or error?
[KJBII] Z applies solely to the 4 here.

	"135[246Z]79"		- "Z" applied to "7" or ignored or error?
[KJBII] Nothing for Z to modify.  Error.

	"135[2S46]"			- "S" (or "L") applied to all in
range (246) or ignored or error?
[KJBII] This is the root of our earlier discussion.  L and S do not modify
digits -- they modify timing strategy for the digitmap at the time they are
encountered.  [246] means "match 2, 4 or 6".  So [2S46] means... What
exactly? "Match 2, short timeout, 4 or 6"?  Or "match 2, 4 or 6 while
running the short timer for this digit only"?  Or "run the short timer S
after detecting 2, but not if 4 or 6 is detected"?  If the string were
"135S[246]" then we would start using the short timer before looking for 2,
4 or 6.  If it were "135[246]S", we would start using the short timer AFTER
matching 2, 4 or 6.  But, with the S timer INSIDE the range, that would
indicate that the timer would have to fire to continue.  For instance, if
the string were "135[2S46]79", that would seem to indicate that if NO digit
was detected for the duration of the short timer, then we should continue
with the string to find 7.  This is a contrary usage to S and L at any other
point in a digitmap.  I think S and L should be ignored within ranges.  If
the MGC wants to use the S or L timer, then put them outside the range.

	"135[2L4S6]"		- "L" or "S" applied or both (somehow?) or
ignored or error?
[KJBII] See above -- the same arguments apply here.  I would note that L
would never get "detected" here, since S would match first.

Thanks,
--Stephen

	

> -----Original Message-----
> From: Steve Cipolli [mailto:SCipolli@radvision.com]
> Sent: Monday, December 01, 2003 8:01 PM
> To: 'Troy Cauble'; Kevin Boyle
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
> Timers ( L), & Short T imers (S)
> 
> 
> Part of the problem is the term "alternatives" is not clear.  
> The text in
> 7.1.14.3 says of "alternatives":
> A DigitMap, according to this syntax, is defined either by a string or 
> by a list of strings.  Each string in the list is an alternative event 
> sequence, specified either as a sequence of digit map symbols or as a 
> regular expression of digit map symbols.
> 
> My reading of this is that "alternatives" are each string and not the 
> possible sequences through a range, but admittedly this is not clear.
> 
> The section doesn't seem to explain other odd sequences like "123Z".
> Presumably the "Z" is simply ignored although an error could also be 
> considered the proper outcome.
> 
> I must say I prefer an interpretation in which the number of possible 
> ways to perform the same action is as close to 1 and possible.
> Therefore, I'd
> prefer to ban (or at least ignore) "L" and "S" within ranges.
> 
> --Stephen
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@bell-labs.com]
> > Sent: Monday, December 01, 2003 6:33 PM
> > To: Kevin Boyle
> > Cc: megaco@ietf.org
> > Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
> > Timers ( L), & Short T imers (S)
> > 
> > 
> > 
> > 
> > I disagree that "L" and "S" are meaningless within a range.
> > 
> > "L" and "S" are used to specify the timer used for "subsequent 
> > events".
> > 
> > I would argue that the "5" is a subsequent event in "[34L]5", just 
> > as it is in "[34]L5".
> > 
> > I would also argue that the "4" in "[3L4]5" is NOT a "subsequent 
> > event", although one might debate the definition of "subsequent".
> > 
> > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and
> "[34]L5" are all
> > the same. (And the "L" is not meaningless.)
> > 
> > 
> > Note that section 7.1.14.3 does bother to specify what happens when 
> > explicit timing specifiers are only active in some "alternatives",
> or when they
> > differ in among alternatives -- the same timer value is used for all 
> > alternatives.
> > 
> > 
> > 7.1.14.3:
> > 
> >  > In addition to these event symbols, the string may contain "S" 
> > and "L"
> >  > inter-event timing specifiers and the "Z" duration modifier. "S" 
> > and "L"
> >  > respectively indicate that the MG should use the short (S) timer 
> > or the  > long (L) timer for subsequent events, overriding the 
> > timing rules  > described above. If an explicit timing specifier is 
> > in effect in one  > alternative event sequence, but none is given in 
> > any other candidate  > alternative, the timer value set by the 
> > explicit timing specifier must be  > used. If all sequences with 
> > explicit timing controls are dropped from the  > candidate set, 
> > timing reverts to the default rules given above. Finally,  > if 
> > conflicting timing specifiers are in effect in different alternative  
> > > sequences, the long timer shall be used.
> > 
> > 
> > -troy
> > 
> > 
> > 
> > Kevin Boyle wrote:
> > 
> > > Since a range means "match one of these", I would agree
> > with the assessment
> > > that L and S are meaningless within a range.
> > >  
> > > Kevin
> > > 
> > > 
> > >   _____
> > > 
> > > From: Steve Cipolli [mailto:SCipolli@radvision.com]
> > > Sent: Monday, December 01, 2003 5:22 PM
> > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
> > > Subject: RE: [Megaco] Digit Maps: Long Duration
> > Modifier(Z), Long Timers (
> > > L), & Short T imers (S)
> > > 
> > > 
> > > Thanks for the feedback.  
> > >  
> > > Just to make sure I understand the L and S cases:
> > > They are syntactically legal in a range specification, but
> > semantically they
> > > have no effect.  Correct?
> > >  
> > > --Stephen
> > > 
> > > -----Original Message-----
> > > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
> > > Sent: Monday, December 01, 2003 5:15 PM
> > > To: Steve Cipolli; megaco@ietf.org
> > > Subject: RE: [Megaco] Digit Maps: Long Duration
> > Modifier(Z), Long Timers (
> > > L), & Short T imers (S)
> > > 
> > > 
> > > Your interpretation is correct.  Because Z changes how a
> > digit is matched,
> > > it makes sense within a range.  Think of Z as part of the
> > digit it modifies,
> > > rather than a separate symbol.
> > >  
> > > The L and S timers within a digitmap give specific
> > instruction as to which
> > > timer to run at that point in the digitmap.  While allowed
> > in a range, I
> > > don't think they provide much value within a range since
> they do not
> > > actually match anything.  For effective use, they should be
> > outside the
> > > range.
> > >  
> > > Kevin
> > > 
> > > 
> > >   _____
> > > 
> > > From: Steve Cipolli [mailto:SCipolli@radvision.com]
> > > Sent: Monday, December 01, 2003 3:26 PM
> > > To: megaco@ietf.org
> > > Subject: [Megaco] Digit Maps: Long Duration Modifier(Z),
> > Long Timers (L), &
> > > Short T imers (S)
> > > 
> > > 
> > >  
> > > According to the syntax in RFCs 3015 & 3525 the long
> > duration modifier (Z),
> > > Long Timers (L), & Short Timers (S) in digit maps can
> > appear in a digit
> > > range.  For example (where Z is 1000ms):
> > >     "135[2Z46]"
> > >  
> > > Is this valid?  If it is valid, does this mean that the
> > fourth digit event
> > > must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
> > >  
> > > How does long timer (L) and short timer (S) in a digit
> range apply?
> > >  
> > > --Stephen
> > >  
> > >  
> > > 
> > > 
> > > _______________________________________________
> > > 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 exim@www1.ietf.org  Tue Dec  2 15:19:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07612
	for <megaco-archive@odin.ietf.org>; Tue, 2 Dec 2003 15:19:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARGz9-00064f-B8
	for megaco-archive@odin.ietf.org; Tue, 02 Dec 2003 15:19:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2KJ3Jd023343
	for megaco-archive@odin.ietf.org; Tue, 2 Dec 2003 15:19:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARGz9-00064Q-6h
	for megaco-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 15:19:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07572
	for <megaco-web-archive@ietf.org>; Tue, 2 Dec 2003 15:18:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARGz7-0007kM-00
	for megaco-web-archive@ietf.org; Tue, 02 Dec 2003 15:19:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARGz7-0007kH-00
	for megaco-web-archive@ietf.org; Tue, 02 Dec 2003 15:19:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARGz6-00063H-K0; Tue, 02 Dec 2003 15:19:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARGz4-00062m-CI
	for megaco@optimus.ietf.org; Tue, 02 Dec 2003 15:18:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07564
	for <megaco@ietf.org>; Tue, 2 Dec 2003 15:18:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARGz3-0007kA-00
	for megaco@ietf.org; Tue, 02 Dec 2003 15:18:57 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARGz2-0007jQ-00
	for megaco@ietf.org; Tue, 02 Dec 2003 15:18:56 -0500
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 hB2KIP712016
	for <megaco@ietf.org>; Tue, 2 Dec 2003 15:18:25 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <WTQH0DBJ>; Tue, 2 Dec 2003 15:18:21 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0CF4F290@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Steve Cipolli <SCipolli@radvision.com>,
        "'Troy Cauble'"
	 <troy@bell-labs.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 L), & Short T imers (S)
Date: Tue, 2 Dec 2003 15:18:11 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Comments inline. [KJBII]

Kevin 

-----Original Message-----
From: Steve Cipolli [mailto:SCipolli@radvision.com] 
Sent: Tuesday, December 02, 2003 2:40 PM
To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)

Perhaps I moved us off track a bit.  It is clear that there is more than one
interpretation of the specification with regard to L, S, and to a lesser
extent Z.  Can the authors comment on what the intent of the specification
was and then perhaps we can reach some conclusion?

Here is a partial list of odd digitmaps that seem to defy interpretation:
	"123Z"   			- "Z" ignored or error?
[KJBII] Z here has nothing to modify.  Error.

	"123S"			- "S" (or "L") ignored or error?
[KJBII] In this instance, the digitmap switches to short interdigit timing
after detecting "123".  So, neither.

	"1ZZ23"			- First "Z" ignored or error?
[KJBII] Because Z is defined as modifying the following digit, and Z cannot
modify Z, this should be an error.

	"1ZSSSSSSSSS23"		- "Z" applied to the "2" or ignored or
error?
[KJBII] See above.  Error as Z cannot modify S (or L).

	"135[2Z46]"			- "Z" applied to "4" or to all in
the range (246) or ignored or error?
[KJBII] Z applies solely to the 4 here.

	"135[246Z]79"		- "Z" applied to "7" or ignored or error?
[KJBII] Nothing for Z to modify.  Error.

	"135[2S46]"			- "S" (or "L") applied to all in
range (246) or ignored or error?
[KJBII] This is the root of our earlier discussion.  L and S do not modify
digits -- they modify timing strategy for the digitmap at the time they are
encountered.  [246] means "match 2, 4 or 6".  So [2S46] means... What
exactly? "Match 2, short timeout, 4 or 6"?  Or "match 2, 4 or 6 while
running the short timer for this digit only"?  Or "run the short timer S
after detecting 2, but not if 4 or 6 is detected"?  If the string were
"135S[246]" then we would start using the short timer before looking for 2,
4 or 6.  If it were "135[246]S", we would start using the short timer AFTER
matching 2, 4 or 6.  But, with the S timer INSIDE the range, that would
indicate that the timer would have to fire to continue.  For instance, if
the string were "135[2S46]79", that would seem to indicate that if NO digit
was detected for the duration of the short timer, then we should continue
with the string to find 7.  This is a contrary usage to S and L at any other
point in a digitmap.  I think S and L should be ignored within ranges.  If
the MGC wants to use the S or L timer, then put them outside the range.

	"135[2L4S6]"		- "L" or "S" applied or both (somehow?) or
ignored or error?
[KJBII] See above -- the same arguments apply here.  I would note that L
would never get "detected" here, since S would match first.

Thanks,
--Stephen

	

> -----Original Message-----
> From: Steve Cipolli [mailto:SCipolli@radvision.com]
> Sent: Monday, December 01, 2003 8:01 PM
> To: 'Troy Cauble'; Kevin Boyle
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
> Timers ( L), & Short T imers (S)
> 
> 
> Part of the problem is the term "alternatives" is not clear.  
> The text in
> 7.1.14.3 says of "alternatives":
> A DigitMap, according to this syntax, is defined either by a string or 
> by a list of strings.  Each string in the list is an alternative event 
> sequence, specified either as a sequence of digit map symbols or as a 
> regular expression of digit map symbols.
> 
> My reading of this is that "alternatives" are each string and not the 
> possible sequences through a range, but admittedly this is not clear.
> 
> The section doesn't seem to explain other odd sequences like "123Z".
> Presumably the "Z" is simply ignored although an error could also be 
> considered the proper outcome.
> 
> I must say I prefer an interpretation in which the number of possible 
> ways to perform the same action is as close to 1 and possible.
> Therefore, I'd
> prefer to ban (or at least ignore) "L" and "S" within ranges.
> 
> --Stephen
> 
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@bell-labs.com]
> > Sent: Monday, December 01, 2003 6:33 PM
> > To: Kevin Boyle
> > Cc: megaco@ietf.org
> > Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
> > Timers ( L), & Short T imers (S)
> > 
> > 
> > 
> > 
> > I disagree that "L" and "S" are meaningless within a range.
> > 
> > "L" and "S" are used to specify the timer used for "subsequent 
> > events".
> > 
> > I would argue that the "5" is a subsequent event in "[34L]5", just 
> > as it is in "[34]L5".
> > 
> > I would also argue that the "4" in "[3L4]5" is NOT a "subsequent 
> > event", although one might debate the definition of "subsequent".
> > 
> > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and
> "[34]L5" are all
> > the same. (And the "L" is not meaningless.)
> > 
> > 
> > Note that section 7.1.14.3 does bother to specify what happens when 
> > explicit timing specifiers are only active in some "alternatives",
> or when they
> > differ in among alternatives -- the same timer value is used for all 
> > alternatives.
> > 
> > 
> > 7.1.14.3:
> > 
> >  > In addition to these event symbols, the string may contain "S" 
> > and "L"
> >  > inter-event timing specifiers and the "Z" duration modifier. "S" 
> > and "L"
> >  > respectively indicate that the MG should use the short (S) timer 
> > or the  > long (L) timer for subsequent events, overriding the 
> > timing rules  > described above. If an explicit timing specifier is 
> > in effect in one  > alternative event sequence, but none is given in 
> > any other candidate  > alternative, the timer value set by the 
> > explicit timing specifier must be  > used. If all sequences with 
> > explicit timing controls are dropped from the  > candidate set, 
> > timing reverts to the default rules given above. Finally,  > if 
> > conflicting timing specifiers are in effect in different alternative  
> > > sequences, the long timer shall be used.
> > 
> > 
> > -troy
> > 
> > 
> > 
> > Kevin Boyle wrote:
> > 
> > > Since a range means "match one of these", I would agree
> > with the assessment
> > > that L and S are meaningless within a range.
> > >  
> > > Kevin
> > > 
> > > 
> > >   _____
> > > 
> > > From: Steve Cipolli [mailto:SCipolli@radvision.com]
> > > Sent: Monday, December 01, 2003 5:22 PM
> > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
> > > Subject: RE: [Megaco] Digit Maps: Long Duration
> > Modifier(Z), Long Timers (
> > > L), & Short T imers (S)
> > > 
> > > 
> > > Thanks for the feedback.  
> > >  
> > > Just to make sure I understand the L and S cases:
> > > They are syntactically legal in a range specification, but
> > semantically they
> > > have no effect.  Correct?
> > >  
> > > --Stephen
> > > 
> > > -----Original Message-----
> > > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
> > > Sent: Monday, December 01, 2003 5:15 PM
> > > To: Steve Cipolli; megaco@ietf.org
> > > Subject: RE: [Megaco] Digit Maps: Long Duration
> > Modifier(Z), Long Timers (
> > > L), & Short T imers (S)
> > > 
> > > 
> > > Your interpretation is correct.  Because Z changes how a
> > digit is matched,
> > > it makes sense within a range.  Think of Z as part of the
> > digit it modifies,
> > > rather than a separate symbol.
> > >  
> > > The L and S timers within a digitmap give specific
> > instruction as to which
> > > timer to run at that point in the digitmap.  While allowed
> > in a range, I
> > > don't think they provide much value within a range since
> they do not
> > > actually match anything.  For effective use, they should be
> > outside the
> > > range.
> > >  
> > > Kevin
> > > 
> > > 
> > >   _____
> > > 
> > > From: Steve Cipolli [mailto:SCipolli@radvision.com]
> > > Sent: Monday, December 01, 2003 3:26 PM
> > > To: megaco@ietf.org
> > > Subject: [Megaco] Digit Maps: Long Duration Modifier(Z),
> > Long Timers (L), &
> > > Short T imers (S)
> > > 
> > > 
> > >  
> > > According to the syntax in RFCs 3015 & 3525 the long
> > duration modifier (Z),
> > > Long Timers (L), & Short Timers (S) in digit maps can
> > appear in a digit
> > > range.  For example (where Z is 1000ms):
> > >     "135[2Z46]"
> > >  
> > > Is this valid?  If it is valid, does this mean that the
> > fourth digit event
> > > must be either 2, 6 (held for any duration) or 4 held for 1000 ms?
> > >  
> > > How does long timer (L) and short timer (S) in a digit
> range apply?
> > >  
> > > --Stephen
> > >  
> > >  
> > > 
> > > 
> > > _______________________________________________
> > > 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-admin@ietf.org  Wed Dec  3 04:28:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07246
	for <megaco-archive@lists.ietf.org>; Wed, 3 Dec 2003 04:28:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARTIf-0002ot-Gh; Wed, 03 Dec 2003 04:28:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARTHq-0002mY-AC
	for megaco@optimus.ietf.org; Wed, 03 Dec 2003 04:27:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07230
	for <megaco@ietf.org>; Wed, 3 Dec 2003 04:26:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARTHn-0004xI-00
	for megaco@ietf.org; Wed, 03 Dec 2003 04:27:07 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARTHm-0004x2-00
	for megaco@ietf.org; Wed, 03 Dec 2003 04:27:07 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HPB00J2BBCYOV@mta0.huawei.com> for megaco@ietf.org;
 Wed, 03 Dec 2003 17:22:12 +0800 (CST)
Date: Wed, 03 Dec 2003 17:23:55 +0800
From: Zhao Bo <zbo@huawei.com>
To: megaco@ietf.org
Message-id: <000701c3b97f$2d791140$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7BIT
Subject: [Megaco] A question about the ITU-T H.248 R2 draft
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7BIT

Hello List:
    When applying the R2 draft(H.248.25, H.248.icasc) to a network like this:
                            MGC
                              /    \
                            /       \
    R2 PBX--->MG1----MG2-->PSTN R2 switch
    
   We find the MGC can't give MG1 a complete digitmap to collect destination number from the R2 PBX
(because the complexity of PSTN, a call may be routes to any regions and contries),  and there isn't I-15 
signalling in R2 PBX. So in most case MG1 will report  the r2 address event due to time out, not digitmap 
match.  This add a significant time delay to call setup procedure and cause quite a lot of compliant.

    Can't we add a extend mechanism to H.248 R2 package, so MGC send multi R2 address event to MG?
MG can then report the destionation number part by part, and once receiving a part, MGC can send them 
to next hop.     

    H.248.icasc allows calling number to  be reported part by part, but it still require MGC have the complete
knowledge of calling number. It only tells MG the sequence to collect a know number pattern, in my case, we
don't know that.

    Best regards
Zhao Bo

*****************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
*****************************************************************

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


From exim@www1.ietf.org  Wed Dec  3 04:28:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07261
	for <megaco-archive@odin.ietf.org>; Wed, 3 Dec 2003 04:28:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARTIl-0002pf-A3
	for megaco-archive@odin.ietf.org; Wed, 03 Dec 2003 04:28:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB39S7Zk010886
	for megaco-archive@odin.ietf.org; Wed, 3 Dec 2003 04:28:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARTIk-0002pV-FA
	for megaco-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 04:28:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07234
	for <megaco-web-archive@ietf.org>; Wed, 3 Dec 2003 04:27:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARTIh-0004xe-00
	for megaco-web-archive@ietf.org; Wed, 03 Dec 2003 04:28:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARTIh-0004xb-00
	for megaco-web-archive@ietf.org; Wed, 03 Dec 2003 04:28:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARTIf-0002ot-Gh; Wed, 03 Dec 2003 04:28:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARTHq-0002mY-AC
	for megaco@optimus.ietf.org; Wed, 03 Dec 2003 04:27:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07230
	for <megaco@ietf.org>; Wed, 3 Dec 2003 04:26:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARTHn-0004xI-00
	for megaco@ietf.org; Wed, 03 Dec 2003 04:27:07 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARTHm-0004x2-00
	for megaco@ietf.org; Wed, 03 Dec 2003 04:27:07 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HPB00J2BBCYOV@mta0.huawei.com> for megaco@ietf.org;
 Wed, 03 Dec 2003 17:22:12 +0800 (CST)
Date: Wed, 03 Dec 2003 17:23:55 +0800
From: Zhao Bo <zbo@huawei.com>
To: megaco@ietf.org
Message-id: <000701c3b97f$2d791140$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7BIT
Subject: [Megaco] A question about the ITU-T H.248 R2 draft
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Hello List:
    When applying the R2 draft(H.248.25, H.248.icasc) to a network like this:
                            MGC
                              /    \
                            /       \
    R2 PBX--->MG1----MG2-->PSTN R2 switch
    
   We find the MGC can't give MG1 a complete digitmap to collect destination number from the R2 PBX
(because the complexity of PSTN, a call may be routes to any regions and contries),  and there isn't I-15 
signalling in R2 PBX. So in most case MG1 will report  the r2 address event due to time out, not digitmap 
match.  This add a significant time delay to call setup procedure and cause quite a lot of compliant.

    Can't we add a extend mechanism to H.248 R2 package, so MGC send multi R2 address event to MG?
MG can then report the destionation number part by part, and once receiving a part, MGC can send them 
to next hop.     

    H.248.icasc allows calling number to  be reported part by part, but it still require MGC have the complete
knowledge of calling number. It only tells MG the sequence to collect a know number pattern, in my case, we
don't know that.

    Best regards
Zhao Bo

*****************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
*****************************************************************

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



From megaco-admin@ietf.org  Wed Dec  3 10:05:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17904
	for <megaco-archive@lists.ietf.org>; Wed, 3 Dec 2003 10:05:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARYYq-0001U5-Kc; Wed, 03 Dec 2003 10:05:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARYXs-0001TD-NG
	for megaco@optimus.ietf.org; Wed, 03 Dec 2003 10:04:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17737
	for <megaco@ietf.org>; Wed, 3 Dec 2003 10:03:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARYXq-0002cA-00
	for megaco@ietf.org; Wed, 03 Dec 2003 10:04:02 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARYXq-0002c7-00
	for megaco@ietf.org; Wed, 03 Dec 2003 10:04:02 -0500
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <XM89M0X4>; Wed, 3 Dec 2003 10:03:58 -0500
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA028A1AAC@wench.telica.com>
From: Brad Steinka <bsteinka@telica.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>
Date: Wed, 3 Dec 2003 10:03:57 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Megaco] International call progress tones
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>


Call progress tones (dial-tone, busy, etc) differ on a per country basis.

Is there any work currently underway to allow the MGC to specify that a
French dial-tone should be
generated by the MG?

OR

Is the current working assumptiong that the per country variants of call
progress tones are PROVISIONED on the
MG?






Brad Steinka
Director - Software Engineering
734 Forest Street, Building G, Suite 100
Marlboro, Ma.   01752
Tel:  508-480-0909  x154
Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
Web:   www.telica.com <http://www.telica.com>



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


From exim@www1.ietf.org  Wed Dec  3 10:05:26 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17925
	for <megaco-archive@odin.ietf.org>; Wed, 3 Dec 2003 10:05:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARYYv-0001V4-5R
	for megaco-archive@odin.ietf.org; Wed, 03 Dec 2003 10:05:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3F59rc005760
	for megaco-archive@odin.ietf.org; Wed, 3 Dec 2003 10:05:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARYYu-0001Up-Rd
	for megaco-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 10:05:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17851
	for <megaco-web-archive@ietf.org>; Wed, 3 Dec 2003 10:04:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARYYs-0002dA-00
	for megaco-web-archive@ietf.org; Wed, 03 Dec 2003 10:05:06 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARYYs-0002d7-00
	for megaco-web-archive@ietf.org; Wed, 03 Dec 2003 10:05:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARYYq-0001U5-Kc; Wed, 03 Dec 2003 10:05:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARYXs-0001TD-NG
	for megaco@optimus.ietf.org; Wed, 03 Dec 2003 10:04:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17737
	for <megaco@ietf.org>; Wed, 3 Dec 2003 10:03:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARYXq-0002cA-00
	for megaco@ietf.org; Wed, 03 Dec 2003 10:04:02 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARYXq-0002c7-00
	for megaco@ietf.org; Wed, 03 Dec 2003 10:04:02 -0500
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <XM89M0X4>; Wed, 3 Dec 2003 10:03:58 -0500
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA028A1AAC@wench.telica.com>
From: Brad Steinka <bsteinka@telica.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>
Date: Wed, 3 Dec 2003 10:03:57 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Megaco] International call progress tones
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>


Call progress tones (dial-tone, busy, etc) differ on a per country basis.

Is there any work currently underway to allow the MGC to specify that a
French dial-tone should be
generated by the MG?

OR

Is the current working assumptiong that the per country variants of call
progress tones are PROVISIONED on the
MG?






Brad Steinka
Director - Software Engineering
734 Forest Street, Building G, Suite 100
Marlboro, Ma.   01752
Tel:  508-480-0909  x154
Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
Web:   www.telica.com <http://www.telica.com>



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



From megaco-admin@ietf.org  Wed Dec  3 11:08:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21376
	for <megaco-archive@lists.ietf.org>; Wed, 3 Dec 2003 11:08:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARZXm-000581-BK; Wed, 03 Dec 2003 11:08:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARZWs-0004q2-23
	for megaco@optimus.ietf.org; Wed, 03 Dec 2003 11:07:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21278
	for <megaco@ietf.org>; Wed, 3 Dec 2003 11:06:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARZWj-0003Y3-00
	for megaco@ietf.org; Wed, 03 Dec 2003 11:06:57 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARZWi-0003Xk-00
	for megaco@ietf.org; Wed, 03 Dec 2003 11:06:57 -0500
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 hB3G6Ox08023
	for <megaco@ietf.org>; Wed, 3 Dec 2003 11:06:24 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <WTQH0RM2>; Wed, 3 Dec 2003 11:06:25 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0CFA8BB1@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Brad Steinka <bsteinka@telica.com>,
        "'megaco@ietf.org'"
	 <megaco@ietf.org>
Subject: RE: [Megaco] International call progress tones
Date: Wed, 3 Dec 2003 11:06:23 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Local differences are the responsibility of the MG.  That is to say, MGs
should know how to correctly produce signals for their terminations.  So,
the short answer to your question is that local-specific information is
provisioned.

If we go to the point of making MGCs responsible for what local flavor of
signals to produce, then the MGC becomes responsible for immense amounts of
data -- every toneset, every ring pattern set, every small difference in
local requirements over the face of the entire Earth.  Remember that part of
the promise of this technology is localized MGs scattered over many
localities controlled from a central MGC in another location.

Kevin

-----Original Message-----
From: Brad Steinka [mailto:bsteinka@telica.com] 
Sent: Wednesday, December 03, 2003 10:04 AM
To: 'megaco@ietf.org'
Subject: [Megaco] International call progress tones


Call progress tones (dial-tone, busy, etc) differ on a per country basis.

Is there any work currently underway to allow the MGC to specify that a
French dial-tone should be generated by the MG?

OR

Is the current working assumptiong that the per country variants of call
progress tones are PROVISIONED on the MG?






Brad Steinka
Director - Software Engineering
734 Forest Street, Building G, Suite 100
Marlboro, Ma.   01752
Tel:  508-480-0909  x154
Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
Web:   www.telica.com <http://www.telica.com>



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

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


From megaco-admin@ietf.org  Wed Dec  3 11:08:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21377
	for <megaco-archive@lists.ietf.org>; Wed, 3 Dec 2003 11:08:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARZXo-00058J-6T; Wed, 03 Dec 2003 11:08:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARZXU-00053D-Aa
	for megaco@optimus.ietf.org; Wed, 03 Dec 2003 11:07:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21337
	for <megaco@ietf.org>; Wed, 3 Dec 2003 11:07:26 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARZXO-0003Z1-00
	for megaco@ietf.org; Wed, 03 Dec 2003 11:07:38 -0500
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARZXO-0003Y9-00
	for megaco@ietf.org; Wed, 03 Dec 2003 11:07:38 -0500
Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67])
	by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB3G6wH20703;
	Wed, 3 Dec 2003 11:06:58 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLY225MC; Wed, 3 Dec 2003 11:06:57 -0500
Received: from nortelnetworks.com (acart1c0.ca.nortel.com [47.129.129.43]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLPWM9B4; Wed, 3 Dec 2003 11:06:58 -0500
Message-ID: <3FCE0A21.4040504@nortelnetworks.com>
Date: Wed, 03 Dec 2003 11:06:57 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brad Steinka <bsteinka@telica.com>
CC: "'megaco@ietf.org'" <megaco@ietf.org>
Subject: Re: [Megaco] International call progress tones
References: <C9AFC8E904D49C4593EB077A2E8402BA028A1AAC@wench.telica.com>
In-Reply-To: <C9AFC8E904D49C4593EB077A2E8402BA028A1AAC@wench.telica.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

The basic philosophy has been that the MG is provisioned to know which 
tone to use.  See the description for tonegen in Annex E.3.  If you want 
the MGC to specify it, you would have to use the Dynamic Tone Generation 
Package (H.248.6).

Brad Steinka wrote:

> Call progress tones (dial-tone, busy, etc) differ on a per country basis.
> 
> Is there any work currently underway to allow the MGC to specify that a
> French dial-tone should be
> generated by the MG?
> 
> OR
> 
> Is the current working assumptiong that the per country variants of call
> progress tones are PROVISIONED on the
> MG?
> 
> 
> 
> 
> 
> 
> Brad Steinka
> Director - Software Engineering
> 734 Forest Street, Building G, Suite 100
> Marlboro, Ma.   01752
> Tel:  508-480-0909  x154
> Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> Web:   www.telica.com <http://www.telica.com>
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


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


From exim@www1.ietf.org  Wed Dec  3 11:08:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21397
	for <megaco-archive@odin.ietf.org>; Wed, 3 Dec 2003 11:08:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARZXq-0005AA-Js
	for megaco-archive@odin.ietf.org; Wed, 03 Dec 2003 11:08:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3G86Ke019840
	for megaco-archive@odin.ietf.org; Wed, 3 Dec 2003 11:08:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARZXq-00059m-3u
	for megaco-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 11:08:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21345
	for <megaco-web-archive@ietf.org>; Wed, 3 Dec 2003 11:07:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARZXn-0003ZH-00
	for megaco-web-archive@ietf.org; Wed, 03 Dec 2003 11:08:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARZXm-0003ZD-00
	for megaco-web-archive@ietf.org; Wed, 03 Dec 2003 11:08:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARZXm-000581-BK; Wed, 03 Dec 2003 11:08:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARZWs-0004q2-23
	for megaco@optimus.ietf.org; Wed, 03 Dec 2003 11:07:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21278
	for <megaco@ietf.org>; Wed, 3 Dec 2003 11:06:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARZWj-0003Y3-00
	for megaco@ietf.org; Wed, 03 Dec 2003 11:06:57 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARZWi-0003Xk-00
	for megaco@ietf.org; Wed, 03 Dec 2003 11:06:57 -0500
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 hB3G6Ox08023
	for <megaco@ietf.org>; Wed, 3 Dec 2003 11:06:24 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <WTQH0RM2>; Wed, 3 Dec 2003 11:06:25 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0CFA8BB1@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Brad Steinka <bsteinka@telica.com>,
        "'megaco@ietf.org'"
	 <megaco@ietf.org>
Subject: RE: [Megaco] International call progress tones
Date: Wed, 3 Dec 2003 11:06:23 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Local differences are the responsibility of the MG.  That is to say, MGs
should know how to correctly produce signals for their terminations.  So,
the short answer to your question is that local-specific information is
provisioned.

If we go to the point of making MGCs responsible for what local flavor of
signals to produce, then the MGC becomes responsible for immense amounts of
data -- every toneset, every ring pattern set, every small difference in
local requirements over the face of the entire Earth.  Remember that part of
the promise of this technology is localized MGs scattered over many
localities controlled from a central MGC in another location.

Kevin

-----Original Message-----
From: Brad Steinka [mailto:bsteinka@telica.com] 
Sent: Wednesday, December 03, 2003 10:04 AM
To: 'megaco@ietf.org'
Subject: [Megaco] International call progress tones


Call progress tones (dial-tone, busy, etc) differ on a per country basis.

Is there any work currently underway to allow the MGC to specify that a
French dial-tone should be generated by the MG?

OR

Is the current working assumptiong that the per country variants of call
progress tones are PROVISIONED on the MG?






Brad Steinka
Director - Software Engineering
734 Forest Street, Building G, Suite 100
Marlboro, Ma.   01752
Tel:  508-480-0909  x154
Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
Web:   www.telica.com <http://www.telica.com>



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

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



From exim@www1.ietf.org  Wed Dec  3 11:08:27 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21426
	for <megaco-archive@odin.ietf.org>; Wed, 3 Dec 2003 11:08:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARZXv-0005Bl-03
	for megaco-archive@odin.ietf.org; Wed, 03 Dec 2003 11:08:11 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3G8AJU019939
	for megaco-archive@odin.ietf.org; Wed, 3 Dec 2003 11:08:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARZXu-00059v-Fk
	for megaco-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 11:08:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21348
	for <megaco-web-archive@ietf.org>; Wed, 3 Dec 2003 11:07:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARZXn-0003ZK-00
	for megaco-web-archive@ietf.org; Wed, 03 Dec 2003 11:08:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARZXn-0003ZE-00
	for megaco-web-archive@ietf.org; Wed, 03 Dec 2003 11:08:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARZXo-00058J-6T; Wed, 03 Dec 2003 11:08:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARZXU-00053D-Aa
	for megaco@optimus.ietf.org; Wed, 03 Dec 2003 11:07:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21337
	for <megaco@ietf.org>; Wed, 3 Dec 2003 11:07:26 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARZXO-0003Z1-00
	for megaco@ietf.org; Wed, 03 Dec 2003 11:07:38 -0500
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARZXO-0003Y9-00
	for megaco@ietf.org; Wed, 03 Dec 2003 11:07:38 -0500
Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67])
	by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB3G6wH20703;
	Wed, 3 Dec 2003 11:06:58 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLY225MC; Wed, 3 Dec 2003 11:06:57 -0500
Received: from nortelnetworks.com (acart1c0.ca.nortel.com [47.129.129.43]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLPWM9B4; Wed, 3 Dec 2003 11:06:58 -0500
Message-ID: <3FCE0A21.4040504@nortelnetworks.com>
Date: Wed, 03 Dec 2003 11:06:57 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brad Steinka <bsteinka@telica.com>
CC: "'megaco@ietf.org'" <megaco@ietf.org>
Subject: Re: [Megaco] International call progress tones
References: <C9AFC8E904D49C4593EB077A2E8402BA028A1AAC@wench.telica.com>
In-Reply-To: <C9AFC8E904D49C4593EB077A2E8402BA028A1AAC@wench.telica.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

The basic philosophy has been that the MG is provisioned to know which 
tone to use.  See the description for tonegen in Annex E.3.  If you want 
the MGC to specify it, you would have to use the Dynamic Tone Generation 
Package (H.248.6).

Brad Steinka wrote:

> Call progress tones (dial-tone, busy, etc) differ on a per country basis.
> 
> Is there any work currently underway to allow the MGC to specify that a
> French dial-tone should be
> generated by the MG?
> 
> OR
> 
> Is the current working assumptiong that the per country variants of call
> progress tones are PROVISIONED on the
> MG?
> 
> 
> 
> 
> 
> 
> Brad Steinka
> Director - Software Engineering
> 734 Forest Street, Building G, Suite 100
> Marlboro, Ma.   01752
> Tel:  508-480-0909  x154
> Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> Web:   www.telica.com <http://www.telica.com>
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


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



From megaco-admin@ietf.org  Wed Dec  3 22:23:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23684
	for <megaco-archive@lists.ietf.org>; Wed, 3 Dec 2003 22:23:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARk4z-0001Ko-Sb; Wed, 03 Dec 2003 22:23:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARk49-0001Js-JF
	for megaco@optimus.ietf.org; Wed, 03 Dec 2003 22:22:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23655
	for <megaco@ietf.org>; Wed, 3 Dec 2003 22:21:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARk45-0007ez-00
	for megaco@ietf.org; Wed, 03 Dec 2003 22:22:05 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARk44-0007eZ-00
	for megaco@ietf.org; Wed, 03 Dec 2003 22:22:05 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HPC00HSCP9HPP@mta0.huawei.com> for megaco@ietf.org;
 Thu, 04 Dec 2003 11:20:06 +0800 (CST)
Date: Thu, 04 Dec 2003 11:21:31 +0800
From: Zhao Bo <zbo@huawei.com>
To: megaco@ietf.org
Message-id: <000301c3ba15$b71cbfa0$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7BIT
Subject: [Megaco] Re: A question about the ITU-T H.248 R2 draft
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7BIT

Guess I didn't describe my question clearly :-(. Try again:

1. MG depends the digitmap to decide if the called numbers receiving  is complete (in most practice, I-15 is not availiabe);
2. When numbers match a digitmap, everything is OK; But in many cases digitmap is not specific enough (something like x.L),  MG will have to wait for a time out;
This timeout add significant time delay to call setup procedure.

How to solve this problem? 
I think MG can send each received number to MGC, MGC can send it to next hop immediately. If some switch in the calling path decide called number is complete, it sends back a Alerting or something, MGC can then clear R2 address event, avoiding MG timeout. 

Actually, I don't like this solution, because MG will have to report many events to MGC. Can anyone give me a better solution? Or any advice?

Thanks very much!

----- Original Message ----- 
From: "Zhao Bo" <zbo@huawei.com>
To: <megaco@ietf.org>
Sent: Wednesday, December 03, 2003 5:23 PM
Subject: A question about the ITU-T H.248 R2 draft


> Hello List:
>     When applying the R2 draft(H.248.25, H.248.icasc) to a network like this:
>                             MGC
>                               /    \
>                             /       \
>     R2 PBX--->MG1----MG2-->PSTN R2 switch
>     
>    We find the MGC can't give MG1 a complete digitmap to collect destination number from the R2 PBX
> (because the complexity of PSTN, a call may be routes to any regions and contries),  and there isn't I-15 
> signalling in R2 PBX. So in most case MG1 will report  the r2 address event due to time out, not digitmap 
> match.  This add a significant time delay to call setup procedure and cause quite a lot of compliant.
> 
>     Can't we add a extend mechanism to H.248 R2 package, so MGC send multi R2 address event to MG?
> MG can then report the destionation number part by part, and once receiving a part, MGC can send them 
> to next hop.     
> 
>     H.248.icasc allows calling number to  be reported part by part, but it still require MGC have the complete
> knowledge of calling number. It only tells MG the sequence to collect a know number pattern, in my case, we
> don't know that.
> 
>     Best regards
> Zhao Bo
> 
> *****************************************************************
> This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
> *****************************************************************

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


From exim@www1.ietf.org  Wed Dec  3 22:23:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23699
	for <megaco-archive@odin.ietf.org>; Wed, 3 Dec 2003 22:23:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARk55-0001Li-Rp
	for megaco-archive@odin.ietf.org; Wed, 03 Dec 2003 22:23:11 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB43N7BC005184
	for megaco-archive@odin.ietf.org; Wed, 3 Dec 2003 22:23:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARk55-0001LX-No
	for megaco-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 22:23:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23672
	for <megaco-web-archive@ietf.org>; Wed, 3 Dec 2003 22:22:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARk52-0007fb-00
	for megaco-web-archive@ietf.org; Wed, 03 Dec 2003 22:23:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARk51-0007fX-00
	for megaco-web-archive@ietf.org; Wed, 03 Dec 2003 22:23:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARk4z-0001Ko-Sb; Wed, 03 Dec 2003 22:23:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARk49-0001Js-JF
	for megaco@optimus.ietf.org; Wed, 03 Dec 2003 22:22:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23655
	for <megaco@ietf.org>; Wed, 3 Dec 2003 22:21:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARk45-0007ez-00
	for megaco@ietf.org; Wed, 03 Dec 2003 22:22:05 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARk44-0007eZ-00
	for megaco@ietf.org; Wed, 03 Dec 2003 22:22:05 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HPC00HSCP9HPP@mta0.huawei.com> for megaco@ietf.org;
 Thu, 04 Dec 2003 11:20:06 +0800 (CST)
Date: Thu, 04 Dec 2003 11:21:31 +0800
From: Zhao Bo <zbo@huawei.com>
To: megaco@ietf.org
Message-id: <000301c3ba15$b71cbfa0$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7BIT
Subject: [Megaco] Re: A question about the ITU-T H.248 R2 draft
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Guess I didn't describe my question clearly :-(. Try again:

1. MG depends the digitmap to decide if the called numbers receiving  is complete (in most practice, I-15 is not availiabe);
2. When numbers match a digitmap, everything is OK; But in many cases digitmap is not specific enough (something like x.L),  MG will have to wait for a time out;
This timeout add significant time delay to call setup procedure.

How to solve this problem? 
I think MG can send each received number to MGC, MGC can send it to next hop immediately. If some switch in the calling path decide called number is complete, it sends back a Alerting or something, MGC can then clear R2 address event, avoiding MG timeout. 

Actually, I don't like this solution, because MG will have to report many events to MGC. Can anyone give me a better solution? Or any advice?

Thanks very much!

----- Original Message ----- 
From: "Zhao Bo" <zbo@huawei.com>
To: <megaco@ietf.org>
Sent: Wednesday, December 03, 2003 5:23 PM
Subject: A question about the ITU-T H.248 R2 draft


> Hello List:
>     When applying the R2 draft(H.248.25, H.248.icasc) to a network like this:
>                             MGC
>                               /    \
>                             /       \
>     R2 PBX--->MG1----MG2-->PSTN R2 switch
>     
>    We find the MGC can't give MG1 a complete digitmap to collect destination number from the R2 PBX
> (because the complexity of PSTN, a call may be routes to any regions and contries),  and there isn't I-15 
> signalling in R2 PBX. So in most case MG1 will report  the r2 address event due to time out, not digitmap 
> match.  This add a significant time delay to call setup procedure and cause quite a lot of compliant.
> 
>     Can't we add a extend mechanism to H.248 R2 package, so MGC send multi R2 address event to MG?
> MG can then report the destionation number part by part, and once receiving a part, MGC can send them 
> to next hop.     
> 
>     H.248.icasc allows calling number to  be reported part by part, but it still require MGC have the complete
> knowledge of calling number. It only tells MG the sequence to collect a know number pattern, in my case, we
> don't know that.
> 
>     Best regards
> Zhao Bo
> 
> *****************************************************************
> This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
> *****************************************************************

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



From megaco-admin@ietf.org  Thu Dec  4 17:35:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21573
	for <megaco-archive@lists.ietf.org>; Thu, 4 Dec 2003 17:35:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS23q-0005CO-PK; Thu, 04 Dec 2003 17:35:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS237-0005BD-QA
	for megaco@optimus.ietf.org; Thu, 04 Dec 2003 17:34:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21401
	for <megaco@ietf.org>; Thu, 4 Dec 2003 17:34:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS235-0003OO-00
	for megaco@ietf.org; Thu, 04 Dec 2003 17:34:15 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS234-0003NL-00
	for megaco@ietf.org; Thu, 04 Dec 2003 17:34:14 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB4MXe012134
	for <megaco@ietf.org>; Thu, 4 Dec 2003 16:33:40 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA01818; Thu, 4 Dec 2003 17:34:01 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA01814; Thu, 4 Dec 2003 17:34:01 -0500 (EST)
Message-ID: <3FCFB5E3.4020801@bell-labs.com>
Date: Thu, 04 Dec 2003 17:32:03 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] wildcarded responses
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit


Can wildcarded responses be returned if they weren't explicitly
requested with a "W-" form?

Specifically, can an MG answer the following with a wildcarded response?

	Transaction = 110 { Context = - { Modify = * {
			Events = 1 { al/of }}}}

-troy




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


From exim@www1.ietf.org  Thu Dec  4 17:35:57 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21676
	for <megaco-archive@odin.ietf.org>; Thu, 4 Dec 2003 17:35:57 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS24V-0005EU-OH
	for megaco-archive@odin.ietf.org; Thu, 04 Dec 2003 17:35:44 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4MZhpn020108
	for megaco-archive@odin.ietf.org; Thu, 4 Dec 2003 17:35:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS24V-0005EF-Jq
	for megaco-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 17:35:43 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21597
	for <megaco-web-archive@ietf.org>; Thu, 4 Dec 2003 17:35:26 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS24S-0003Ra-00
	for megaco-web-archive@ietf.org; Thu, 04 Dec 2003 17:35:41 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS24S-0003Qq-00
	for megaco-web-archive@ietf.org; Thu, 04 Dec 2003 17:35:40 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS23q-0005CO-PK; Thu, 04 Dec 2003 17:35:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS237-0005BD-QA
	for megaco@optimus.ietf.org; Thu, 04 Dec 2003 17:34:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21401
	for <megaco@ietf.org>; Thu, 4 Dec 2003 17:34:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS235-0003OO-00
	for megaco@ietf.org; Thu, 04 Dec 2003 17:34:15 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS234-0003NL-00
	for megaco@ietf.org; Thu, 04 Dec 2003 17:34:14 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB4MXe012134
	for <megaco@ietf.org>; Thu, 4 Dec 2003 16:33:40 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA01818; Thu, 4 Dec 2003 17:34:01 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id RAA01814; Thu, 4 Dec 2003 17:34:01 -0500 (EST)
Message-ID: <3FCFB5E3.4020801@bell-labs.com>
Date: Thu, 04 Dec 2003 17:32:03 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] wildcarded responses
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Can wildcarded responses be returned if they weren't explicitly
requested with a "W-" form?

Specifically, can an MG answer the following with a wildcarded response?

	Transaction = 110 { Context = - { Modify = * {
			Events = 1 { al/of }}}}

-troy




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



From megaco-admin@ietf.org  Thu Dec  4 18:02:17 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23075
	for <megaco-archive@lists.ietf.org>; Thu, 4 Dec 2003 18:02:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2Tx-000648-Gc; Thu, 04 Dec 2003 18:02:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2TT-00062Q-RM
	for megaco@optimus.ietf.org; Thu, 04 Dec 2003 18:01:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22916
	for <Megaco@ietf.org>; Thu, 4 Dec 2003 18:01:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2TR-0003xq-00
	for Megaco@ietf.org; Thu, 04 Dec 2003 18:01:29 -0500
Received: from astra.telenet-ops.be ([195.130.132.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2TP-0003xm-00
	for Megaco@ietf.org; Thu, 04 Dec 2003 18:01:27 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by astra.telenet-ops.be (Postfix) with SMTP id 8117438051
	for <Megaco@ietf.org>; Fri,  5 Dec 2003 00:01:22 +0100 (MET)
Received: from pas (D5778AF4.kabel.telenet.be [213.119.138.244])
	by astra.telenet-ops.be (Postfix) with SMTP id 6990C37FDF
	for <Megaco@ietf.org>; Fri,  5 Dec 2003 00:01:22 +0100 (MET)
Message-ID: <003701c3babb$1ba11ca0$b400a8c0@pandora.be>
Reply-To: "Pascal Lambers" <pascal.lambers@pandora.be>
From: "Pascal Lambers" <pascal.lambers@pandora.be>
To: <Megaco@ietf.org>
Date: Fri, 5 Dec 2003 00:05:27 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0034_01C3BAC3.7D457980"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Subject: [Megaco] SDP mode and Megaco mode question
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0034_01C3BAC3.7D457980
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

Don't know precisely how to forumulate this question clearly, so let me =
put in in two different ways...

What does a MG have to do if an MGC sends a Modify with:
- the Mode property of the LocalControl descriptor set to, for instance, =
receive-only;
- a Local/Remote Descriptor with an SDP-block containing an =
"a=3Dsendrecv" parameter?

In other words, what is the relation beween the a=3Dsendrecv, =
a=3Dsendonly, a=3Dinactive, a=3Drecvonly parameters of the SDP protocol =
and the Mode property of the LocalControl descriptor in the Megaco =
protocol?


Can sb give some advise? Thanks!
Pascal


------=_NextPart_000_0034_01C3BAC3.7D457980
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.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>Don't know precisely how to forumulate this question clearly, =
so&nbsp;let=20
me put in in two different ways...</DIV>
<DIV>&nbsp;</DIV>
<DIV>What does a MG have to do if an MGC sends a Modify with:</DIV>
<DIV>-&nbsp;the Mode property of the&nbsp;LocalControl descriptor set =
to, for=20
instance, receive-only;</DIV>
<DIV>- a Local/Remote Descriptor with an SDP-block containing an =
"a=3Dsendrecv"=20
parameter?</DIV>
<DIV>&nbsp;</DIV>
<DIV>In other words, what is the relation beween the a=3Dsendrecv, =
a=3Dsendonly,=20
a=3Dinactive, a=3Drecvonly parameters of the SDP protocol and the Mode =
property of=20
the LocalControl descriptor in the Megaco protocol?</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Can sb give some advise? Thanks!</DIV>
<DIV>Pascal</DIV></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0034_01C3BAC3.7D457980--



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


From exim@www1.ietf.org  Thu Dec  4 18:02:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23104
	for <megaco-archive@odin.ietf.org>; Thu, 4 Dec 2003 18:02:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2U1-00066A-0S
	for megaco-archive@odin.ietf.org; Thu, 04 Dec 2003 18:02:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4N24gj023436
	for megaco-archive@odin.ietf.org; Thu, 4 Dec 2003 18:02:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2U0-00065v-S0
	for megaco-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 18:02:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23028
	for <megaco-web-archive@ietf.org>; Thu, 4 Dec 2003 18:01:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2Ty-00041c-00
	for megaco-web-archive@ietf.org; Thu, 04 Dec 2003 18:02:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2Tx-00041Z-00
	for megaco-web-archive@ietf.org; Thu, 04 Dec 2003 18:02:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2Tx-000648-Gc; Thu, 04 Dec 2003 18:02:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2TT-00062Q-RM
	for megaco@optimus.ietf.org; Thu, 04 Dec 2003 18:01:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22916
	for <Megaco@ietf.org>; Thu, 4 Dec 2003 18:01:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2TR-0003xq-00
	for Megaco@ietf.org; Thu, 04 Dec 2003 18:01:29 -0500
Received: from astra.telenet-ops.be ([195.130.132.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2TP-0003xm-00
	for Megaco@ietf.org; Thu, 04 Dec 2003 18:01:27 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by astra.telenet-ops.be (Postfix) with SMTP id 8117438051
	for <Megaco@ietf.org>; Fri,  5 Dec 2003 00:01:22 +0100 (MET)
Received: from pas (D5778AF4.kabel.telenet.be [213.119.138.244])
	by astra.telenet-ops.be (Postfix) with SMTP id 6990C37FDF
	for <Megaco@ietf.org>; Fri,  5 Dec 2003 00:01:22 +0100 (MET)
Message-ID: <003701c3babb$1ba11ca0$b400a8c0@pandora.be>
Reply-To: "Pascal Lambers" <pascal.lambers@pandora.be>
From: "Pascal Lambers" <pascal.lambers@pandora.be>
To: <Megaco@ietf.org>
Date: Fri, 5 Dec 2003 00:05:27 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0034_01C3BAC3.7D457980"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Subject: [Megaco] SDP mode and Megaco mode question
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0034_01C3BAC3.7D457980
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

Don't know precisely how to forumulate this question clearly, so let me =
put in in two different ways...

What does a MG have to do if an MGC sends a Modify with:
- the Mode property of the LocalControl descriptor set to, for instance, =
receive-only;
- a Local/Remote Descriptor with an SDP-block containing an =
"a=3Dsendrecv" parameter?

In other words, what is the relation beween the a=3Dsendrecv, =
a=3Dsendonly, a=3Dinactive, a=3Drecvonly parameters of the SDP protocol =
and the Mode property of the LocalControl descriptor in the Megaco =
protocol?


Can sb give some advise? Thanks!
Pascal


------=_NextPart_000_0034_01C3BAC3.7D457980
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.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>Don't know precisely how to forumulate this question clearly, =
so&nbsp;let=20
me put in in two different ways...</DIV>
<DIV>&nbsp;</DIV>
<DIV>What does a MG have to do if an MGC sends a Modify with:</DIV>
<DIV>-&nbsp;the Mode property of the&nbsp;LocalControl descriptor set =
to, for=20
instance, receive-only;</DIV>
<DIV>- a Local/Remote Descriptor with an SDP-block containing an =
"a=3Dsendrecv"=20
parameter?</DIV>
<DIV>&nbsp;</DIV>
<DIV>In other words, what is the relation beween the a=3Dsendrecv, =
a=3Dsendonly,=20
a=3Dinactive, a=3Drecvonly parameters of the SDP protocol and the Mode =
property of=20
the LocalControl descriptor in the Megaco protocol?</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Can sb give some advise? Thanks!</DIV>
<DIV>Pascal</DIV></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0034_01C3BAC3.7D457980--



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



From megaco-admin@ietf.org  Thu Dec  4 18:06:16 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23537
	for <megaco-archive@lists.ietf.org>; Thu, 4 Dec 2003 18:06:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2Xp-0006Lk-Bj; Thu, 04 Dec 2003 18:06:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2X0-0006Jy-EC
	for megaco@optimus.ietf.org; Thu, 04 Dec 2003 18:05:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23370
	for <Megaco@ietf.org>; Thu, 4 Dec 2003 18:04:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2Wx-00045f-00
	for Megaco@ietf.org; Thu, 04 Dec 2003 18:05:07 -0500
Received: from mx1.veraznet.com ([198.87.49.137])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2Ww-00044y-00
	for Megaco@ietf.org; Thu, 04 Dec 2003 18:05:07 -0500
Received: from sapphire.veraznet.com ([198.87.49.5]) by mx1.veraznet.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 4 Dec 2003 15:04:31 -0800
Received: by mail.veraznet.com with Internet Mail Service (5.5.2656.59)
	id <XLSCX25Z>; Thu, 4 Dec 2003 15:04:31 -0800
Message-ID: <9E388C880C1ED411AFE1009027E787250526F0AA@mail.veraznet.com>
From: Madhubabu Brahmanapally <Madhubabu@veraznet.com>
To: "'Pascal Lambers'" <pascal.lambers@pandora.be>, Megaco@ietf.org
Subject: RE: [Megaco] SDP mode and Megaco mode question
Date: Thu, 4 Dec 2003 15:04:20 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3BABA.F36DAB40"
X-OriginalArrivalTime: 04 Dec 2003 23:04:31.0488 (UTC) FILETIME=[F9D82000:01C3BABA]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3BABA.F36DAB40
Content-Type: text/plain;
	charset="iso-8859-1"

The Local Control Descriptor has high precedence over the SDP
information....

-----Original Message-----
From: Pascal Lambers [mailto:pascal.lambers@pandora.be]
Sent: Thursday, December 04, 2003 3:05 PM
To: Megaco@ietf.org
Subject: [Megaco] SDP mode and Megaco mode question



Hello,
 
Don't know precisely how to forumulate this question clearly, so let me put
in in two different ways...
 
What does a MG have to do if an MGC sends a Modify with:
- the Mode property of the LocalControl descriptor set to, for instance,
receive-only;
- a Local/Remote Descriptor with an SDP-block containing an "a=sendrecv"
parameter?
 
In other words, what is the relation beween the a=sendrecv, a=sendonly,
a=inactive, a=recvonly parameters of the SDP protocol and the Mode property
of the LocalControl descriptor in the Megaco protocol?
 
 
Can sb give some advise? Thanks!
Pascal
 
 


------_=_NextPart_001_01C3BABA.F36DAB40
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">


<META content="MSHTML 6.00.2800.1264" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=218310323-04122003><FONT face=Arial color=#0000ff size=2>The 
Local Control Descriptor has high precedence over the SDP 
information....</FONT></SPAN></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> Pascal Lambers 
  [mailto:pascal.lambers@pandora.be]<BR><B>Sent:</B> Thursday, December 04, 2003 
  3:05 PM<BR><B>To:</B> Megaco@ietf.org<BR><B>Subject:</B> [Megaco] SDP mode and 
  Megaco mode question<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial size=2>
  <DIV><FONT face=Arial size=2>Hello,</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV>Don't know precisely how to forumulate this question clearly, so&nbsp;let 
  me put in in two different ways...</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>What does a MG have to do if an MGC sends a Modify with:</DIV>
  <DIV>-&nbsp;the Mode property of the&nbsp;LocalControl descriptor set to, for 
  instance, receive-only;</DIV>
  <DIV>- a Local/Remote Descriptor with an SDP-block containing an "a=sendrecv" 
  parameter?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>In other words, what is the relation beween the a=sendrecv, a=sendonly, 
  a=inactive, a=recvonly parameters of the SDP protocol and the Mode property of 
  the LocalControl descriptor in the Megaco protocol?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Can sb give some advise? Thanks!</DIV>
  <DIV>Pascal</DIV></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3BABA.F36DAB40--

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


From exim@www1.ietf.org  Thu Dec  4 18:06:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23558
	for <megaco-archive@odin.ietf.org>; Thu, 4 Dec 2003 18:06:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2Xs-0006Mp-OX
	for megaco-archive@odin.ietf.org; Thu, 04 Dec 2003 18:06:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4N64ba024469
	for megaco-archive@odin.ietf.org; Thu, 4 Dec 2003 18:06:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2Xs-0006MX-KB
	for megaco-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 18:06:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23458
	for <megaco-web-archive@ietf.org>; Thu, 4 Dec 2003 18:05:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2Xo-00046O-00
	for megaco-web-archive@ietf.org; Thu, 04 Dec 2003 18:06:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2Xn-00046L-00
	for megaco-web-archive@ietf.org; Thu, 04 Dec 2003 18:05:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2Xp-0006Lk-Bj; Thu, 04 Dec 2003 18:06:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2X0-0006Jy-EC
	for megaco@optimus.ietf.org; Thu, 04 Dec 2003 18:05:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23370
	for <Megaco@ietf.org>; Thu, 4 Dec 2003 18:04:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2Wx-00045f-00
	for Megaco@ietf.org; Thu, 04 Dec 2003 18:05:07 -0500
Received: from mx1.veraznet.com ([198.87.49.137])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2Ww-00044y-00
	for Megaco@ietf.org; Thu, 04 Dec 2003 18:05:07 -0500
Received: from sapphire.veraznet.com ([198.87.49.5]) by mx1.veraznet.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 4 Dec 2003 15:04:31 -0800
Received: by mail.veraznet.com with Internet Mail Service (5.5.2656.59)
	id <XLSCX25Z>; Thu, 4 Dec 2003 15:04:31 -0800
Message-ID: <9E388C880C1ED411AFE1009027E787250526F0AA@mail.veraznet.com>
From: Madhubabu Brahmanapally <Madhubabu@veraznet.com>
To: "'Pascal Lambers'" <pascal.lambers@pandora.be>, Megaco@ietf.org
Subject: RE: [Megaco] SDP mode and Megaco mode question
Date: Thu, 4 Dec 2003 15:04:20 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3BABA.F36DAB40"
X-OriginalArrivalTime: 04 Dec 2003 23:04:31.0488 (UTC) FILETIME=[F9D82000:01C3BABA]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3BABA.F36DAB40
Content-Type: text/plain;
	charset="iso-8859-1"

The Local Control Descriptor has high precedence over the SDP
information....

-----Original Message-----
From: Pascal Lambers [mailto:pascal.lambers@pandora.be]
Sent: Thursday, December 04, 2003 3:05 PM
To: Megaco@ietf.org
Subject: [Megaco] SDP mode and Megaco mode question



Hello,
 
Don't know precisely how to forumulate this question clearly, so let me put
in in two different ways...
 
What does a MG have to do if an MGC sends a Modify with:
- the Mode property of the LocalControl descriptor set to, for instance,
receive-only;
- a Local/Remote Descriptor with an SDP-block containing an "a=sendrecv"
parameter?
 
In other words, what is the relation beween the a=sendrecv, a=sendonly,
a=inactive, a=recvonly parameters of the SDP protocol and the Mode property
of the LocalControl descriptor in the Megaco protocol?
 
 
Can sb give some advise? Thanks!
Pascal
 
 


------_=_NextPart_001_01C3BABA.F36DAB40
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">


<META content="MSHTML 6.00.2800.1264" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=218310323-04122003><FONT face=Arial color=#0000ff size=2>The 
Local Control Descriptor has high precedence over the SDP 
information....</FONT></SPAN></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> Pascal Lambers 
  [mailto:pascal.lambers@pandora.be]<BR><B>Sent:</B> Thursday, December 04, 2003 
  3:05 PM<BR><B>To:</B> Megaco@ietf.org<BR><B>Subject:</B> [Megaco] SDP mode and 
  Megaco mode question<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial size=2>
  <DIV><FONT face=Arial size=2>Hello,</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV>Don't know precisely how to forumulate this question clearly, so&nbsp;let 
  me put in in two different ways...</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>What does a MG have to do if an MGC sends a Modify with:</DIV>
  <DIV>-&nbsp;the Mode property of the&nbsp;LocalControl descriptor set to, for 
  instance, receive-only;</DIV>
  <DIV>- a Local/Remote Descriptor with an SDP-block containing an "a=sendrecv" 
  parameter?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>In other words, what is the relation beween the a=sendrecv, a=sendonly, 
  a=inactive, a=recvonly parameters of the SDP protocol and the Mode property of 
  the LocalControl descriptor in the Megaco protocol?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Can sb give some advise? Thanks!</DIV>
  <DIV>Pascal</DIV></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3BABA.F36DAB40--

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



From megaco-admin@ietf.org  Thu Dec  4 18:33:16 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25369
	for <megaco-archive@lists.ietf.org>; Thu, 4 Dec 2003 18:33:16 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2xx-0007aP-Nh; Thu, 04 Dec 2003 18:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2xR-0007ZL-6B
	for megaco@optimus.ietf.org; Thu, 04 Dec 2003 18:32:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25318
	for <Megaco@ietf.org>; Thu, 4 Dec 2003 18:32:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2xE-0004Tb-00
	for Megaco@ietf.org; Thu, 04 Dec 2003 18:32:16 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2xE-0004T7-00
	for Megaco@ietf.org; Thu, 04 Dec 2003 18:32:16 -0500
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB4NVaI03621;
	Thu, 4 Dec 2003 18:31:36 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLSTFVHF; Thu, 4 Dec 2003 18:31:36 -0500
Received: from nortelnetworks.com (acart1hf.ca.nortel.com [47.129.129.223]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLPWM9WK; Thu, 4 Dec 2003 18:31:36 -0500
Message-ID: <3FCFC3D7.8000501@nortelnetworks.com>
Date: Thu, 04 Dec 2003 18:31:35 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Madhubabu Brahmanapally <Madhubabu@veraznet.com>
CC: "'Pascal Lambers'" <pascal.lambers@pandora.be>, Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question
References: <9E388C880C1ED411AFE1009027E787250526F0AA@mail.veraznet.com>
In-Reply-To: <9E388C880C1ED411AFE1009027E787250526F0AA@mail.veraznet.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

I would put it bluntly that the MG must ignore mode in the SDP.

Madhubabu Brahmanapally wrote:

> The Local Control Descriptor has high precedence over the SDP 
> information....
> 
>     -----Original Message-----
>     *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
>     *Sent:* Thursday, December 04, 2003 3:05 PM
>     *To:* Megaco@ietf.org
>     *Subject:* [Megaco] SDP mode and Megaco mode question
> 
>     Hello,
>      
>     Don't know precisely how to forumulate this question clearly, so let
>     me put in in two different ways...
>      
>     What does a MG have to do if an MGC sends a Modify with:
>     - the Mode property of the LocalControl descriptor set to, for
>     instance, receive-only;
>     - a Local/Remote Descriptor with an SDP-block containing an
>     "a=sendrecv" parameter?
>      
>     In other words, what is the relation beween the a=sendrecv,
>     a=sendonly, a=inactive, a=recvonly parameters of the SDP protocol
>     and the Mode property of the LocalControl descriptor in the Megaco
>     protocol?
>      
>      
>     Can sb give some advise? Thanks!
>     Pascal
>      
>      


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


From exim@www1.ietf.org  Thu Dec  4 18:33:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25384
	for <megaco-archive@odin.ietf.org>; Thu, 4 Dec 2003 18:33:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2y0-0007bm-IM
	for megaco-archive@odin.ietf.org; Thu, 04 Dec 2003 18:33:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4NX4pJ029240
	for megaco-archive@odin.ietf.org; Thu, 4 Dec 2003 18:33:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2y0-0007bX-F1
	for megaco-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 18:33:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25356
	for <megaco-web-archive@ietf.org>; Thu, 4 Dec 2003 18:32:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2xx-0004U8-00
	for megaco-web-archive@ietf.org; Thu, 04 Dec 2003 18:33:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2xw-0004U5-00
	for megaco-web-archive@ietf.org; Thu, 04 Dec 2003 18:33:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2xx-0007aP-Nh; Thu, 04 Dec 2003 18:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS2xR-0007ZL-6B
	for megaco@optimus.ietf.org; Thu, 04 Dec 2003 18:32:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25318
	for <Megaco@ietf.org>; Thu, 4 Dec 2003 18:32:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2xE-0004Tb-00
	for Megaco@ietf.org; Thu, 04 Dec 2003 18:32:16 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS2xE-0004T7-00
	for Megaco@ietf.org; Thu, 04 Dec 2003 18:32:16 -0500
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB4NVaI03621;
	Thu, 4 Dec 2003 18:31:36 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLSTFVHF; Thu, 4 Dec 2003 18:31:36 -0500
Received: from nortelnetworks.com (acart1hf.ca.nortel.com [47.129.129.223]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLPWM9WK; Thu, 4 Dec 2003 18:31:36 -0500
Message-ID: <3FCFC3D7.8000501@nortelnetworks.com>
Date: Thu, 04 Dec 2003 18:31:35 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Madhubabu Brahmanapally <Madhubabu@veraznet.com>
CC: "'Pascal Lambers'" <pascal.lambers@pandora.be>, Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question
References: <9E388C880C1ED411AFE1009027E787250526F0AA@mail.veraznet.com>
In-Reply-To: <9E388C880C1ED411AFE1009027E787250526F0AA@mail.veraznet.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I would put it bluntly that the MG must ignore mode in the SDP.

Madhubabu Brahmanapally wrote:

> The Local Control Descriptor has high precedence over the SDP 
> information....
> 
>     -----Original Message-----
>     *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
>     *Sent:* Thursday, December 04, 2003 3:05 PM
>     *To:* Megaco@ietf.org
>     *Subject:* [Megaco] SDP mode and Megaco mode question
> 
>     Hello,
>      
>     Don't know precisely how to forumulate this question clearly, so let
>     me put in in two different ways...
>      
>     What does a MG have to do if an MGC sends a Modify with:
>     - the Mode property of the LocalControl descriptor set to, for
>     instance, receive-only;
>     - a Local/Remote Descriptor with an SDP-block containing an
>     "a=sendrecv" parameter?
>      
>     In other words, what is the relation beween the a=sendrecv,
>     a=sendonly, a=inactive, a=recvonly parameters of the SDP protocol
>     and the Mode property of the LocalControl descriptor in the Megaco
>     protocol?
>      
>      
>     Can sb give some advise? Thanks!
>     Pascal
>      
>      


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



From megaco-admin@ietf.org  Thu Dec  4 21:50:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02512
	for <megaco-archive@lists.ietf.org>; Thu, 4 Dec 2003 21:50:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS62c-0005pU-J1; Thu, 04 Dec 2003 21:50:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS62Z-0005pA-LW
	for megaco@optimus.ietf.org; Thu, 04 Dec 2003 21:49:59 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02504
	for <megaco@ietf.org>; Thu, 4 Dec 2003 21:49:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS62W-0007dp-00
	for megaco@ietf.org; Thu, 04 Dec 2003 21:49:56 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS62V-0007db-00
	for megaco@ietf.org; Thu, 04 Dec 2003 21:49:56 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HPE00BOEIG8G7@mta0.huawei.com> for megaco@ietf.org;
 Fri, 05 Dec 2003 10:48:09 +0800 (CST)
Date: Fri, 05 Dec 2003 10:49:33 +0800
From: Zhao Bo <zbo@huawei.com>
Subject: Re: [Megaco] A question about the ITU-T H.248 R2 draft
To: megaco@ietf.org
Message-id: <001701c3bada$6a79a620$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <000701c3b97f$2d791140$f8486e0a@HUAWEI.COM>
Content-Transfer-Encoding: 7BIT
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7BIT

Guess I didn't describe my question clearly :-(. Try again:

1. MG depends the digitmap to decide if the called numbers receiving  is complete (in most practice, I-15 is not availiabe);
2. When numbers match a digitmap, everything is OK; But in many cases digitmap is not specific enough (something like x.L),  MG will have to wait for a time out;
This timeout add significant time delay to call setup procedure.

How to solve this problem? 
I think MG can send each received number to MGC, MGC can send it to next hop immediately. If some switch in the calling path decide called number is complete, it sends back a Alerting or something, MGC can then clear R2 address event, avoiding MG timeout. 

Actually, I don't like this solution, because MG will have to report many events to MGC. Can anyone give me a better solution? Or any advice?

Thanks very much!

----- Original Message ----- 
From: "Zhao Bo" <zbo@huawei.com>
To: <megaco@ietf.org>
Sent: Wednesday, December 03, 2003 5:23 PM
Subject: [Megaco] A question about the ITU-T H.248 R2 draft


> Hello List:
>     When applying the R2 draft(H.248.25, H.248.icasc) to a network like this:
>                             MGC
>                               /    \
>                             /       \
>     R2 PBX--->MG1----MG2-->PSTN R2 switch
>     
>    We find the MGC can't give MG1 a complete digitmap to collect destination number from the R2 PBX
> (because the complexity of PSTN, a call may be routes to any regions and contries),  and there isn't I-15 
> signalling in R2 PBX. So in most case MG1 will report  the r2 address event due to time out, not digitmap 
> match.  This add a significant time delay to call setup procedure and cause quite a lot of compliant.
> 
>     Can't we add a extend mechanism to H.248 R2 package, so MGC send multi R2 address event to MG?
> MG can then report the destionation number part by part, and once receiving a part, MGC can send them 
> to next hop.     
> 
>     H.248.icasc allows calling number to  be reported part by part, but it still require MGC have the complete
> knowledge of calling number. It only tells MG the sequence to collect a know number pattern, in my case, we
> don't know that.
> 
>     Best regards
> Zhao Bo
> 
> *****************************************************************
> This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
> *****************************************************************
> 
> _______________________________________________
> 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 exim@www1.ietf.org  Thu Dec  4 21:50:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02533
	for <megaco-archive@odin.ietf.org>; Thu, 4 Dec 2003 21:50:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS62j-0005qX-Gz
	for megaco-archive@odin.ietf.org; Thu, 04 Dec 2003 21:50:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB52o90O022467
	for megaco-archive@odin.ietf.org; Thu, 4 Dec 2003 21:50:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS62j-0005qI-AA
	for megaco-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 21:50:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02508
	for <megaco-web-archive@ietf.org>; Thu, 4 Dec 2003 21:49:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS62g-0007dw-00
	for megaco-web-archive@ietf.org; Thu, 04 Dec 2003 21:50:06 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS62g-0007dt-00
	for megaco-web-archive@ietf.org; Thu, 04 Dec 2003 21:50:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS62c-0005pU-J1; Thu, 04 Dec 2003 21:50:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS62Z-0005pA-LW
	for megaco@optimus.ietf.org; Thu, 04 Dec 2003 21:49:59 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02504
	for <megaco@ietf.org>; Thu, 4 Dec 2003 21:49:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS62W-0007dp-00
	for megaco@ietf.org; Thu, 04 Dec 2003 21:49:56 -0500
Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS62V-0007db-00
	for megaco@ietf.org; Thu, 04 Dec 2003 21:49:56 -0500
Received: from z14593 (huawei.com [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0HPE00BOEIG8G7@mta0.huawei.com> for megaco@ietf.org;
 Fri, 05 Dec 2003 10:48:09 +0800 (CST)
Date: Fri, 05 Dec 2003 10:49:33 +0800
From: Zhao Bo <zbo@huawei.com>
Subject: Re: [Megaco] A question about the ITU-T H.248 R2 draft
To: megaco@ietf.org
Message-id: <001701c3bada$6a79a620$f8486e0a@HUAWEI.COM>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <000701c3b97f$2d791140$f8486e0a@HUAWEI.COM>
Content-Transfer-Encoding: 7BIT
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Guess I didn't describe my question clearly :-(. Try again:

1. MG depends the digitmap to decide if the called numbers receiving  is complete (in most practice, I-15 is not availiabe);
2. When numbers match a digitmap, everything is OK; But in many cases digitmap is not specific enough (something like x.L),  MG will have to wait for a time out;
This timeout add significant time delay to call setup procedure.

How to solve this problem? 
I think MG can send each received number to MGC, MGC can send it to next hop immediately. If some switch in the calling path decide called number is complete, it sends back a Alerting or something, MGC can then clear R2 address event, avoiding MG timeout. 

Actually, I don't like this solution, because MG will have to report many events to MGC. Can anyone give me a better solution? Or any advice?

Thanks very much!

----- Original Message ----- 
From: "Zhao Bo" <zbo@huawei.com>
To: <megaco@ietf.org>
Sent: Wednesday, December 03, 2003 5:23 PM
Subject: [Megaco] A question about the ITU-T H.248 R2 draft


> Hello List:
>     When applying the R2 draft(H.248.25, H.248.icasc) to a network like this:
>                             MGC
>                               /    \
>                             /       \
>     R2 PBX--->MG1----MG2-->PSTN R2 switch
>     
>    We find the MGC can't give MG1 a complete digitmap to collect destination number from the R2 PBX
> (because the complexity of PSTN, a call may be routes to any regions and contries),  and there isn't I-15 
> signalling in R2 PBX. So in most case MG1 will report  the r2 address event due to time out, not digitmap 
> match.  This add a significant time delay to call setup procedure and cause quite a lot of compliant.
> 
>     Can't we add a extend mechanism to H.248 R2 package, so MGC send multi R2 address event to MG?
> MG can then report the destionation number part by part, and once receiving a part, MGC can send them 
> to next hop.     
> 
>     H.248.icasc allows calling number to  be reported part by part, but it still require MGC have the complete
> knowledge of calling number. It only tells MG the sequence to collect a know number pattern, in my case, we
> don't know that.
> 
>     Best regards
> Zhao Bo
> 
> *****************************************************************
> This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
> *****************************************************************
> 
> _______________________________________________
> 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-admin@ietf.org  Fri Dec  5 02:59:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24945
	for <megaco-archive@lists.ietf.org>; Fri, 5 Dec 2003 02:59:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASArc-0000Ix-Af; Fri, 05 Dec 2003 02:59:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASAqu-0000Hh-F3
	for megaco@optimus.ietf.org; Fri, 05 Dec 2003 02:58:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24908
	for <Megaco@ietf.org>; Fri, 5 Dec 2003 02:58:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASAqq-0004Oj-00
	for Megaco@ietf.org; Fri, 05 Dec 2003 02:58:12 -0500
Received: from astra.telenet-ops.be ([195.130.132.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASAqq-0004Of-00
	for Megaco@ietf.org; Fri, 05 Dec 2003 02:58:12 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by astra.telenet-ops.be (Postfix) with SMTP
	id A2D6137EEB; Fri,  5 Dec 2003 08:58:12 +0100 (MET)
Received: from pas (D5778F08.kabel.telenet.be [213.119.143.8])
	by astra.telenet-ops.be (Postfix) with SMTP
	id 770AB37EDF; Fri,  5 Dec 2003 08:58:12 +0100 (MET)
Message-ID: <001901c3bb06$1b3ebc40$b400a8c0@pandora.be>
Reply-To: "Pascal Lambers" <pascal.lambers@pandora.be>
From: "Pascal Lambers" <pascal.lambers@pandora.be>
To: "Tom Taylor" <taylor@nortelnetworks.com>,
        "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
Cc: <Megaco@ietf.org>
References: <9E388C880C1ED411AFE1009027E787250526F0AA@mail.veraznet.com> <3FCFC3D7.8000501@nortelnetworks.com>
Subject: Re: [Megaco] SDP mode and Megaco mode question
Date: Fri, 5 Dec 2003 09:02:19 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

So would I, but isn't there any RFC statement to enforce this opinion?

Pascal


----- Original Message ----- 
From: "Tom Taylor" <taylor@nortelnetworks.com>
To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>
Sent: Friday, December 05, 2003 12:31 AM
Subject: Re: [Megaco] SDP mode and Megaco mode question


> I would put it bluntly that the MG must ignore mode in the SDP.
>
> Madhubabu Brahmanapally wrote:
>
> > The Local Control Descriptor has high precedence over the SDP
> > information....
> >
> >     -----Original Message-----
> >     *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
> >     *Sent:* Thursday, December 04, 2003 3:05 PM
> >     *To:* Megaco@ietf.org
> >     *Subject:* [Megaco] SDP mode and Megaco mode question
> >
> >     Hello,
> >
> >     Don't know precisely how to forumulate this question clearly, so let
> >     me put in in two different ways...
> >
> >     What does a MG have to do if an MGC sends a Modify with:
> >     - the Mode property of the LocalControl descriptor set to, for
> >     instance, receive-only;
> >     - a Local/Remote Descriptor with an SDP-block containing an
> >     "a=sendrecv" parameter?
> >
> >     In other words, what is the relation beween the a=sendrecv,
> >     a=sendonly, a=inactive, a=recvonly parameters of the SDP protocol
> >     and the Mode property of the LocalControl descriptor in the Megaco
> >     protocol?
> >
> >
> >     Can sb give some advise? Thanks!
> >     Pascal
> >
> >
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>



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


From exim@www1.ietf.org  Fri Dec  5 02:59:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24960
	for <megaco-archive@odin.ietf.org>; Fri, 5 Dec 2003 02:59:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASArh-0000Ke-NO
	for megaco-archive@odin.ietf.org; Fri, 05 Dec 2003 02:59:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB57x5gm001269
	for megaco-archive@odin.ietf.org; Fri, 5 Dec 2003 02:59:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASArg-0000KO-Kg
	for megaco-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 02:59:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24938
	for <megaco-web-archive@ietf.org>; Fri, 5 Dec 2003 02:58:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASArc-0004PU-00
	for megaco-web-archive@ietf.org; Fri, 05 Dec 2003 02:59:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASArc-0004PN-00
	for megaco-web-archive@ietf.org; Fri, 05 Dec 2003 02:59:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASArc-0000Ix-Af; Fri, 05 Dec 2003 02:59:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASAqu-0000Hh-F3
	for megaco@optimus.ietf.org; Fri, 05 Dec 2003 02:58:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24908
	for <Megaco@ietf.org>; Fri, 5 Dec 2003 02:58:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASAqq-0004Oj-00
	for Megaco@ietf.org; Fri, 05 Dec 2003 02:58:12 -0500
Received: from astra.telenet-ops.be ([195.130.132.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASAqq-0004Of-00
	for Megaco@ietf.org; Fri, 05 Dec 2003 02:58:12 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by astra.telenet-ops.be (Postfix) with SMTP
	id A2D6137EEB; Fri,  5 Dec 2003 08:58:12 +0100 (MET)
Received: from pas (D5778F08.kabel.telenet.be [213.119.143.8])
	by astra.telenet-ops.be (Postfix) with SMTP
	id 770AB37EDF; Fri,  5 Dec 2003 08:58:12 +0100 (MET)
Message-ID: <001901c3bb06$1b3ebc40$b400a8c0@pandora.be>
Reply-To: "Pascal Lambers" <pascal.lambers@pandora.be>
From: "Pascal Lambers" <pascal.lambers@pandora.be>
To: "Tom Taylor" <taylor@nortelnetworks.com>,
        "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
Cc: <Megaco@ietf.org>
References: <9E388C880C1ED411AFE1009027E787250526F0AA@mail.veraznet.com> <3FCFC3D7.8000501@nortelnetworks.com>
Subject: Re: [Megaco] SDP mode and Megaco mode question
Date: Fri, 5 Dec 2003 09:02:19 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

So would I, but isn't there any RFC statement to enforce this opinion?

Pascal


----- Original Message ----- 
From: "Tom Taylor" <taylor@nortelnetworks.com>
To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>
Sent: Friday, December 05, 2003 12:31 AM
Subject: Re: [Megaco] SDP mode and Megaco mode question


> I would put it bluntly that the MG must ignore mode in the SDP.
>
> Madhubabu Brahmanapally wrote:
>
> > The Local Control Descriptor has high precedence over the SDP
> > information....
> >
> >     -----Original Message-----
> >     *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
> >     *Sent:* Thursday, December 04, 2003 3:05 PM
> >     *To:* Megaco@ietf.org
> >     *Subject:* [Megaco] SDP mode and Megaco mode question
> >
> >     Hello,
> >
> >     Don't know precisely how to forumulate this question clearly, so let
> >     me put in in two different ways...
> >
> >     What does a MG have to do if an MGC sends a Modify with:
> >     - the Mode property of the LocalControl descriptor set to, for
> >     instance, receive-only;
> >     - a Local/Remote Descriptor with an SDP-block containing an
> >     "a=sendrecv" parameter?
> >
> >     In other words, what is the relation beween the a=sendrecv,
> >     a=sendonly, a=inactive, a=recvonly parameters of the SDP protocol
> >     and the Mode property of the LocalControl descriptor in the Megaco
> >     protocol?
> >
> >
> >     Can sb give some advise? Thanks!
> >     Pascal
> >
> >
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>



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



From megaco-admin@ietf.org  Fri Dec  5 13:10:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16961
	for <megaco-archive@lists.ietf.org>; Fri, 5 Dec 2003 13:10:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASKOy-0006ZL-7g; Fri, 05 Dec 2003 13:10:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASKOM-0006YG-Vg
	for megaco@optimus.ietf.org; Fri, 05 Dec 2003 13:09:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16875
	for <megaco@ietf.org>; Fri, 5 Dec 2003 13:09:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASKOK-0006dq-00
	for megaco@ietf.org; Fri, 05 Dec 2003 13:09:24 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASKOK-0006dm-00
	for megaco@ietf.org; Fri, 05 Dec 2003 13:09:24 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Fri, 5 Dec 2003 13:09:12 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZS51V>; Fri, 5 Dec 2003 13:09:12 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B0A2D@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'Troy Cauble'"
	 <troy@bell-labs.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 	 L), & Short T imers (S)
Date: Fri, 5 Dec 2003 13:09:11 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3BB5A.E22F5770"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3BB5A.E22F5770
Content-Type: text/plain;
	charset="iso-8859-1"

While I tend to agree with most of the answers below, I don't see any of
this specified in the specification.  If we can agree that the answers below
are the correct interpretation, then we still need clarification in the spec
or implementors guide.  I'm still hoping the original author of this section
of the spec will clarify the original intention.
 
--Stephen

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Tuesday, December 02, 2003 3:18 PM
To: Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)



Comments inline. [KJBII] 

Kevin 

-----Original Message----- 
From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
Sent: Tuesday, December 02, 2003 2:40 PM 
To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH] 
Cc: megaco@ietf.org 
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S) 

Perhaps I moved us off track a bit.  It is clear that there is more than one
interpretation of the specification with regard to L, S, and to a lesser
extent Z.  Can the authors comment on what the intent of the specification
was and then perhaps we can reach some conclusion?

Here is a partial list of odd digitmaps that seem to defy interpretation: 
        "123Z"                          - "Z" ignored or error? 
[KJBII] Z here has nothing to modify.  Error. 

        "123S"                  - "S" (or "L") ignored or error? 
[KJBII] In this instance, the digitmap switches to short interdigit timing
after detecting "123".  So, neither. 

        "1ZZ23"                 - First "Z" ignored or error? 
[KJBII] Because Z is defined as modifying the following digit, and Z cannot
modify Z, this should be an error. 

        "1ZSSSSSSSSS23"         - "Z" applied to the "2" or ignored or
error? 
[KJBII] See above.  Error as Z cannot modify S (or L). 

        "135[2Z46]"                     - "Z" applied to "4" or to all in
the range (246) or ignored or error? 
[KJBII] Z applies solely to the 4 here. 

        "135[246Z]79"           - "Z" applied to "7" or ignored or error? 
[KJBII] Nothing for Z to modify.  Error. 

        "135[2S46]"                     - "S" (or "L") applied to all in
range (246) or ignored or error? 
[KJBII] This is the root of our earlier discussion.  L and S do not modify
digits -- they modify timing strategy for the digitmap at the time they are
encountered.  [246] means "match 2, 4 or 6".  So [2S46] means... What
exactly? "Match 2, short timeout, 4 or 6"?  Or "match 2, 4 or 6 while
running the short timer for this digit only"?  Or "run the short timer S
after detecting 2, but not if 4 or 6 is detected"?  If the string were
"135S[246]" then we would start using the short timer before looking for 2,
4 or 6.  If it were "135[246]S", we would start using the short timer AFTER
matching 2, 4 or 6.  But, with the S timer INSIDE the range, that would
indicate that the timer would have to fire to continue.  For instance, if
the string were "135[2S46]79", that would seem to indicate that if NO digit
was detected for the duration of the short timer, then we should continue
with the string to find 7.  This is a contrary usage to S and L at any other
point in a digitmap.  I think S and L should be ignored within ranges.  If
the MGC wants to use the S or L timer, then put them outside the range.

        "135[2L4S6]"            - "L" or "S" applied or both (somehow?) or
ignored or error? 
[KJBII] See above -- the same arguments apply here.  I would note that L
would never get "detected" here, since S would match first.

Thanks, 
--Stephen 

        

> -----Original Message----- 
> From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
> Sent: Monday, December 01, 2003 8:01 PM 
> To: 'Troy Cauble'; Kevin Boyle 
> Cc: megaco@ietf.org 
> Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
> Timers ( L), & Short T imers (S) 
> 
> 
> Part of the problem is the term "alternatives" is not clear.  
> The text in 
> 7.1.14.3 says of "alternatives": 
> A DigitMap, according to this syntax, is defined either by a string or 
> by a list of strings.  Each string in the list is an alternative event 
> sequence, specified either as a sequence of digit map symbols or as a 
> regular expression of digit map symbols. 
> 
> My reading of this is that "alternatives" are each string and not the 
> possible sequences through a range, but admittedly this is not clear. 
> 
> The section doesn't seem to explain other odd sequences like "123Z". 
> Presumably the "Z" is simply ignored although an error could also be 
> considered the proper outcome. 
> 
> I must say I prefer an interpretation in which the number of possible 
> ways to perform the same action is as close to 1 and possible. 
> Therefore, I'd 
> prefer to ban (or at least ignore) "L" and "S" within ranges. 
> 
> --Stephen 
> 
> > -----Original Message----- 
> > From: Troy Cauble [ mailto:troy@bell-labs.com
<mailto:troy@bell-labs.com> ] 
> > Sent: Monday, December 01, 2003 6:33 PM 
> > To: Kevin Boyle 
> > Cc: megaco@ietf.org 
> > Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
> > Timers ( L), & Short T imers (S) 
> > 
> > 
> > 
> > 
> > I disagree that "L" and "S" are meaningless within a range. 
> > 
> > "L" and "S" are used to specify the timer used for "subsequent 
> > events". 
> > 
> > I would argue that the "5" is a subsequent event in "[34L]5", just 
> > as it is in "[34]L5". 
> > 
> > I would also argue that the "4" in "[3L4]5" is NOT a "subsequent 
> > event", although one might debate the definition of "subsequent". 
> > 
> > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and 
> "[34]L5" are all 
> > the same. (And the "L" is not meaningless.) 
> > 
> > 
> > Note that section 7.1.14.3 does bother to specify what happens when 
> > explicit timing specifiers are only active in some "alternatives", 
> or when they 
> > differ in among alternatives -- the same timer value is used for all 
> > alternatives. 
> > 
> > 
> > 7.1.14.3: 
> > 
> >  > In addition to these event symbols, the string may contain "S" 
> > and "L" 
> >  > inter-event timing specifiers and the "Z" duration modifier. "S" 
> > and "L" 
> >  > respectively indicate that the MG should use the short (S) timer 
> > or the  > long (L) timer for subsequent events, overriding the 
> > timing rules  > described above. If an explicit timing specifier is 
> > in effect in one  > alternative event sequence, but none is given in 
> > any other candidate  > alternative, the timer value set by the 
> > explicit timing specifier must be  > used. If all sequences with 
> > explicit timing controls are dropped from the  > candidate set, 
> > timing reverts to the default rules given above. Finally,  > if 
> > conflicting timing specifiers are in effect in different alternative  
> > > sequences, the long timer shall be used. 
> > 
> > 
> > -troy 
> > 
> > 
> > 
> > Kevin Boyle wrote: 
> > 
> > > Since a range means "match one of these", I would agree 
> > with the assessment 
> > > that L and S are meaningless within a range. 
> > >  
> > > Kevin 
> > > 
> > > 
> > >   _____ 
> > > 
> > > From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
> > > Sent: Monday, December 01, 2003 5:22 PM 
> > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org 
> > > Subject: RE: [Megaco] Digit Maps: Long Duration 
> > Modifier(Z), Long Timers ( 
> > > L), & Short T imers (S) 
> > > 
> > > 
> > > Thanks for the feedback.  
> > >  
> > > Just to make sure I understand the L and S cases: 
> > > They are syntactically legal in a range specification, but 
> > semantically they 
> > > have no effect.  Correct? 
> > >  
> > > --Stephen 
> > > 
> > > -----Original Message----- 
> > > From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 
> > > Sent: Monday, December 01, 2003 5:15 PM 
> > > To: Steve Cipolli; megaco@ietf.org 
> > > Subject: RE: [Megaco] Digit Maps: Long Duration 
> > Modifier(Z), Long Timers ( 
> > > L), & Short T imers (S) 
> > > 
> > > 
> > > Your interpretation is correct.  Because Z changes how a 
> > digit is matched, 
> > > it makes sense within a range.  Think of Z as part of the 
> > digit it modifies, 
> > > rather than a separate symbol. 
> > >  
> > > The L and S timers within a digitmap give specific 
> > instruction as to which 
> > > timer to run at that point in the digitmap.  While allowed 
> > in a range, I 
> > > don't think they provide much value within a range since 
> they do not 
> > > actually match anything.  For effective use, they should be 
> > outside the 
> > > range. 
> > >  
> > > Kevin 
> > > 
> > > 
> > >   _____ 
> > > 
> > > From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
> > > Sent: Monday, December 01, 2003 3:26 PM 
> > > To: megaco@ietf.org 
> > > Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), 
> > Long Timers (L), & 
> > > Short T imers (S) 
> > > 
> > > 
> > >  
> > > According to the syntax in RFCs 3015 & 3525 the long 
> > duration modifier (Z), 
> > > Long Timers (L), & Short Timers (S) in digit maps can 
> > appear in a digit 
> > > range.  For example (where Z is 1000ms): 
> > >     "135[2Z46]" 
> > >  
> > > Is this valid?  If it is valid, does this mean that the 
> > fourth digit event 
> > > must be either 2, 6 (held for any duration) or 4 held for 1000 ms? 
> > >  
> > > How does long timer (L) and short timer (S) in a digit 
> range apply? 
> > >  
> > > --Stephen 
> > >  
> > >  
> > > 
> > > 
> > > _______________________________________________ 
> > > 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
<https://www1.ietf.org/mailman/listinfo/megaco>  
> > 
> 
> 
> _______________________________________________ 
> Megaco mailing list 
> Megaco@ietf.org 
> https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  
> 


------_=_NextPart_001_01C3BB5A.E22F5770
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] Digit Maps: Long Duration Modifier(Z), Long Timers ( L), & Short T imers (S)</TITLE>

<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=456500318-05122003><FONT face=Arial color=#0000ff size=2>While 
I tend to agree with most of&nbsp;the answers below, I don't see any of this 
specified in the specification.&nbsp; If we can agree that the answers below are 
the correct interpretation, then we still need clarification in the spec or 
implementors guide.&nbsp; I'm still hoping the original author of this section 
of the spec will clarify the original intention.</FONT></SPAN></DIV>
<DIV><SPAN class=456500318-05122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=456500318-05122003><FONT face=Arial color=#0000ff 
size=2>--Stephen</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; 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, December 02, 2003 
  3:18 PM<BR><B>To:</B> Steve Cipolli; 'Troy Cauble'<BR><B>Cc:</B> 
  megaco@ietf.org<BR><B>Subject:</B> RE: [Megaco] Digit Maps: Long Duration 
  Modifier(Z), Long Timers ( L), &amp; Short T imers (S)<BR><BR></FONT></DIV>
  <P><FONT size=2>Comments inline. [KJBII]</FONT> </P>
  <P><FONT size=2>Kevin </FONT></P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Steve 
  Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR><FONT size=2>Sent: Tuesday, December 02, 2003 2:40 PM</FONT> 
  <BR><FONT size=2>To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH]</FONT> 
  <BR><FONT size=2>Cc: megaco@ietf.org</FONT> <BR><FONT size=2>Subject: RE: 
  [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers ( L), &amp; Short 
  T imers (S)</FONT> </P>
  <P><FONT size=2>Perhaps I moved us off track a bit.&nbsp; It is clear that 
  there is more than one interpretation of the specification with regard to L, 
  S, and to a lesser extent Z.&nbsp; Can the authors comment on what the intent 
  of the specification was and then perhaps we can reach some 
  conclusion?</FONT></P>
  <P><FONT size=2>Here is a partial list of odd digitmaps that seem to defy 
  interpretation:</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>"123Z"&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "Z" ignored or error?</FONT> 
  <BR><FONT size=2>[KJBII] Z here has nothing to modify.&nbsp; Error.</FONT> 
</P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>"123S"&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "S" (or "L") ignored or 
  error?</FONT> <BR><FONT size=2>[KJBII] In this instance, the digitmap switches 
  to short interdigit timing after detecting "123".&nbsp; So, neither.</FONT> 
  </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>"1ZZ23" 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - First "Z" ignored or 
  error?</FONT> <BR><FONT size=2>[KJBII] Because Z is defined as modifying the 
  following digit, and Z cannot modify Z, this should be an error.</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>"1ZSSSSSSSSS23" 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "Z" applied to the "2" or ignored 
  or error?</FONT> <BR><FONT size=2>[KJBII] See above.&nbsp; Error as Z cannot 
  modify S (or L).</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>"135[2Z46]"&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "Z" applied to "4" or to all in 
  the range (246) or ignored or error?</FONT> <BR><FONT size=2>[KJBII] Z applies 
  solely to the 4 here.</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>"135[246Z]79"&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 
  "Z" applied to "7" or ignored or error?</FONT> <BR><FONT size=2>[KJBII] 
  Nothing for Z to modify.&nbsp; Error.</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>"135[2S46]"&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "S" (or "L") applied to all in 
  range (246) or ignored or error?</FONT> <BR><FONT size=2>[KJBII] This is the 
  root of our earlier discussion.&nbsp; L and S do not modify digits -- they 
  modify timing strategy for the digitmap at the time they are 
  encountered.&nbsp; [246] means "match 2, 4 or 6".&nbsp; So [2S46] means... 
  What exactly? "Match 2, short timeout, 4 or 6"?&nbsp; Or "match 2, 4 or 6 
  while running the short timer for this digit only"?&nbsp; Or "run the short 
  timer S after detecting 2, but not if 4 or 6 is detected"?&nbsp; If the string 
  were "135S[246]" then we would start using the short timer before looking for 
  2, 4 or 6.&nbsp; If it were "135[246]S", we would start using the short timer 
  AFTER matching 2, 4 or 6.&nbsp; But, with the S timer INSIDE the range, that 
  would indicate that the timer would have to fire to continue.&nbsp; For 
  instance, if the string were "135[2S46]79", that would seem to indicate that 
  if NO digit was detected for the duration of the short timer, then we should 
  continue with the string to find 7.&nbsp; This is a contrary usage to S and L 
  at any other point in a digitmap.&nbsp; I think S and L should be ignored 
  within ranges.&nbsp; If the MGC wants to use the S or L timer, then put them 
  outside the range.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>"135[2L4S6]"&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "L" or "S" applied or both 
  (somehow?) or ignored or error?</FONT> <BR><FONT size=2>[KJBII] See above -- 
  the same arguments apply here.&nbsp; I would note that L would never get 
  "detected" here, since S would match first.</FONT></P>
  <P><FONT size=2>Thanks,</FONT> <BR><FONT size=2>--Stephen</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Steve Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: Monday, December 01, 2003 8:01 PM</FONT> <BR><FONT 
  size=2>&gt; To: 'Troy Cauble'; Kevin Boyle</FONT> <BR><FONT size=2>&gt; Cc: 
  megaco@ietf.org</FONT> <BR><FONT size=2>&gt; Subject: RE: [Megaco] Digit Maps: 
  Long Duration Modifier(Z), Long </FONT><BR><FONT size=2>&gt; Timers ( L), 
  &amp; Short T imers (S)</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; Part of the problem is the term 
  "alternatives" is not clear.&nbsp; </FONT><BR><FONT size=2>&gt; The text 
  in</FONT> <BR><FONT size=2>&gt; 7.1.14.3 says of "alternatives":</FONT> 
  <BR><FONT size=2>&gt; A DigitMap, according to this syntax, is defined either 
  by a string or </FONT><BR><FONT size=2>&gt; by a list of strings.&nbsp; Each 
  string in the list is an alternative event </FONT><BR><FONT size=2>&gt; 
  sequence, specified either as a sequence of digit map symbols or as a 
  </FONT><BR><FONT size=2>&gt; regular expression of digit map symbols.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; My reading of this is that 
  "alternatives" are each string and not the </FONT><BR><FONT size=2>&gt; 
  possible sequences through a range, but admittedly this is not clear.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; The section doesn't seem to 
  explain other odd sequences like "123Z".</FONT> <BR><FONT size=2>&gt; 
  Presumably the "Z" is simply ignored although an error could also be 
  </FONT><BR><FONT size=2>&gt; considered the proper outcome.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; I must say I prefer an interpretation 
  in which the number of possible </FONT><BR><FONT size=2>&gt; ways to perform 
  the same action is as close to 1 and possible.</FONT> <BR><FONT size=2>&gt; 
  Therefore, I'd</FONT> <BR><FONT size=2>&gt; prefer to ban (or at least ignore) 
  "L" and "S" within ranges.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; --Stephen</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; 
  From: Troy Cauble [<A 
  href="mailto:troy@bell-labs.com">mailto:troy@bell-labs.com</A>]</FONT> 
  <BR><FONT size=2>&gt; &gt; Sent: Monday, December 01, 2003 6:33 PM</FONT> 
  <BR><FONT size=2>&gt; &gt; To: Kevin Boyle</FONT> <BR><FONT size=2>&gt; &gt; 
  Cc: megaco@ietf.org</FONT> <BR><FONT size=2>&gt; &gt; Subject: Re: [Megaco] 
  Digit Maps: Long Duration Modifier(Z), Long </FONT><BR><FONT size=2>&gt; &gt; 
  Timers ( L), &amp; Short T imers (S)</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; I disagree 
  that "L" and "S" are meaningless within a range.</FONT> <BR><FONT size=2>&gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt; "L" and "S" are used to specify the 
  timer used for "subsequent </FONT><BR><FONT size=2>&gt; &gt; events".</FONT> 
  <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; I would argue 
  that the "5" is a subsequent event in "[34L]5", just </FONT><BR><FONT 
  size=2>&gt; &gt; as it is in "[34]L5".</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; I would also argue that the "4" in "[3L4]5" 
  is NOT a "subsequent </FONT><BR><FONT size=2>&gt; &gt; event", although one 
  might debate the definition of "subsequent".</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; In summary, I think "[L34]5", "[3L4]5", 
  "[34L]5", and</FONT> <BR><FONT size=2>&gt; "[34]L5" are all</FONT> <BR><FONT 
  size=2>&gt; &gt; the same. (And the "L" is not meaningless.)</FONT> <BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; Note that section 7.1.14.3 does bother to specify what 
  happens when </FONT><BR><FONT size=2>&gt; &gt; explicit timing specifiers are 
  only active in some "alternatives",</FONT> <BR><FONT size=2>&gt; or when 
  they</FONT> <BR><FONT size=2>&gt; &gt; differ in among alternatives -- the 
  same timer value is used for all </FONT><BR><FONT size=2>&gt; &gt; 
  alternatives.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt; 7.1.14.3:</FONT> <BR><FONT size=2>&gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt;&nbsp; &gt; In addition to these event 
  symbols, the string may contain "S" </FONT><BR><FONT size=2>&gt; &gt; and 
  "L"</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt; inter-event timing specifiers 
  and the "Z" duration modifier. "S" </FONT><BR><FONT size=2>&gt; &gt; and 
  "L"</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt; respectively indicate that 
  the MG should use the short (S) timer </FONT><BR><FONT size=2>&gt; &gt; or 
  the&nbsp; &gt; long (L) timer for subsequent events, overriding the 
  </FONT><BR><FONT size=2>&gt; &gt; timing rules&nbsp; &gt; described above. If 
  an explicit timing specifier is </FONT><BR><FONT size=2>&gt; &gt; in effect in 
  one&nbsp; &gt; alternative event sequence, but none is given in 
  </FONT><BR><FONT size=2>&gt; &gt; any other candidate&nbsp; &gt; alternative, 
  the timer value set by the </FONT><BR><FONT size=2>&gt; &gt; explicit timing 
  specifier must be&nbsp; &gt; used. If all sequences with </FONT><BR><FONT 
  size=2>&gt; &gt; explicit timing controls are dropped from the&nbsp; &gt; 
  candidate set, </FONT><BR><FONT size=2>&gt; &gt; timing reverts to the default 
  rules given above. Finally,&nbsp; &gt; if </FONT><BR><FONT size=2>&gt; &gt; 
  conflicting timing specifiers are in effect in different alternative&nbsp; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; sequences, the long timer shall be 
  used.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; -troy</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; Kevin Boyle wrote:</FONT> <BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; Since a range means 
  "match one of these", I would agree</FONT> <BR><FONT size=2>&gt; &gt; with the 
  assessment</FONT> <BR><FONT size=2>&gt; &gt; &gt; that L and S are meaningless 
  within a range.</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; Kevin</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  &gt;&nbsp;&nbsp; _____</FONT> <BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; From: Steve Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>]</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; Sent: Monday, December 01, 2003 5:22 PM</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 
  megaco@ietf.org</FONT> <BR><FONT size=2>&gt; &gt; &gt; Subject: RE: [Megaco] 
  Digit Maps: Long Duration</FONT> <BR><FONT size=2>&gt; &gt; Modifier(Z), Long 
  Timers (</FONT> <BR><FONT size=2>&gt; &gt; &gt; L), &amp; Short T imers 
  (S)</FONT> <BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; Thanks for the feedback.&nbsp; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; 
  &gt; Just to make sure I understand the L and S cases:</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; They are syntactically legal in a range specification, 
  but</FONT> <BR><FONT size=2>&gt; &gt; semantically they</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; have no effect.&nbsp; Correct?</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  --Stephen</FONT> <BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; 
  &gt; &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  From: Kevin Boyle [<A 
  href="mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.com</A>]</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; Sent: Monday, December 01, 2003 5:15 PM</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; To: Steve Cipolli; megaco@ietf.org</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; Subject: RE: [Megaco] Digit Maps: Long 
  Duration</FONT> <BR><FONT size=2>&gt; &gt; Modifier(Z), Long Timers (</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; L), &amp; Short T imers (S)</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; Your interpretation is correct.&nbsp; Because Z changes 
  how a</FONT> <BR><FONT size=2>&gt; &gt; digit is matched,</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; it makes sense within a range.&nbsp; Think of Z as part 
  of the</FONT> <BR><FONT size=2>&gt; &gt; digit it modifies,</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; rather than a separate symbol.</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; &gt; The L and S 
  timers within a digitmap give specific</FONT> <BR><FONT size=2>&gt; &gt; 
  instruction as to which</FONT> <BR><FONT size=2>&gt; &gt; &gt; timer to run at 
  that point in the digitmap.&nbsp; While allowed</FONT> <BR><FONT size=2>&gt; 
  &gt; in a range, I</FONT> <BR><FONT size=2>&gt; &gt; &gt; don't think they 
  provide much value within a range since</FONT> <BR><FONT size=2>&gt; they do 
  not</FONT> <BR><FONT size=2>&gt; &gt; &gt; actually match anything.&nbsp; For 
  effective use, they should be</FONT> <BR><FONT size=2>&gt; &gt; outside 
  the</FONT> <BR><FONT size=2>&gt; &gt; &gt; range.</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; &gt; Kevin</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt;&nbsp;&nbsp; _____</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; From: Steve Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>]</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; Sent: Monday, December 01, 2003 3:26 PM</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; To: megaco@ietf.org</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; Subject: [Megaco] Digit Maps: Long Duration 
  Modifier(Z),</FONT> <BR><FONT size=2>&gt; &gt; Long Timers (L), &amp;</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; Short T imers (S)</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; 
  &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; &gt; According to the syntax 
  in RFCs 3015 &amp; 3525 the long</FONT> <BR><FONT size=2>&gt; &gt; duration 
  modifier (Z),</FONT> <BR><FONT size=2>&gt; &gt; &gt; Long Timers (L), &amp; 
  Short Timers (S) in digit maps can</FONT> <BR><FONT size=2>&gt; &gt; appear in 
  a digit</FONT> <BR><FONT size=2>&gt; &gt; &gt; range.&nbsp; For example (where 
  Z is 1000ms):</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2Z46]"</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; Is this valid?&nbsp; If it is valid, does this mean that 
  the</FONT> <BR><FONT size=2>&gt; &gt; fourth digit event</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; must be either 2, 6 (held for any duration) or 4 held 
  for 1000 ms?</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; How does long timer (L) and short timer (S) in a 
  digit</FONT> <BR><FONT size=2>&gt; range apply?</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; &gt; --Stephen</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; 
  &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; 
  &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; Megaco mailing list</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  Megaco@ietf.org</FONT> <BR><FONT size=2>&gt; &gt; &gt; <A 
  href="https://www1.ietf.org/mailman/listinfo/megaco" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> 
  <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  &gt; Megaco mailing list</FONT> <BR><FONT size=2>&gt; &gt; 
  Megaco@ietf.org</FONT> <BR><FONT size=2>&gt; &gt; <A 
  href="https://www1.ietf.org/mailman/listinfo/megaco" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> 
  <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  Megaco mailing list</FONT> <BR><FONT size=2>&gt; Megaco@ietf.org</FONT> 
  <BR><FONT size=2>&gt; <A href="https://www1.ietf.org/mailman/listinfo/megaco" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> 
  <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3BB5A.E22F5770--


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


From exim@www1.ietf.org  Fri Dec  5 13:10:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16980
	for <megaco-archive@odin.ietf.org>; Fri, 5 Dec 2003 13:10:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASKP1-0006a8-Od
	for megaco-archive@odin.ietf.org; Fri, 05 Dec 2003 13:10:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5IA76s025297
	for megaco-archive@odin.ietf.org; Fri, 5 Dec 2003 13:10:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASKP1-0006Zw-Cx
	for megaco-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 13:10:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16922
	for <megaco-web-archive@ietf.org>; Fri, 5 Dec 2003 13:09:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASKOz-0006f7-00
	for megaco-web-archive@ietf.org; Fri, 05 Dec 2003 13:10:05 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASKOy-0006f4-00
	for megaco-web-archive@ietf.org; Fri, 05 Dec 2003 13:10:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASKOy-0006ZL-7g; Fri, 05 Dec 2003 13:10:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASKOM-0006YG-Vg
	for megaco@optimus.ietf.org; Fri, 05 Dec 2003 13:09:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16875
	for <megaco@ietf.org>; Fri, 5 Dec 2003 13:09:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASKOK-0006dq-00
	for megaco@ietf.org; Fri, 05 Dec 2003 13:09:24 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASKOK-0006dm-00
	for megaco@ietf.org; Fri, 05 Dec 2003 13:09:24 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Fri, 5 Dec 2003 13:09:12 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZS51V>; Fri, 5 Dec 2003 13:09:12 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B0A2D@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'Troy Cauble'"
	 <troy@bell-labs.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 	 L), & Short T imers (S)
Date: Fri, 5 Dec 2003 13:09:11 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3BB5A.E22F5770"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3BB5A.E22F5770
Content-Type: text/plain;
	charset="iso-8859-1"

While I tend to agree with most of the answers below, I don't see any of
this specified in the specification.  If we can agree that the answers below
are the correct interpretation, then we still need clarification in the spec
or implementors guide.  I'm still hoping the original author of this section
of the spec will clarify the original intention.
 
--Stephen

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Tuesday, December 02, 2003 3:18 PM
To: Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)



Comments inline. [KJBII] 

Kevin 

-----Original Message----- 
From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
Sent: Tuesday, December 02, 2003 2:40 PM 
To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH] 
Cc: megaco@ietf.org 
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S) 

Perhaps I moved us off track a bit.  It is clear that there is more than one
interpretation of the specification with regard to L, S, and to a lesser
extent Z.  Can the authors comment on what the intent of the specification
was and then perhaps we can reach some conclusion?

Here is a partial list of odd digitmaps that seem to defy interpretation: 
        "123Z"                          - "Z" ignored or error? 
[KJBII] Z here has nothing to modify.  Error. 

        "123S"                  - "S" (or "L") ignored or error? 
[KJBII] In this instance, the digitmap switches to short interdigit timing
after detecting "123".  So, neither. 

        "1ZZ23"                 - First "Z" ignored or error? 
[KJBII] Because Z is defined as modifying the following digit, and Z cannot
modify Z, this should be an error. 

        "1ZSSSSSSSSS23"         - "Z" applied to the "2" or ignored or
error? 
[KJBII] See above.  Error as Z cannot modify S (or L). 

        "135[2Z46]"                     - "Z" applied to "4" or to all in
the range (246) or ignored or error? 
[KJBII] Z applies solely to the 4 here. 

        "135[246Z]79"           - "Z" applied to "7" or ignored or error? 
[KJBII] Nothing for Z to modify.  Error. 

        "135[2S46]"                     - "S" (or "L") applied to all in
range (246) or ignored or error? 
[KJBII] This is the root of our earlier discussion.  L and S do not modify
digits -- they modify timing strategy for the digitmap at the time they are
encountered.  [246] means "match 2, 4 or 6".  So [2S46] means... What
exactly? "Match 2, short timeout, 4 or 6"?  Or "match 2, 4 or 6 while
running the short timer for this digit only"?  Or "run the short timer S
after detecting 2, but not if 4 or 6 is detected"?  If the string were
"135S[246]" then we would start using the short timer before looking for 2,
4 or 6.  If it were "135[246]S", we would start using the short timer AFTER
matching 2, 4 or 6.  But, with the S timer INSIDE the range, that would
indicate that the timer would have to fire to continue.  For instance, if
the string were "135[2S46]79", that would seem to indicate that if NO digit
was detected for the duration of the short timer, then we should continue
with the string to find 7.  This is a contrary usage to S and L at any other
point in a digitmap.  I think S and L should be ignored within ranges.  If
the MGC wants to use the S or L timer, then put them outside the range.

        "135[2L4S6]"            - "L" or "S" applied or both (somehow?) or
ignored or error? 
[KJBII] See above -- the same arguments apply here.  I would note that L
would never get "detected" here, since S would match first.

Thanks, 
--Stephen 

        

> -----Original Message----- 
> From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
> Sent: Monday, December 01, 2003 8:01 PM 
> To: 'Troy Cauble'; Kevin Boyle 
> Cc: megaco@ietf.org 
> Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
> Timers ( L), & Short T imers (S) 
> 
> 
> Part of the problem is the term "alternatives" is not clear.  
> The text in 
> 7.1.14.3 says of "alternatives": 
> A DigitMap, according to this syntax, is defined either by a string or 
> by a list of strings.  Each string in the list is an alternative event 
> sequence, specified either as a sequence of digit map symbols or as a 
> regular expression of digit map symbols. 
> 
> My reading of this is that "alternatives" are each string and not the 
> possible sequences through a range, but admittedly this is not clear. 
> 
> The section doesn't seem to explain other odd sequences like "123Z". 
> Presumably the "Z" is simply ignored although an error could also be 
> considered the proper outcome. 
> 
> I must say I prefer an interpretation in which the number of possible 
> ways to perform the same action is as close to 1 and possible. 
> Therefore, I'd 
> prefer to ban (or at least ignore) "L" and "S" within ranges. 
> 
> --Stephen 
> 
> > -----Original Message----- 
> > From: Troy Cauble [ mailto:troy@bell-labs.com
<mailto:troy@bell-labs.com> ] 
> > Sent: Monday, December 01, 2003 6:33 PM 
> > To: Kevin Boyle 
> > Cc: megaco@ietf.org 
> > Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
> > Timers ( L), & Short T imers (S) 
> > 
> > 
> > 
> > 
> > I disagree that "L" and "S" are meaningless within a range. 
> > 
> > "L" and "S" are used to specify the timer used for "subsequent 
> > events". 
> > 
> > I would argue that the "5" is a subsequent event in "[34L]5", just 
> > as it is in "[34]L5". 
> > 
> > I would also argue that the "4" in "[3L4]5" is NOT a "subsequent 
> > event", although one might debate the definition of "subsequent". 
> > 
> > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and 
> "[34]L5" are all 
> > the same. (And the "L" is not meaningless.) 
> > 
> > 
> > Note that section 7.1.14.3 does bother to specify what happens when 
> > explicit timing specifiers are only active in some "alternatives", 
> or when they 
> > differ in among alternatives -- the same timer value is used for all 
> > alternatives. 
> > 
> > 
> > 7.1.14.3: 
> > 
> >  > In addition to these event symbols, the string may contain "S" 
> > and "L" 
> >  > inter-event timing specifiers and the "Z" duration modifier. "S" 
> > and "L" 
> >  > respectively indicate that the MG should use the short (S) timer 
> > or the  > long (L) timer for subsequent events, overriding the 
> > timing rules  > described above. If an explicit timing specifier is 
> > in effect in one  > alternative event sequence, but none is given in 
> > any other candidate  > alternative, the timer value set by the 
> > explicit timing specifier must be  > used. If all sequences with 
> > explicit timing controls are dropped from the  > candidate set, 
> > timing reverts to the default rules given above. Finally,  > if 
> > conflicting timing specifiers are in effect in different alternative  
> > > sequences, the long timer shall be used. 
> > 
> > 
> > -troy 
> > 
> > 
> > 
> > Kevin Boyle wrote: 
> > 
> > > Since a range means "match one of these", I would agree 
> > with the assessment 
> > > that L and S are meaningless within a range. 
> > >  
> > > Kevin 
> > > 
> > > 
> > >   _____ 
> > > 
> > > From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
> > > Sent: Monday, December 01, 2003 5:22 PM 
> > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org 
> > > Subject: RE: [Megaco] Digit Maps: Long Duration 
> > Modifier(Z), Long Timers ( 
> > > L), & Short T imers (S) 
> > > 
> > > 
> > > Thanks for the feedback.  
> > >  
> > > Just to make sure I understand the L and S cases: 
> > > They are syntactically legal in a range specification, but 
> > semantically they 
> > > have no effect.  Correct? 
> > >  
> > > --Stephen 
> > > 
> > > -----Original Message----- 
> > > From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 
> > > Sent: Monday, December 01, 2003 5:15 PM 
> > > To: Steve Cipolli; megaco@ietf.org 
> > > Subject: RE: [Megaco] Digit Maps: Long Duration 
> > Modifier(Z), Long Timers ( 
> > > L), & Short T imers (S) 
> > > 
> > > 
> > > Your interpretation is correct.  Because Z changes how a 
> > digit is matched, 
> > > it makes sense within a range.  Think of Z as part of the 
> > digit it modifies, 
> > > rather than a separate symbol. 
> > >  
> > > The L and S timers within a digitmap give specific 
> > instruction as to which 
> > > timer to run at that point in the digitmap.  While allowed 
> > in a range, I 
> > > don't think they provide much value within a range since 
> they do not 
> > > actually match anything.  For effective use, they should be 
> > outside the 
> > > range. 
> > >  
> > > Kevin 
> > > 
> > > 
> > >   _____ 
> > > 
> > > From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
> > > Sent: Monday, December 01, 2003 3:26 PM 
> > > To: megaco@ietf.org 
> > > Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), 
> > Long Timers (L), & 
> > > Short T imers (S) 
> > > 
> > > 
> > >  
> > > According to the syntax in RFCs 3015 & 3525 the long 
> > duration modifier (Z), 
> > > Long Timers (L), & Short Timers (S) in digit maps can 
> > appear in a digit 
> > > range.  For example (where Z is 1000ms): 
> > >     "135[2Z46]" 
> > >  
> > > Is this valid?  If it is valid, does this mean that the 
> > fourth digit event 
> > > must be either 2, 6 (held for any duration) or 4 held for 1000 ms? 
> > >  
> > > How does long timer (L) and short timer (S) in a digit 
> range apply? 
> > >  
> > > --Stephen 
> > >  
> > >  
> > > 
> > > 
> > > _______________________________________________ 
> > > 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
<https://www1.ietf.org/mailman/listinfo/megaco>  
> > 
> 
> 
> _______________________________________________ 
> Megaco mailing list 
> Megaco@ietf.org 
> https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  
> 


------_=_NextPart_001_01C3BB5A.E22F5770
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] Digit Maps: Long Duration Modifier(Z), Long Timers ( L), & Short T imers (S)</TITLE>

<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=456500318-05122003><FONT face=Arial color=#0000ff size=2>While 
I tend to agree with most of&nbsp;the answers below, I don't see any of this 
specified in the specification.&nbsp; If we can agree that the answers below are 
the correct interpretation, then we still need clarification in the spec or 
implementors guide.&nbsp; I'm still hoping the original author of this section 
of the spec will clarify the original intention.</FONT></SPAN></DIV>
<DIV><SPAN class=456500318-05122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=456500318-05122003><FONT face=Arial color=#0000ff 
size=2>--Stephen</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; 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, December 02, 2003 
  3:18 PM<BR><B>To:</B> Steve Cipolli; 'Troy Cauble'<BR><B>Cc:</B> 
  megaco@ietf.org<BR><B>Subject:</B> RE: [Megaco] Digit Maps: Long Duration 
  Modifier(Z), Long Timers ( L), &amp; Short T imers (S)<BR><BR></FONT></DIV>
  <P><FONT size=2>Comments inline. [KJBII]</FONT> </P>
  <P><FONT size=2>Kevin </FONT></P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Steve 
  Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR><FONT size=2>Sent: Tuesday, December 02, 2003 2:40 PM</FONT> 
  <BR><FONT size=2>To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH]</FONT> 
  <BR><FONT size=2>Cc: megaco@ietf.org</FONT> <BR><FONT size=2>Subject: RE: 
  [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers ( L), &amp; Short 
  T imers (S)</FONT> </P>
  <P><FONT size=2>Perhaps I moved us off track a bit.&nbsp; It is clear that 
  there is more than one interpretation of the specification with regard to L, 
  S, and to a lesser extent Z.&nbsp; Can the authors comment on what the intent 
  of the specification was and then perhaps we can reach some 
  conclusion?</FONT></P>
  <P><FONT size=2>Here is a partial list of odd digitmaps that seem to defy 
  interpretation:</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>"123Z"&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "Z" ignored or error?</FONT> 
  <BR><FONT size=2>[KJBII] Z here has nothing to modify.&nbsp; Error.</FONT> 
</P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>"123S"&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "S" (or "L") ignored or 
  error?</FONT> <BR><FONT size=2>[KJBII] In this instance, the digitmap switches 
  to short interdigit timing after detecting "123".&nbsp; So, neither.</FONT> 
  </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>"1ZZ23" 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - First "Z" ignored or 
  error?</FONT> <BR><FONT size=2>[KJBII] Because Z is defined as modifying the 
  following digit, and Z cannot modify Z, this should be an error.</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>"1ZSSSSSSSSS23" 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "Z" applied to the "2" or ignored 
  or error?</FONT> <BR><FONT size=2>[KJBII] See above.&nbsp; Error as Z cannot 
  modify S (or L).</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>"135[2Z46]"&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "Z" applied to "4" or to all in 
  the range (246) or ignored or error?</FONT> <BR><FONT size=2>[KJBII] Z applies 
  solely to the 4 here.</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>"135[246Z]79"&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 
  "Z" applied to "7" or ignored or error?</FONT> <BR><FONT size=2>[KJBII] 
  Nothing for Z to modify.&nbsp; Error.</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>"135[2S46]"&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "S" (or "L") applied to all in 
  range (246) or ignored or error?</FONT> <BR><FONT size=2>[KJBII] This is the 
  root of our earlier discussion.&nbsp; L and S do not modify digits -- they 
  modify timing strategy for the digitmap at the time they are 
  encountered.&nbsp; [246] means "match 2, 4 or 6".&nbsp; So [2S46] means... 
  What exactly? "Match 2, short timeout, 4 or 6"?&nbsp; Or "match 2, 4 or 6 
  while running the short timer for this digit only"?&nbsp; Or "run the short 
  timer S after detecting 2, but not if 4 or 6 is detected"?&nbsp; If the string 
  were "135S[246]" then we would start using the short timer before looking for 
  2, 4 or 6.&nbsp; If it were "135[246]S", we would start using the short timer 
  AFTER matching 2, 4 or 6.&nbsp; But, with the S timer INSIDE the range, that 
  would indicate that the timer would have to fire to continue.&nbsp; For 
  instance, if the string were "135[2S46]79", that would seem to indicate that 
  if NO digit was detected for the duration of the short timer, then we should 
  continue with the string to find 7.&nbsp; This is a contrary usage to S and L 
  at any other point in a digitmap.&nbsp; I think S and L should be ignored 
  within ranges.&nbsp; If the MGC wants to use the S or L timer, then put them 
  outside the range.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>"135[2L4S6]"&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "L" or "S" applied or both 
  (somehow?) or ignored or error?</FONT> <BR><FONT size=2>[KJBII] See above -- 
  the same arguments apply here.&nbsp; I would note that L would never get 
  "detected" here, since S would match first.</FONT></P>
  <P><FONT size=2>Thanks,</FONT> <BR><FONT size=2>--Stephen</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Steve Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: Monday, December 01, 2003 8:01 PM</FONT> <BR><FONT 
  size=2>&gt; To: 'Troy Cauble'; Kevin Boyle</FONT> <BR><FONT size=2>&gt; Cc: 
  megaco@ietf.org</FONT> <BR><FONT size=2>&gt; Subject: RE: [Megaco] Digit Maps: 
  Long Duration Modifier(Z), Long </FONT><BR><FONT size=2>&gt; Timers ( L), 
  &amp; Short T imers (S)</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; Part of the problem is the term 
  "alternatives" is not clear.&nbsp; </FONT><BR><FONT size=2>&gt; The text 
  in</FONT> <BR><FONT size=2>&gt; 7.1.14.3 says of "alternatives":</FONT> 
  <BR><FONT size=2>&gt; A DigitMap, according to this syntax, is defined either 
  by a string or </FONT><BR><FONT size=2>&gt; by a list of strings.&nbsp; Each 
  string in the list is an alternative event </FONT><BR><FONT size=2>&gt; 
  sequence, specified either as a sequence of digit map symbols or as a 
  </FONT><BR><FONT size=2>&gt; regular expression of digit map symbols.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; My reading of this is that 
  "alternatives" are each string and not the </FONT><BR><FONT size=2>&gt; 
  possible sequences through a range, but admittedly this is not clear.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; The section doesn't seem to 
  explain other odd sequences like "123Z".</FONT> <BR><FONT size=2>&gt; 
  Presumably the "Z" is simply ignored although an error could also be 
  </FONT><BR><FONT size=2>&gt; considered the proper outcome.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; I must say I prefer an interpretation 
  in which the number of possible </FONT><BR><FONT size=2>&gt; ways to perform 
  the same action is as close to 1 and possible.</FONT> <BR><FONT size=2>&gt; 
  Therefore, I'd</FONT> <BR><FONT size=2>&gt; prefer to ban (or at least ignore) 
  "L" and "S" within ranges.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; --Stephen</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; 
  From: Troy Cauble [<A 
  href="mailto:troy@bell-labs.com">mailto:troy@bell-labs.com</A>]</FONT> 
  <BR><FONT size=2>&gt; &gt; Sent: Monday, December 01, 2003 6:33 PM</FONT> 
  <BR><FONT size=2>&gt; &gt; To: Kevin Boyle</FONT> <BR><FONT size=2>&gt; &gt; 
  Cc: megaco@ietf.org</FONT> <BR><FONT size=2>&gt; &gt; Subject: Re: [Megaco] 
  Digit Maps: Long Duration Modifier(Z), Long </FONT><BR><FONT size=2>&gt; &gt; 
  Timers ( L), &amp; Short T imers (S)</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; I disagree 
  that "L" and "S" are meaningless within a range.</FONT> <BR><FONT size=2>&gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt; "L" and "S" are used to specify the 
  timer used for "subsequent </FONT><BR><FONT size=2>&gt; &gt; events".</FONT> 
  <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; I would argue 
  that the "5" is a subsequent event in "[34L]5", just </FONT><BR><FONT 
  size=2>&gt; &gt; as it is in "[34]L5".</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; I would also argue that the "4" in "[3L4]5" 
  is NOT a "subsequent </FONT><BR><FONT size=2>&gt; &gt; event", although one 
  might debate the definition of "subsequent".</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; In summary, I think "[L34]5", "[3L4]5", 
  "[34L]5", and</FONT> <BR><FONT size=2>&gt; "[34]L5" are all</FONT> <BR><FONT 
  size=2>&gt; &gt; the same. (And the "L" is not meaningless.)</FONT> <BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; Note that section 7.1.14.3 does bother to specify what 
  happens when </FONT><BR><FONT size=2>&gt; &gt; explicit timing specifiers are 
  only active in some "alternatives",</FONT> <BR><FONT size=2>&gt; or when 
  they</FONT> <BR><FONT size=2>&gt; &gt; differ in among alternatives -- the 
  same timer value is used for all </FONT><BR><FONT size=2>&gt; &gt; 
  alternatives.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt; 7.1.14.3:</FONT> <BR><FONT size=2>&gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt;&nbsp; &gt; In addition to these event 
  symbols, the string may contain "S" </FONT><BR><FONT size=2>&gt; &gt; and 
  "L"</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt; inter-event timing specifiers 
  and the "Z" duration modifier. "S" </FONT><BR><FONT size=2>&gt; &gt; and 
  "L"</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt; respectively indicate that 
  the MG should use the short (S) timer </FONT><BR><FONT size=2>&gt; &gt; or 
  the&nbsp; &gt; long (L) timer for subsequent events, overriding the 
  </FONT><BR><FONT size=2>&gt; &gt; timing rules&nbsp; &gt; described above. If 
  an explicit timing specifier is </FONT><BR><FONT size=2>&gt; &gt; in effect in 
  one&nbsp; &gt; alternative event sequence, but none is given in 
  </FONT><BR><FONT size=2>&gt; &gt; any other candidate&nbsp; &gt; alternative, 
  the timer value set by the </FONT><BR><FONT size=2>&gt; &gt; explicit timing 
  specifier must be&nbsp; &gt; used. If all sequences with </FONT><BR><FONT 
  size=2>&gt; &gt; explicit timing controls are dropped from the&nbsp; &gt; 
  candidate set, </FONT><BR><FONT size=2>&gt; &gt; timing reverts to the default 
  rules given above. Finally,&nbsp; &gt; if </FONT><BR><FONT size=2>&gt; &gt; 
  conflicting timing specifiers are in effect in different alternative&nbsp; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; sequences, the long timer shall be 
  used.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; -troy</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; Kevin Boyle wrote:</FONT> <BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; Since a range means 
  "match one of these", I would agree</FONT> <BR><FONT size=2>&gt; &gt; with the 
  assessment</FONT> <BR><FONT size=2>&gt; &gt; &gt; that L and S are meaningless 
  within a range.</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; Kevin</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  &gt;&nbsp;&nbsp; _____</FONT> <BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; From: Steve Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>]</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; Sent: Monday, December 01, 2003 5:22 PM</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 
  megaco@ietf.org</FONT> <BR><FONT size=2>&gt; &gt; &gt; Subject: RE: [Megaco] 
  Digit Maps: Long Duration</FONT> <BR><FONT size=2>&gt; &gt; Modifier(Z), Long 
  Timers (</FONT> <BR><FONT size=2>&gt; &gt; &gt; L), &amp; Short T imers 
  (S)</FONT> <BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; Thanks for the feedback.&nbsp; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; 
  &gt; Just to make sure I understand the L and S cases:</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; They are syntactically legal in a range specification, 
  but</FONT> <BR><FONT size=2>&gt; &gt; semantically they</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; have no effect.&nbsp; Correct?</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  --Stephen</FONT> <BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; 
  &gt; &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  From: Kevin Boyle [<A 
  href="mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.com</A>]</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; Sent: Monday, December 01, 2003 5:15 PM</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; To: Steve Cipolli; megaco@ietf.org</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; Subject: RE: [Megaco] Digit Maps: Long 
  Duration</FONT> <BR><FONT size=2>&gt; &gt; Modifier(Z), Long Timers (</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; L), &amp; Short T imers (S)</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; Your interpretation is correct.&nbsp; Because Z changes 
  how a</FONT> <BR><FONT size=2>&gt; &gt; digit is matched,</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; it makes sense within a range.&nbsp; Think of Z as part 
  of the</FONT> <BR><FONT size=2>&gt; &gt; digit it modifies,</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; rather than a separate symbol.</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; &gt; The L and S 
  timers within a digitmap give specific</FONT> <BR><FONT size=2>&gt; &gt; 
  instruction as to which</FONT> <BR><FONT size=2>&gt; &gt; &gt; timer to run at 
  that point in the digitmap.&nbsp; While allowed</FONT> <BR><FONT size=2>&gt; 
  &gt; in a range, I</FONT> <BR><FONT size=2>&gt; &gt; &gt; don't think they 
  provide much value within a range since</FONT> <BR><FONT size=2>&gt; they do 
  not</FONT> <BR><FONT size=2>&gt; &gt; &gt; actually match anything.&nbsp; For 
  effective use, they should be</FONT> <BR><FONT size=2>&gt; &gt; outside 
  the</FONT> <BR><FONT size=2>&gt; &gt; &gt; range.</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; &gt; Kevin</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt;&nbsp;&nbsp; _____</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; From: Steve Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>]</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; Sent: Monday, December 01, 2003 3:26 PM</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; To: megaco@ietf.org</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; Subject: [Megaco] Digit Maps: Long Duration 
  Modifier(Z),</FONT> <BR><FONT size=2>&gt; &gt; Long Timers (L), &amp;</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; Short T imers (S)</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; 
  &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; &gt; According to the syntax 
  in RFCs 3015 &amp; 3525 the long</FONT> <BR><FONT size=2>&gt; &gt; duration 
  modifier (Z),</FONT> <BR><FONT size=2>&gt; &gt; &gt; Long Timers (L), &amp; 
  Short Timers (S) in digit maps can</FONT> <BR><FONT size=2>&gt; &gt; appear in 
  a digit</FONT> <BR><FONT size=2>&gt; &gt; &gt; range.&nbsp; For example (where 
  Z is 1000ms):</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2Z46]"</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; Is this valid?&nbsp; If it is valid, does this mean that 
  the</FONT> <BR><FONT size=2>&gt; &gt; fourth digit event</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; must be either 2, 6 (held for any duration) or 4 held 
  for 1000 ms?</FONT> <BR><FONT size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; How does long timer (L) and short timer (S) in a 
  digit</FONT> <BR><FONT size=2>&gt; range apply?</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; &gt; --Stephen</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; 
  &gt;&nbsp; </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; 
  &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; Megaco mailing list</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  Megaco@ietf.org</FONT> <BR><FONT size=2>&gt; &gt; &gt; <A 
  href="https://www1.ietf.org/mailman/listinfo/megaco" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> 
  <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  &gt; Megaco mailing list</FONT> <BR><FONT size=2>&gt; &gt; 
  Megaco@ietf.org</FONT> <BR><FONT size=2>&gt; &gt; <A 
  href="https://www1.ietf.org/mailman/listinfo/megaco" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> 
  <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  Megaco mailing list</FONT> <BR><FONT size=2>&gt; Megaco@ietf.org</FONT> 
  <BR><FONT size=2>&gt; <A href="https://www1.ietf.org/mailman/listinfo/megaco" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> 
  <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3BB5A.E22F5770--


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



From megaco-admin@ietf.org  Fri Dec  5 15:32:17 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23895
	for <megaco-archive@lists.ietf.org>; Fri, 5 Dec 2003 15:32:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASMcL-0004AV-J5; Fri, 05 Dec 2003 15:32:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASMcC-00047Q-Iu
	for megaco@optimus.ietf.org; Fri, 05 Dec 2003 15:31:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23867
	for <megaco@ietf.org>; Fri, 5 Dec 2003 15:31:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASMcB-0001QM-00
	for megaco@ietf.org; Fri, 05 Dec 2003 15:31:51 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASMcA-0001Oq-00
	for megaco@ietf.org; Fri, 05 Dec 2003 15:31:50 -0500
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 hB5KVEm12595
	for <megaco@ietf.org>; Fri, 5 Dec 2003 15:31:14 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1VX5M>; Fri, 5 Dec 2003 15:31:14 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D0808B2@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Troy Cauble <troy@bell-labs.com>, MEGACO list <megaco@ietf.org>
Subject: RE: [Megaco] wildcarded responses
Date: Fri, 5 Dec 2003 15:31:10 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

No.  Section 8 says that you return explicit command replies for each term
(in this case, for each term in NULL).

Kevin

-----Original Message-----
From: Troy Cauble [mailto:troy@bell-labs.com] 
Sent: Thursday, December 04, 2003 5:32 PM
To: MEGACO list
Subject: [Megaco] wildcarded responses


Can wildcarded responses be returned if they weren't explicitly requested
with a "W-" form?

Specifically, can an MG answer the following with a wildcarded response?

	Transaction = 110 { Context = - { Modify = * {
			Events = 1 { al/of }}}}

-troy




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

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


From exim@www1.ietf.org  Fri Dec  5 15:32:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23921
	for <megaco-archive@odin.ietf.org>; Fri, 5 Dec 2003 15:32:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASMcN-0004BB-Aa
	for megaco-archive@odin.ietf.org; Fri, 05 Dec 2003 15:32:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5KW3Ts016059
	for megaco-archive@odin.ietf.org; Fri, 5 Dec 2003 15:32:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASMcN-0004Aw-5v
	for megaco-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 15:32:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23875
	for <megaco-web-archive@ietf.org>; Fri, 5 Dec 2003 15:31:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASMcL-0001QZ-00
	for megaco-web-archive@ietf.org; Fri, 05 Dec 2003 15:32:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASMcL-0001QW-00
	for megaco-web-archive@ietf.org; Fri, 05 Dec 2003 15:32:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASMcL-0004AV-J5; Fri, 05 Dec 2003 15:32:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASMcC-00047Q-Iu
	for megaco@optimus.ietf.org; Fri, 05 Dec 2003 15:31:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23867
	for <megaco@ietf.org>; Fri, 5 Dec 2003 15:31:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASMcB-0001QM-00
	for megaco@ietf.org; Fri, 05 Dec 2003 15:31:51 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASMcA-0001Oq-00
	for megaco@ietf.org; Fri, 05 Dec 2003 15:31:50 -0500
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 hB5KVEm12595
	for <megaco@ietf.org>; Fri, 5 Dec 2003 15:31:14 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1VX5M>; Fri, 5 Dec 2003 15:31:14 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D0808B2@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Troy Cauble <troy@bell-labs.com>, MEGACO list <megaco@ietf.org>
Subject: RE: [Megaco] wildcarded responses
Date: Fri, 5 Dec 2003 15:31:10 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

No.  Section 8 says that you return explicit command replies for each term
(in this case, for each term in NULL).

Kevin

-----Original Message-----
From: Troy Cauble [mailto:troy@bell-labs.com] 
Sent: Thursday, December 04, 2003 5:32 PM
To: MEGACO list
Subject: [Megaco] wildcarded responses


Can wildcarded responses be returned if they weren't explicitly requested
with a "W-" form?

Specifically, can an MG answer the following with a wildcarded response?

	Transaction = 110 { Context = - { Modify = * {
			Events = 1 { al/of }}}}

-troy




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

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



From megaco-admin@ietf.org  Sun Dec  7 11:09:17 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26897
	for <megaco-archive@lists.ietf.org>; Sun, 7 Dec 2003 11:09:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AT1Sv-0000cp-Bg; Sun, 07 Dec 2003 11:09:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AT1S2-0000cG-6V
	for megaco@optimus.ietf.org; Sun, 07 Dec 2003 11:08:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26884
	for <megaco@ietf.org>; Sun, 7 Dec 2003 11:07:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AT1Rz-0002T8-00
	for megaco@ietf.org; Sun, 07 Dec 2003 11:08:03 -0500
Received: from [207.191.111.15] (helo=iconsis.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AT1Ry-0002Sz-00
	for megaco@ietf.org; Sun, 07 Dec 2003 11:08:03 -0500
Received: from w1x6d9 [202.88.38.28] by iconsis.com with ESMTP
  (SMTPD32-7.12     ) id A06014046A; Sun, 07 Dec 2003 10:08:00 -0600
Reply-To: <bilgrami@variationtechnologies.com>
From: "Asif Bilgrami" <bilgrami@variationtechnologies.com>
To: <megaco@ietf.org>
Date: Sun, 7 Dec 2003 21:13:01 +0500
Message-ID: <MCBBJOMBONBELDDFNFGDOEFKCAAA.bilgrami@variationtechnologies.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.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 7bit
Subject: [Megaco] CTSQL Flow Suite For IVR
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

We have upgraded our product "CTSQL Flow Suite" to support more features.

Create IVR Flow using CTEditor in minutes or modify existing template to
meet your needs.

Now same CTServer supports T1 (ISDN and Robbed Bit),E1 and Analog Dialogic
cards.

CTSQL Flow Suite provides same features to implement IVR Flow in lower cost
which other
provides at higher costs.

For details have a look at: http://www.variationtechnologies.com/aboutct.htm

For Supported Functions have a look at:
http://www.variationtechnologies.com/functions.htm

For Supported Events have a look at:
http://www.variationtechnologies.com/events.htm


Voice Mail Flow is included as demo.

Find out how to run Voice Mail demo for Analog,T1 or E1:

http://www.variationtechnologies.com/demo.htm

That means once you have created IVR Flow, it can be implemented for variety
of protocols.


Download your free evaluation copy now including Voice Mail demo.


Regards

Marketing Department

Variation Technologies



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


From exim@www1.ietf.org  Sun Dec  7 11:09:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26912
	for <megaco-archive@odin.ietf.org>; Sun, 7 Dec 2003 11:09:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AT1Sy-0000df-2f
	for megaco-archive@odin.ietf.org; Sun, 07 Dec 2003 11:09:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7G94Ax002449
	for megaco-archive@odin.ietf.org; Sun, 7 Dec 2003 11:09:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AT1Sx-0000dQ-UA
	for megaco-web-archive@optimus.ietf.org; Sun, 07 Dec 2003 11:09:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26894
	for <megaco-web-archive@ietf.org>; Sun, 7 Dec 2003 11:08:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AT1Sv-0002TY-00
	for megaco-web-archive@ietf.org; Sun, 07 Dec 2003 11:09:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AT1Su-0002TU-00
	for megaco-web-archive@ietf.org; Sun, 07 Dec 2003 11:09:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AT1Sv-0000cp-Bg; Sun, 07 Dec 2003 11:09:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AT1S2-0000cG-6V
	for megaco@optimus.ietf.org; Sun, 07 Dec 2003 11:08:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26884
	for <megaco@ietf.org>; Sun, 7 Dec 2003 11:07:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AT1Rz-0002T8-00
	for megaco@ietf.org; Sun, 07 Dec 2003 11:08:03 -0500
Received: from [207.191.111.15] (helo=iconsis.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AT1Ry-0002Sz-00
	for megaco@ietf.org; Sun, 07 Dec 2003 11:08:03 -0500
Received: from w1x6d9 [202.88.38.28] by iconsis.com with ESMTP
  (SMTPD32-7.12     ) id A06014046A; Sun, 07 Dec 2003 10:08:00 -0600
Reply-To: <bilgrami@variationtechnologies.com>
From: "Asif Bilgrami" <bilgrami@variationtechnologies.com>
To: <megaco@ietf.org>
Date: Sun, 7 Dec 2003 21:13:01 +0500
Message-ID: <MCBBJOMBONBELDDFNFGDOEFKCAAA.bilgrami@variationtechnologies.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.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 7bit
Subject: [Megaco] CTSQL Flow Suite For IVR
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

We have upgraded our product "CTSQL Flow Suite" to support more features.

Create IVR Flow using CTEditor in minutes or modify existing template to
meet your needs.

Now same CTServer supports T1 (ISDN and Robbed Bit),E1 and Analog Dialogic
cards.

CTSQL Flow Suite provides same features to implement IVR Flow in lower cost
which other
provides at higher costs.

For details have a look at: http://www.variationtechnologies.com/aboutct.htm

For Supported Functions have a look at:
http://www.variationtechnologies.com/functions.htm

For Supported Events have a look at:
http://www.variationtechnologies.com/events.htm


Voice Mail Flow is included as demo.

Find out how to run Voice Mail demo for Analog,T1 or E1:

http://www.variationtechnologies.com/demo.htm

That means once you have created IVR Flow, it can be implemented for variety
of protocols.


Download your free evaluation copy now including Voice Mail demo.


Regards

Marketing Department

Variation Technologies



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



From megaco-admin@ietf.org  Sun Dec  7 23:59:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13396
	for <megaco-archive@lists.ietf.org>; Sun, 7 Dec 2003 23:59:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDU5-00046t-Hj; Sun, 07 Dec 2003 23:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDTs-00046c-QZ
	for megaco@optimus.ietf.org; Sun, 07 Dec 2003 23:58:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13373
	for <Megaco@ietf.org>; Sun, 7 Dec 2003 23:58:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDTq-0004Uu-00
	for Megaco@ietf.org; Sun, 07 Dec 2003 23:58:46 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDTp-0004Up-00
	for Megaco@ietf.org; Sun, 07 Dec 2003 23:58:45 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hB84t4v18937;
	Mon, 8 Dec 2003 15:55:05 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.150]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YHH39ZZ7; Mon, 8 Dec 2003 15:56:59 +1100
Message-ID: <3FD4044D.9090502@ericsson.com>
Date: Mon, 08 Dec 2003 15:55:41 +1100
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: Pascal Lambers <pascal.lambers@pandora.be>
CC: Tom Taylor <taylor@nortelnetworks.com>,
        Madhubabu Brahmanapally <Madhubabu@veraznet.com>, Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question
References: <9E388C880C1ED411AFE1009027E787250526F0AA@mail.veraznet.com> <3FCFC3D7.8000501@nortelnetworks.com> <001901c3bb06$1b3ebc40$b400a8c0@pandora.be>
In-Reply-To: <001901c3bb06$1b3ebc40$b400a8c0@pandora.be>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hello Pascal,

I think you have pointed out an issue for the Implementors' Guide. This fact 
that the Local Control Mode overrides the SDP is common practise the only 
problem is that it is not clearly stated.

I would propose that :
7.1.7	LocalControl descriptor
...
The allowed values for the mode property are send-only, receive-only, 
send/receive, inactive and loop-back. "Send" and "receive" are with respect to 
the exterior of the Context, so that, for example, a stream set to mode = 
sendOnly does not pass received media into the Context. The default value for 
the mode property is "Inactive". Signals and Events are not affected by mode.
 >>> The local control mode property takes precedence over the local and remote 
descriptors.<<<
...

Regards, Christian

Pascal Lambers wrote:

> So would I, but isn't there any RFC statement to enforce this opinion?
> 
> Pascal
> 
> 
> ----- Original Message ----- 
> From: "Tom Taylor" <taylor@nortelnetworks.com>
> To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
> Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>
> Sent: Friday, December 05, 2003 12:31 AM
> Subject: Re: [Megaco] SDP mode and Megaco mode question
> 
> 
> 
>>I would put it bluntly that the MG must ignore mode in the SDP.
>>
>>Madhubabu Brahmanapally wrote:
>>
>>
>>>The Local Control Descriptor has high precedence over the SDP
>>>information....
>>>
>>>    -----Original Message-----
>>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
>>>    *Sent:* Thursday, December 04, 2003 3:05 PM
>>>    *To:* Megaco@ietf.org
>>>    *Subject:* [Megaco] SDP mode and Megaco mode question
>>>
>>>    Hello,
>>>
>>>    Don't know precisely how to forumulate this question clearly, so let
>>>    me put in in two different ways...
>>>
>>>    What does a MG have to do if an MGC sends a Modify with:
>>>    - the Mode property of the LocalControl descriptor set to, for
>>>    instance, receive-only;
>>>    - a Local/Remote Descriptor with an SDP-block containing an
>>>    "a=sendrecv" parameter?
>>>
>>>    In other words, what is the relation beween the a=sendrecv,
>>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP protocol
>>>    and the Mode property of the LocalControl descriptor in the Megaco
>>>    protocol?
>>>
>>>
>>>    Can sb give some advise? Thanks!
>>>    Pascal
>>>
>>>
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
> 
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


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


From exim@www1.ietf.org  Sun Dec  7 23:59:25 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13411
	for <megaco-archive@odin.ietf.org>; Sun, 7 Dec 2003 23:59:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDUD-00048L-MV
	for megaco-archive@odin.ietf.org; Sun, 07 Dec 2003 23:59:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB84x980015885
	for megaco-archive@odin.ietf.org; Sun, 7 Dec 2003 23:59:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDUD-000488-Hi
	for megaco-web-archive@optimus.ietf.org; Sun, 07 Dec 2003 23:59:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13377
	for <megaco-web-archive@ietf.org>; Sun, 7 Dec 2003 23:58:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDUB-0004V1-00
	for megaco-web-archive@ietf.org; Sun, 07 Dec 2003 23:59:07 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDUA-0004Uy-00
	for megaco-web-archive@ietf.org; Sun, 07 Dec 2003 23:59:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDU5-00046t-Hj; Sun, 07 Dec 2003 23:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDTs-00046c-QZ
	for megaco@optimus.ietf.org; Sun, 07 Dec 2003 23:58:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13373
	for <Megaco@ietf.org>; Sun, 7 Dec 2003 23:58:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDTq-0004Uu-00
	for Megaco@ietf.org; Sun, 07 Dec 2003 23:58:46 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDTp-0004Up-00
	for Megaco@ietf.org; Sun, 07 Dec 2003 23:58:45 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hB84t4v18937;
	Mon, 8 Dec 2003 15:55:05 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.150]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YHH39ZZ7; Mon, 8 Dec 2003 15:56:59 +1100
Message-ID: <3FD4044D.9090502@ericsson.com>
Date: Mon, 08 Dec 2003 15:55:41 +1100
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: Pascal Lambers <pascal.lambers@pandora.be>
CC: Tom Taylor <taylor@nortelnetworks.com>,
        Madhubabu Brahmanapally <Madhubabu@veraznet.com>, Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question
References: <9E388C880C1ED411AFE1009027E787250526F0AA@mail.veraznet.com> <3FCFC3D7.8000501@nortelnetworks.com> <001901c3bb06$1b3ebc40$b400a8c0@pandora.be>
In-Reply-To: <001901c3bb06$1b3ebc40$b400a8c0@pandora.be>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Pascal,

I think you have pointed out an issue for the Implementors' Guide. This fact 
that the Local Control Mode overrides the SDP is common practise the only 
problem is that it is not clearly stated.

I would propose that :
7.1.7	LocalControl descriptor
...
The allowed values for the mode property are send-only, receive-only, 
send/receive, inactive and loop-back. "Send" and "receive" are with respect to 
the exterior of the Context, so that, for example, a stream set to mode = 
sendOnly does not pass received media into the Context. The default value for 
the mode property is "Inactive". Signals and Events are not affected by mode.
 >>> The local control mode property takes precedence over the local and remote 
descriptors.<<<
...

Regards, Christian

Pascal Lambers wrote:

> So would I, but isn't there any RFC statement to enforce this opinion?
> 
> Pascal
> 
> 
> ----- Original Message ----- 
> From: "Tom Taylor" <taylor@nortelnetworks.com>
> To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
> Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>
> Sent: Friday, December 05, 2003 12:31 AM
> Subject: Re: [Megaco] SDP mode and Megaco mode question
> 
> 
> 
>>I would put it bluntly that the MG must ignore mode in the SDP.
>>
>>Madhubabu Brahmanapally wrote:
>>
>>
>>>The Local Control Descriptor has high precedence over the SDP
>>>information....
>>>
>>>    -----Original Message-----
>>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
>>>    *Sent:* Thursday, December 04, 2003 3:05 PM
>>>    *To:* Megaco@ietf.org
>>>    *Subject:* [Megaco] SDP mode and Megaco mode question
>>>
>>>    Hello,
>>>
>>>    Don't know precisely how to forumulate this question clearly, so let
>>>    me put in in two different ways...
>>>
>>>    What does a MG have to do if an MGC sends a Modify with:
>>>    - the Mode property of the LocalControl descriptor set to, for
>>>    instance, receive-only;
>>>    - a Local/Remote Descriptor with an SDP-block containing an
>>>    "a=sendrecv" parameter?
>>>
>>>    In other words, what is the relation beween the a=sendrecv,
>>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP protocol
>>>    and the Mode property of the LocalControl descriptor in the Megaco
>>>    protocol?
>>>
>>>
>>>    Can sb give some advise? Thanks!
>>>    Pascal
>>>
>>>
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
> 
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


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



From megaco-admin@ietf.org  Mon Dec  8 00:31:17 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14070
	for <megaco-archive@lists.ietf.org>; Mon, 8 Dec 2003 00:31:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDz3-00050R-Hr; Mon, 08 Dec 2003 00:31:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDyB-0004zq-8L
	for megaco@optimus.ietf.org; Mon, 08 Dec 2003 00:30:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14028
	for <megaco@ietf.org>; Mon, 8 Dec 2003 00:29:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDy8-0004o0-00
	for megaco@ietf.org; Mon, 08 Dec 2003 00:30:04 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDy6-0004ng-00
	for megaco@ietf.org; Mon, 08 Dec 2003 00:30:03 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hB84X8v16943;
	Mon, 8 Dec 2003 15:33:09 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.150]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YHH39ZM5; Mon, 8 Dec 2003 15:35:02 +1100
Message-ID: <3FD3FF27.1080108@ericsson.com>
Date: Mon, 08 Dec 2003 15:33:43 +1100
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: Steve Cipolli <SCipolli@radvision.com>
CC: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'Troy Cauble'" <troy@bell-labs.com>, megaco@ietf.org
Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
  	 L), & Short T imers (S)
References: <A3851AA1B761E944912B20D1E95A7EFE0B0A2D@radvpost.radvision.com>
In-Reply-To: <A3851AA1B761E944912B20D1E95A7EFE0B0A2D@radvpost.radvision.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hello Steve,

Nortel were instrumental in coming up with this digit map section so you've 
probably got the original intention from Kevin :).

Christian

Steve Cipolli wrote:

> While I tend to agree with most of the answers below, I don't see any of 
> this specified in the specification.  If we can agree that the answers 
> below are the correct interpretation, then we still need clarification 
> in the spec or implementors guide.  I'm still hoping the original author 
> of this section of the spec will clarify the original intention.
>  
> --Stephen
> 
>     -----Original Message-----
>     From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>     Sent: Tuesday, December 02, 2003 3:18 PM
>     To: Steve Cipolli; 'Troy Cauble'
>     Cc: megaco@ietf.org
>     Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>     Timers ( L), & Short T imers (S)
> 
>     Comments inline. [KJBII]
> 
>     Kevin
> 
>     -----Original Message-----
>     From: Steve Cipolli [mailto:SCipolli@radvision.com]
>     Sent: Tuesday, December 02, 2003 2:40 PM
>     To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH]
>     Cc: megaco@ietf.org
>     Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>     Timers ( L), & Short T imers (S)
> 
>     Perhaps I moved us off track a bit.  It is clear that there is more
>     than one interpretation of the specification with regard to L, S,
>     and to a lesser extent Z.  Can the authors comment on what the
>     intent of the specification was and then perhaps we can reach some
>     conclusion?
> 
>     Here is a partial list of odd digitmaps that seem to defy
>     interpretation:
>             "123Z"                          - "Z" ignored or error?
>     [KJBII] Z here has nothing to modify.  Error.
> 
>             "123S"                  - "S" (or "L") ignored or error?
>     [KJBII] In this instance, the digitmap switches to short interdigit
>     timing after detecting "123".  So, neither.
> 
>             "1ZZ23"                 - First "Z" ignored or error?
>     [KJBII] Because Z is defined as modifying the following digit, and Z
>     cannot modify Z, this should be an error.
> 
>             "1ZSSSSSSSSS23"         - "Z" applied to the "2" or ignored
>     or error?
>     [KJBII] See above.  Error as Z cannot modify S (or L).
> 
>             "135[2Z46]"                     - "Z" applied to "4" or to
>     all in the range (246) or ignored or error?
>     [KJBII] Z applies solely to the 4 here.
> 
>             "135[246Z]79"           - "Z" applied to "7" or ignored or
>     error?
>     [KJBII] Nothing for Z to modify.  Error.
> 
>             "135[2S46]"                     - "S" (or "L") applied to
>     all in range (246) or ignored or error?
>     [KJBII] This is the root of our earlier discussion.  L and S do not
>     modify digits -- they modify timing strategy for the digitmap at the
>     time they are encountered.  [246] means "match 2, 4 or 6".  So
>     [2S46] means... What exactly? "Match 2, short timeout, 4 or 6"?  Or
>     "match 2, 4 or 6 while running the short timer for this digit
>     only"?  Or "run the short timer S after detecting 2, but not if 4 or
>     6 is detected"?  If the string were "135S[246]" then we would start
>     using the short timer before looking for 2, 4 or 6.  If it were
>     "135[246]S", we would start using the short timer AFTER matching 2,
>     4 or 6.  But, with the S timer INSIDE the range, that would indicate
>     that the timer would have to fire to continue.  For instance, if the
>     string were "135[2S46]79", that would seem to indicate that if NO
>     digit was detected for the duration of the short timer, then we
>     should continue with the string to find 7.  This is a contrary usage
>     to S and L at any other point in a digitmap.  I think S and L should
>     be ignored within ranges.  If the MGC wants to use the S or L timer,
>     then put them outside the range.
> 
>             "135[2L4S6]"            - "L" or "S" applied or both
>     (somehow?) or ignored or error?
>     [KJBII] See above -- the same arguments apply here.  I would note
>     that L would never get "detected" here, since S would match first.
> 
>     Thanks,
>     --Stephen
> 
>            
> 
>      > -----Original Message-----
>      > From: Steve Cipolli [mailto:SCipolli@radvision.com]
>      > Sent: Monday, December 01, 2003 8:01 PM
>      > To: 'Troy Cauble'; Kevin Boyle
>      > Cc: megaco@ietf.org
>      > Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>      > Timers ( L), & Short T imers (S)
>      >
>      >
>      > Part of the problem is the term "alternatives" is not clear. 
>      > The text in
>      > 7.1.14.3 says of "alternatives":
>      > A DigitMap, according to this syntax, is defined either by a
>     string or
>      > by a list of strings.  Each string in the list is an alternative
>     event
>      > sequence, specified either as a sequence of digit map symbols or
>     as a
>      > regular expression of digit map symbols.
>      >
>      > My reading of this is that "alternatives" are each string and not
>     the
>      > possible sequences through a range, but admittedly this is not
>     clear.
>      >
>      > The section doesn't seem to explain other odd sequences like "123Z".
>      > Presumably the "Z" is simply ignored although an error could also be
>      > considered the proper outcome.
>      >
>      > I must say I prefer an interpretation in which the number of
>     possible
>      > ways to perform the same action is as close to 1 and possible.
>      > Therefore, I'd
>      > prefer to ban (or at least ignore) "L" and "S" within ranges.
>      >
>      > --Stephen
>      >
>      > > -----Original Message-----
>      > > From: Troy Cauble [mailto:troy@bell-labs.com]
>      > > Sent: Monday, December 01, 2003 6:33 PM
>      > > To: Kevin Boyle
>      > > Cc: megaco@ietf.org
>      > > Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>      > > Timers ( L), & Short T imers (S)
>      > >
>      > >
>      > >
>      > >
>      > > I disagree that "L" and "S" are meaningless within a range.
>      > >
>      > > "L" and "S" are used to specify the timer used for "subsequent
>      > > events".
>      > >
>      > > I would argue that the "5" is a subsequent event in "[34L]5", just
>      > > as it is in "[34]L5".
>      > >
>      > > I would also argue that the "4" in "[3L4]5" is NOT a "subsequent
>      > > event", although one might debate the definition of "subsequent".
>      > >
>      > > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and
>      > "[34]L5" are all
>      > > the same. (And the "L" is not meaningless.)
>      > >
>      > >
>      > > Note that section 7.1.14.3 does bother to specify what happens
>     when
>      > > explicit timing specifiers are only active in some "alternatives",
>      > or when they
>      > > differ in among alternatives -- the same timer value is used
>     for all
>      > > alternatives.
>      > >
>      > >
>      > > 7.1.14.3:
>      > >
>      > >  > In addition to these event symbols, the string may contain "S"
>      > > and "L"
>      > >  > inter-event timing specifiers and the "Z" duration modifier.
>     "S"
>      > > and "L"
>      > >  > respectively indicate that the MG should use the short (S)
>     timer
>      > > or the  > long (L) timer for subsequent events, overriding the
>      > > timing rules  > described above. If an explicit timing
>     specifier is
>      > > in effect in one  > alternative event sequence, but none is
>     given in
>      > > any other candidate  > alternative, the timer value set by the
>      > > explicit timing specifier must be  > used. If all sequences with
>      > > explicit timing controls are dropped from the  > candidate set,
>      > > timing reverts to the default rules given above. Finally,  > if
>      > > conflicting timing specifiers are in effect in different
>     alternative 
>      > > > sequences, the long timer shall be used.
>      > >
>      > >
>      > > -troy
>      > >
>      > >
>      > >
>      > > Kevin Boyle wrote:
>      > >
>      > > > Since a range means "match one of these", I would agree
>      > > with the assessment
>      > > > that L and S are meaningless within a range.
>      > > > 
>      > > > Kevin
>      > > >
>      > > >
>      > > >   _____
>      > > >
>      > > > From: Steve Cipolli [mailto:SCipolli@radvision.com]
>      > > > Sent: Monday, December 01, 2003 5:22 PM
>      > > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
>      > > > Subject: RE: [Megaco] Digit Maps: Long Duration
>      > > Modifier(Z), Long Timers (
>      > > > L), & Short T imers (S)
>      > > >
>      > > >
>      > > > Thanks for the feedback. 
>      > > > 
>      > > > Just to make sure I understand the L and S cases:
>      > > > They are syntactically legal in a range specification, but
>      > > semantically they
>      > > > have no effect.  Correct?
>      > > > 
>      > > > --Stephen
>      > > >
>      > > > -----Original Message-----
>      > > > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>      > > > Sent: Monday, December 01, 2003 5:15 PM
>      > > > To: Steve Cipolli; megaco@ietf.org
>      > > > Subject: RE: [Megaco] Digit Maps: Long Duration
>      > > Modifier(Z), Long Timers (
>      > > > L), & Short T imers (S)
>      > > >
>      > > >
>      > > > Your interpretation is correct.  Because Z changes how a
>      > > digit is matched,
>      > > > it makes sense within a range.  Think of Z as part of the
>      > > digit it modifies,
>      > > > rather than a separate symbol.
>      > > > 
>      > > > The L and S timers within a digitmap give specific
>      > > instruction as to which
>      > > > timer to run at that point in the digitmap.  While allowed
>      > > in a range, I
>      > > > don't think they provide much value within a range since
>      > they do not
>      > > > actually match anything.  For effective use, they should be
>      > > outside the
>      > > > range.
>      > > > 
>      > > > Kevin
>      > > >
>      > > >
>      > > >   _____
>      > > >
>      > > > From: Steve Cipolli [mailto:SCipolli@radvision.com]
>      > > > Sent: Monday, December 01, 2003 3:26 PM
>      > > > To: megaco@ietf.org
>      > > > Subject: [Megaco] Digit Maps: Long Duration Modifier(Z),
>      > > Long Timers (L), &
>      > > > Short T imers (S)
>      > > >
>      > > >
>      > > > 
>      > > > According to the syntax in RFCs 3015 & 3525 the long
>      > > duration modifier (Z),
>      > > > Long Timers (L), & Short Timers (S) in digit maps can
>      > > appear in a digit
>      > > > range.  For example (where Z is 1000ms):
>      > > >     "135[2Z46]"
>      > > > 
>      > > > Is this valid?  If it is valid, does this mean that the
>      > > fourth digit event
>      > > > must be either 2, 6 (held for any duration) or 4 held for
>     1000 ms?
>      > > > 
>      > > > How does long timer (L) and short timer (S) in a digit
>      > range apply?
>      > > > 
>      > > > --Stephen
>      > > > 
>      > > > 
>      > > >
>      > > >
>      > > > _______________________________________________
>      > > > 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 exim@www1.ietf.org  Mon Dec  8 00:31:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14085
	for <megaco-archive@odin.ietf.org>; Mon, 8 Dec 2003 00:31:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDz6-000527-Df
	for megaco-archive@odin.ietf.org; Mon, 08 Dec 2003 00:31:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB85V4qJ019341
	for megaco-archive@odin.ietf.org; Mon, 8 Dec 2003 00:31:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDz6-00051s-A5
	for megaco-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 00:31:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14051
	for <megaco-web-archive@ietf.org>; Mon, 8 Dec 2003 00:30:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDz3-0004oU-00
	for megaco-web-archive@ietf.org; Mon, 08 Dec 2003 00:31:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDz3-0004oR-00
	for megaco-web-archive@ietf.org; Mon, 08 Dec 2003 00:31:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDz3-00050R-Hr; Mon, 08 Dec 2003 00:31:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDyB-0004zq-8L
	for megaco@optimus.ietf.org; Mon, 08 Dec 2003 00:30:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14028
	for <megaco@ietf.org>; Mon, 8 Dec 2003 00:29:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDy8-0004o0-00
	for megaco@ietf.org; Mon, 08 Dec 2003 00:30:04 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDy6-0004ng-00
	for megaco@ietf.org; Mon, 08 Dec 2003 00:30:03 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hB84X8v16943;
	Mon, 8 Dec 2003 15:33:09 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.150]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YHH39ZM5; Mon, 8 Dec 2003 15:35:02 +1100
Message-ID: <3FD3FF27.1080108@ericsson.com>
Date: Mon, 08 Dec 2003 15:33:43 +1100
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: Steve Cipolli <SCipolli@radvision.com>
CC: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        "'Troy Cauble'" <troy@bell-labs.com>, megaco@ietf.org
Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
  	 L), & Short T imers (S)
References: <A3851AA1B761E944912B20D1E95A7EFE0B0A2D@radvpost.radvision.com>
In-Reply-To: <A3851AA1B761E944912B20D1E95A7EFE0B0A2D@radvpost.radvision.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Steve,

Nortel were instrumental in coming up with this digit map section so you've 
probably got the original intention from Kevin :).

Christian

Steve Cipolli wrote:

> While I tend to agree with most of the answers below, I don't see any of 
> this specified in the specification.  If we can agree that the answers 
> below are the correct interpretation, then we still need clarification 
> in the spec or implementors guide.  I'm still hoping the original author 
> of this section of the spec will clarify the original intention.
>  
> --Stephen
> 
>     -----Original Message-----
>     From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>     Sent: Tuesday, December 02, 2003 3:18 PM
>     To: Steve Cipolli; 'Troy Cauble'
>     Cc: megaco@ietf.org
>     Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>     Timers ( L), & Short T imers (S)
> 
>     Comments inline. [KJBII]
> 
>     Kevin
> 
>     -----Original Message-----
>     From: Steve Cipolli [mailto:SCipolli@radvision.com]
>     Sent: Tuesday, December 02, 2003 2:40 PM
>     To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH]
>     Cc: megaco@ietf.org
>     Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>     Timers ( L), & Short T imers (S)
> 
>     Perhaps I moved us off track a bit.  It is clear that there is more
>     than one interpretation of the specification with regard to L, S,
>     and to a lesser extent Z.  Can the authors comment on what the
>     intent of the specification was and then perhaps we can reach some
>     conclusion?
> 
>     Here is a partial list of odd digitmaps that seem to defy
>     interpretation:
>             "123Z"                          - "Z" ignored or error?
>     [KJBII] Z here has nothing to modify.  Error.
> 
>             "123S"                  - "S" (or "L") ignored or error?
>     [KJBII] In this instance, the digitmap switches to short interdigit
>     timing after detecting "123".  So, neither.
> 
>             "1ZZ23"                 - First "Z" ignored or error?
>     [KJBII] Because Z is defined as modifying the following digit, and Z
>     cannot modify Z, this should be an error.
> 
>             "1ZSSSSSSSSS23"         - "Z" applied to the "2" or ignored
>     or error?
>     [KJBII] See above.  Error as Z cannot modify S (or L).
> 
>             "135[2Z46]"                     - "Z" applied to "4" or to
>     all in the range (246) or ignored or error?
>     [KJBII] Z applies solely to the 4 here.
> 
>             "135[246Z]79"           - "Z" applied to "7" or ignored or
>     error?
>     [KJBII] Nothing for Z to modify.  Error.
> 
>             "135[2S46]"                     - "S" (or "L") applied to
>     all in range (246) or ignored or error?
>     [KJBII] This is the root of our earlier discussion.  L and S do not
>     modify digits -- they modify timing strategy for the digitmap at the
>     time they are encountered.  [246] means "match 2, 4 or 6".  So
>     [2S46] means... What exactly? "Match 2, short timeout, 4 or 6"?  Or
>     "match 2, 4 or 6 while running the short timer for this digit
>     only"?  Or "run the short timer S after detecting 2, but not if 4 or
>     6 is detected"?  If the string were "135S[246]" then we would start
>     using the short timer before looking for 2, 4 or 6.  If it were
>     "135[246]S", we would start using the short timer AFTER matching 2,
>     4 or 6.  But, with the S timer INSIDE the range, that would indicate
>     that the timer would have to fire to continue.  For instance, if the
>     string were "135[2S46]79", that would seem to indicate that if NO
>     digit was detected for the duration of the short timer, then we
>     should continue with the string to find 7.  This is a contrary usage
>     to S and L at any other point in a digitmap.  I think S and L should
>     be ignored within ranges.  If the MGC wants to use the S or L timer,
>     then put them outside the range.
> 
>             "135[2L4S6]"            - "L" or "S" applied or both
>     (somehow?) or ignored or error?
>     [KJBII] See above -- the same arguments apply here.  I would note
>     that L would never get "detected" here, since S would match first.
> 
>     Thanks,
>     --Stephen
> 
>            
> 
>      > -----Original Message-----
>      > From: Steve Cipolli [mailto:SCipolli@radvision.com]
>      > Sent: Monday, December 01, 2003 8:01 PM
>      > To: 'Troy Cauble'; Kevin Boyle
>      > Cc: megaco@ietf.org
>      > Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>      > Timers ( L), & Short T imers (S)
>      >
>      >
>      > Part of the problem is the term "alternatives" is not clear. 
>      > The text in
>      > 7.1.14.3 says of "alternatives":
>      > A DigitMap, according to this syntax, is defined either by a
>     string or
>      > by a list of strings.  Each string in the list is an alternative
>     event
>      > sequence, specified either as a sequence of digit map symbols or
>     as a
>      > regular expression of digit map symbols.
>      >
>      > My reading of this is that "alternatives" are each string and not
>     the
>      > possible sequences through a range, but admittedly this is not
>     clear.
>      >
>      > The section doesn't seem to explain other odd sequences like "123Z".
>      > Presumably the "Z" is simply ignored although an error could also be
>      > considered the proper outcome.
>      >
>      > I must say I prefer an interpretation in which the number of
>     possible
>      > ways to perform the same action is as close to 1 and possible.
>      > Therefore, I'd
>      > prefer to ban (or at least ignore) "L" and "S" within ranges.
>      >
>      > --Stephen
>      >
>      > > -----Original Message-----
>      > > From: Troy Cauble [mailto:troy@bell-labs.com]
>      > > Sent: Monday, December 01, 2003 6:33 PM
>      > > To: Kevin Boyle
>      > > Cc: megaco@ietf.org
>      > > Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>      > > Timers ( L), & Short T imers (S)
>      > >
>      > >
>      > >
>      > >
>      > > I disagree that "L" and "S" are meaningless within a range.
>      > >
>      > > "L" and "S" are used to specify the timer used for "subsequent
>      > > events".
>      > >
>      > > I would argue that the "5" is a subsequent event in "[34L]5", just
>      > > as it is in "[34]L5".
>      > >
>      > > I would also argue that the "4" in "[3L4]5" is NOT a "subsequent
>      > > event", although one might debate the definition of "subsequent".
>      > >
>      > > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and
>      > "[34]L5" are all
>      > > the same. (And the "L" is not meaningless.)
>      > >
>      > >
>      > > Note that section 7.1.14.3 does bother to specify what happens
>     when
>      > > explicit timing specifiers are only active in some "alternatives",
>      > or when they
>      > > differ in among alternatives -- the same timer value is used
>     for all
>      > > alternatives.
>      > >
>      > >
>      > > 7.1.14.3:
>      > >
>      > >  > In addition to these event symbols, the string may contain "S"
>      > > and "L"
>      > >  > inter-event timing specifiers and the "Z" duration modifier.
>     "S"
>      > > and "L"
>      > >  > respectively indicate that the MG should use the short (S)
>     timer
>      > > or the  > long (L) timer for subsequent events, overriding the
>      > > timing rules  > described above. If an explicit timing
>     specifier is
>      > > in effect in one  > alternative event sequence, but none is
>     given in
>      > > any other candidate  > alternative, the timer value set by the
>      > > explicit timing specifier must be  > used. If all sequences with
>      > > explicit timing controls are dropped from the  > candidate set,
>      > > timing reverts to the default rules given above. Finally,  > if
>      > > conflicting timing specifiers are in effect in different
>     alternative 
>      > > > sequences, the long timer shall be used.
>      > >
>      > >
>      > > -troy
>      > >
>      > >
>      > >
>      > > Kevin Boyle wrote:
>      > >
>      > > > Since a range means "match one of these", I would agree
>      > > with the assessment
>      > > > that L and S are meaningless within a range.
>      > > > 
>      > > > Kevin
>      > > >
>      > > >
>      > > >   _____
>      > > >
>      > > > From: Steve Cipolli [mailto:SCipolli@radvision.com]
>      > > > Sent: Monday, December 01, 2003 5:22 PM
>      > > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
>      > > > Subject: RE: [Megaco] Digit Maps: Long Duration
>      > > Modifier(Z), Long Timers (
>      > > > L), & Short T imers (S)
>      > > >
>      > > >
>      > > > Thanks for the feedback. 
>      > > > 
>      > > > Just to make sure I understand the L and S cases:
>      > > > They are syntactically legal in a range specification, but
>      > > semantically they
>      > > > have no effect.  Correct?
>      > > > 
>      > > > --Stephen
>      > > >
>      > > > -----Original Message-----
>      > > > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>      > > > Sent: Monday, December 01, 2003 5:15 PM
>      > > > To: Steve Cipolli; megaco@ietf.org
>      > > > Subject: RE: [Megaco] Digit Maps: Long Duration
>      > > Modifier(Z), Long Timers (
>      > > > L), & Short T imers (S)
>      > > >
>      > > >
>      > > > Your interpretation is correct.  Because Z changes how a
>      > > digit is matched,
>      > > > it makes sense within a range.  Think of Z as part of the
>      > > digit it modifies,
>      > > > rather than a separate symbol.
>      > > > 
>      > > > The L and S timers within a digitmap give specific
>      > > instruction as to which
>      > > > timer to run at that point in the digitmap.  While allowed
>      > > in a range, I
>      > > > don't think they provide much value within a range since
>      > they do not
>      > > > actually match anything.  For effective use, they should be
>      > > outside the
>      > > > range.
>      > > > 
>      > > > Kevin
>      > > >
>      > > >
>      > > >   _____
>      > > >
>      > > > From: Steve Cipolli [mailto:SCipolli@radvision.com]
>      > > > Sent: Monday, December 01, 2003 3:26 PM
>      > > > To: megaco@ietf.org
>      > > > Subject: [Megaco] Digit Maps: Long Duration Modifier(Z),
>      > > Long Timers (L), &
>      > > > Short T imers (S)
>      > > >
>      > > >
>      > > > 
>      > > > According to the syntax in RFCs 3015 & 3525 the long
>      > > duration modifier (Z),
>      > > > Long Timers (L), & Short Timers (S) in digit maps can
>      > > appear in a digit
>      > > > range.  For example (where Z is 1000ms):
>      > > >     "135[2Z46]"
>      > > > 
>      > > > Is this valid?  If it is valid, does this mean that the
>      > > fourth digit event
>      > > > must be either 2, 6 (held for any duration) or 4 held for
>     1000 ms?
>      > > > 
>      > > > How does long timer (L) and short timer (S) in a digit
>      > range apply?
>      > > > 
>      > > > --Stephen
>      > > > 
>      > > > 
>      > > >
>      > > >
>      > > > _______________________________________________
>      > > > 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-admin@ietf.org  Mon Dec  8 10:17:15 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13145
	for <megaco-archive@lists.ietf.org>; Mon, 8 Dec 2003 10:17:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATN88-0001qJ-Sr; Mon, 08 Dec 2003 10:17:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDcy-0004hl-KU
	for megaco@optimus.ietf.org; Mon, 08 Dec 2003 00:08:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13629
	for <megaco@ietf.org>; Mon, 8 Dec 2003 00:07:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDcw-0004bp-00
	for megaco@ietf.org; Mon, 08 Dec 2003 00:08:10 -0500
Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDcu-0004bT-00
	for megaco@ietf.org; Mon, 08 Dec 2003 00:08:08 -0500
Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38])
	by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id hB852U93024376
	for <megaco@ietf.org>; Mon, 8 Dec 2003 13:02:31 +0800 (CST)
Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Mon Dec 08 13:10:40 2003 +0800
Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 8 Dec 2003 13:10:39 +0800
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="utf-7"
Content-Transfer-Encoding: 7bit
Date: Mon, 8 Dec 2003 13:10:39 +0800
Message-ID: <C2DB7F5BC458EA4C8EB46B7A4EFF7E76BB1379@bellnet-mail1.sbell.com.cn>
Thread-Topic: about error code 
Thread-Index: AcO9SZ3ERrbroOJvRmSMbK7lK0FvPg+AD0APQ-
From: "FND-AD Wang JuLin" <JuLin.Wang@alcatel-sbell.com.cn>
To: <megaco@ietf.org>
X-OriginalArrivalTime: 08 Dec 2003 05:10:39.0749 (UTC) FILETIME=[9F2FFB50:01C3BD49]
Content-Transfer-Encoding: 7bit
Subject: [Megaco] about error code
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hello list,
1) Suppose a term has already been added to a specific context. When we add this term again with choose +ACQ- context, does the reply message(433 error) contain the old specific context or just the latest choose context?

As follows:
MGC to MG
MEGACO/1 +AFs-10.10.0.4+AF0- Transaction +AD0-1372  +AHs-     Context +AD0- +ACQ- +AHs-         Add +AD0- tdm/2/1 +AHs-                 Media +AHs-LocalControl +AHs-Mode +AD0- SendReceive+AH0AfQ-                 +AH0-  ,        Add +AD0- +ACQ- +AHs-                Media +AHs-Stream+AD0-1+AHs-LocalControl +AHs-Mode +AD0- ReceiveOnly+AH0-,Local +AHs- v+AD0-0   c+AD0-IN IP4 +ACQ- m+AD0-audio +ACQ- RTP/AVP 8 a+AD0-ptime:30 +AH0AfQB9-                +AH0-  +AH0-     +AH0- 

MG reply message
+ACE-/1 +AFs-10.10.0.11+AF0- P+AD0-1372+AHs-C+AD0AJAB7-A+AD0-tdm/2/1+AHs-ER+AD0-433+AHsAIg-TerminationID is already in a Context+ACIAfQB9AH0AfQ-
or
+ACE-/1 +AFs-10.10.0.11+AF0- P+AD0-1372+AHs-C+AD0-416+AHs-A+AD0-tdm/2/1+AHs-ER+AD0-433+AHsAIg-TerminationID is already in a Context+ACIAfQB9AH0AfQ-

2) What error will be triggerred if mgc issue subtract message with choose context on all term(+ACo-)?
i.e.
MGC to MG
MEGACO/1 +AFs-10.10.0.4+AF0- Transaction +AD0-133 +AHs-
    Context +AD0- +ACQAew-  
       Subtract  +AD0- +ACo-
    +AH0AfQ-
MG reply message

+ACE-/1 +AFs-10.10.0.11+AF0- P+AD0-133+AHs-C+AD0AJAB7-S+AD0AKgB7-ER+AD0-411+AHsAIg-Transaction refers to an unknown ContextID+ACIAfQB9AH0AfQ-


Thank you  very much+ACE- 



 best  regards
+AD4- :-)Jerry Wang
tel:(8621)58541240 ext 9531
MP:13621761050
mailto:Julin.Wang+AEA-alcatel-sbell.com.cn 
Alcatel Shanghai Bell Co.LTD


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


From exim@www1.ietf.org  Mon Dec  8 10:17:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13164
	for <megaco-archive@odin.ietf.org>; Mon, 8 Dec 2003 10:17:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATN8C-0001rf-9F
	for megaco-archive@odin.ietf.org; Mon, 08 Dec 2003 10:17:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8FH4Yc007161
	for megaco-archive@odin.ietf.org; Mon, 8 Dec 2003 10:17:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATN8C-0001rQ-2D
	for megaco-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 10:17:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13076
	for <megaco-web-archive@ietf.org>; Mon, 8 Dec 2003 10:16:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATN88-0005wX-00
	for megaco-web-archive@ietf.org; Mon, 08 Dec 2003 10:17:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATN88-0005wU-00
	for megaco-web-archive@ietf.org; Mon, 08 Dec 2003 10:17:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATN88-0001qJ-Sr; Mon, 08 Dec 2003 10:17:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATDcy-0004hl-KU
	for megaco@optimus.ietf.org; Mon, 08 Dec 2003 00:08:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13629
	for <megaco@ietf.org>; Mon, 8 Dec 2003 00:07:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDcw-0004bp-00
	for megaco@ietf.org; Mon, 08 Dec 2003 00:08:10 -0500
Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATDcu-0004bT-00
	for megaco@ietf.org; Mon, 08 Dec 2003 00:08:08 -0500
Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38])
	by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id hB852U93024376
	for <megaco@ietf.org>; Mon, 8 Dec 2003 13:02:31 +0800 (CST)
Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Mon Dec 08 13:10:40 2003 +0800
Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 8 Dec 2003 13:10:39 +0800
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="utf-7"
Content-Transfer-Encoding: 7bit
Date: Mon, 8 Dec 2003 13:10:39 +0800
Message-ID: <C2DB7F5BC458EA4C8EB46B7A4EFF7E76BB1379@bellnet-mail1.sbell.com.cn>
Thread-Topic: about error code 
Thread-Index: AcO9SZ3ERrbroOJvRmSMbK7lK0FvPg+AD0APQ-
From: "FND-AD Wang JuLin" <JuLin.Wang@alcatel-sbell.com.cn>
To: <megaco@ietf.org>
X-OriginalArrivalTime: 08 Dec 2003 05:10:39.0749 (UTC) FILETIME=[9F2FFB50:01C3BD49]
Content-Transfer-Encoding: 7bit
Subject: [Megaco] about error code
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello list,
1) Suppose a term has already been added to a specific context. When we add this term again with choose +ACQ- context, does the reply message(433 error) contain the old specific context or just the latest choose context?

As follows:
MGC to MG
MEGACO/1 +AFs-10.10.0.4+AF0- Transaction +AD0-1372  +AHs-     Context +AD0- +ACQ- +AHs-         Add +AD0- tdm/2/1 +AHs-                 Media +AHs-LocalControl +AHs-Mode +AD0- SendReceive+AH0AfQ-                 +AH0-  ,        Add +AD0- +ACQ- +AHs-                Media +AHs-Stream+AD0-1+AHs-LocalControl +AHs-Mode +AD0- ReceiveOnly+AH0-,Local +AHs- v+AD0-0   c+AD0-IN IP4 +ACQ- m+AD0-audio +ACQ- RTP/AVP 8 a+AD0-ptime:30 +AH0AfQB9-                +AH0-  +AH0-     +AH0- 

MG reply message
+ACE-/1 +AFs-10.10.0.11+AF0- P+AD0-1372+AHs-C+AD0AJAB7-A+AD0-tdm/2/1+AHs-ER+AD0-433+AHsAIg-TerminationID is already in a Context+ACIAfQB9AH0AfQ-
or
+ACE-/1 +AFs-10.10.0.11+AF0- P+AD0-1372+AHs-C+AD0-416+AHs-A+AD0-tdm/2/1+AHs-ER+AD0-433+AHsAIg-TerminationID is already in a Context+ACIAfQB9AH0AfQ-

2) What error will be triggerred if mgc issue subtract message with choose context on all term(+ACo-)?
i.e.
MGC to MG
MEGACO/1 +AFs-10.10.0.4+AF0- Transaction +AD0-133 +AHs-
    Context +AD0- +ACQAew-  
       Subtract  +AD0- +ACo-
    +AH0AfQ-
MG reply message

+ACE-/1 +AFs-10.10.0.11+AF0- P+AD0-133+AHs-C+AD0AJAB7-S+AD0AKgB7-ER+AD0-411+AHsAIg-Transaction refers to an unknown ContextID+ACIAfQB9AH0AfQ-


Thank you  very much+ACE- 



 best  regards
+AD4- :-)Jerry Wang
tel:(8621)58541240 ext 9531
MP:13621761050
mailto:Julin.Wang+AEA-alcatel-sbell.com.cn 
Alcatel Shanghai Bell Co.LTD


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



From megaco-admin@ietf.org  Mon Dec  8 12:59:15 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21184
	for <megaco-archive@lists.ietf.org>; Mon, 8 Dec 2003 12:59:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATPev-0003Bo-Eb; Mon, 08 Dec 2003 12:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATPeN-0003BK-4D
	for megaco@optimus.ietf.org; Mon, 08 Dec 2003 12:58:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21159
	for <Megaco@ietf.org>; Mon, 8 Dec 2003 12:58:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATPeG-0001TM-00
	for Megaco@ietf.org; Mon, 08 Dec 2003 12:58:20 -0500
Received: from mx1.veraznet.com ([198.87.49.137])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATPeF-0001TC-00
	for Megaco@ietf.org; Mon, 08 Dec 2003 12:58:20 -0500
Received: from sapphire.veraznet.com ([198.87.49.5]) by mx1.veraznet.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 8 Dec 2003 09:57:46 -0800
Received: by mail.veraznet.com with Internet Mail Service (5.5.2656.59)
	id <YLJ3RSL0>; Mon, 8 Dec 2003 09:57:45 -0800
Message-ID: <9E388C880C1ED411AFE1009027E787250526F0AC@mail.veraznet.com>
From: Madhubabu Brahmanapally <Madhubabu@veraznet.com>
To: "'Christian Groves'" <Christian.Groves@ericsson.com>,
        Pascal Lambers
	 <pascal.lambers@pandora.be>
Cc: Tom Taylor <taylor@nortelnetworks.com>, Megaco@ietf.org
Subject: RE: [Megaco] SDP mode and Megaco mode question
Date: Mon, 8 Dec 2003 09:57:40 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3BDB4.C5A195D0"
X-OriginalArrivalTime: 08 Dec 2003 17:57:46.0274 (UTC) FILETIME=[C9225820:01C3BDB4]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3BDB4.C5A195D0
Content-Type: text/plain

Hi Christian,
Does the Local control mode property takes precedence or as Tom pointed out,
does the MG always disregard the mode in local/remote descriptors??

Regards
Madhubabu

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com]
Sent: Sunday, December 07, 2003 8:56 PM
To: Pascal Lambers
Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question


Hello Pascal,

I think you have pointed out an issue for the Implementors' Guide. This fact

that the Local Control Mode overrides the SDP is common practise the only 
problem is that it is not clearly stated.

I would propose that :
7.1.7	LocalControl descriptor
...
The allowed values for the mode property are send-only, receive-only, 
send/receive, inactive and loop-back. "Send" and "receive" are with respect
to 
the exterior of the Context, so that, for example, a stream set to mode = 
sendOnly does not pass received media into the Context. The default value
for 
the mode property is "Inactive". Signals and Events are not affected by
mode.
 >>> The local control mode property takes precedence over the local and
remote 
descriptors.<<<
...

Regards, Christian

Pascal Lambers wrote:

> So would I, but isn't there any RFC statement to enforce this opinion?
> 
> Pascal
> 
> 
> ----- Original Message ----- 
> From: "Tom Taylor" <taylor@nortelnetworks.com>
> To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
> Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>
> Sent: Friday, December 05, 2003 12:31 AM
> Subject: Re: [Megaco] SDP mode and Megaco mode question
> 
> 
> 
>>I would put it bluntly that the MG must ignore mode in the SDP.
>>
>>Madhubabu Brahmanapally wrote:
>>
>>
>>>The Local Control Descriptor has high precedence over the SDP
>>>information....
>>>
>>>    -----Original Message-----
>>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
>>>    *Sent:* Thursday, December 04, 2003 3:05 PM
>>>    *To:* Megaco@ietf.org
>>>    *Subject:* [Megaco] SDP mode and Megaco mode question
>>>
>>>    Hello,
>>>
>>>    Don't know precisely how to forumulate this question clearly, so let
>>>    me put in in two different ways...
>>>
>>>    What does a MG have to do if an MGC sends a Modify with:
>>>    - the Mode property of the LocalControl descriptor set to, for
>>>    instance, receive-only;
>>>    - a Local/Remote Descriptor with an SDP-block containing an
>>>    "a=sendrecv" parameter?
>>>
>>>    In other words, what is the relation beween the a=sendrecv,
>>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP protocol
>>>    and the Mode property of the LocalControl descriptor in the Megaco
>>>    protocol?
>>>
>>>
>>>    Can sb give some advise? Thanks!
>>>    Pascal
>>>
>>>
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
> 
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 

------_=_NextPart_001_01C3BDB4.C5A195D0
Content-Type: text/html
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=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.45">
<TITLE>RE: [Megaco] SDP mode and Megaco mode question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Christian,</FONT>
<BR><FONT SIZE=3D2>Does the Local control mode property takes =
precedence or as Tom pointed out, does the MG always disregard the mode =
in local/remote descriptors??</FONT></P>

<P><FONT SIZE=3D2>Regards</FONT>
<BR><FONT SIZE=3D2>Madhubabu</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Christian Groves [<A =
HREF=3D"mailto:Christian.Groves@ericsson.com">mailto:Christian.Groves@er=
icsson.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, December 07, 2003 8:56 PM</FONT>
<BR><FONT SIZE=3D2>To: Pascal Lambers</FONT>
<BR><FONT SIZE=3D2>Cc: Tom Taylor; Madhubabu Brahmanapally; =
Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Megaco] SDP mode and Megaco mode =
question</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hello Pascal,</FONT>
</P>

<P><FONT SIZE=3D2>I think you have pointed out an issue for the =
Implementors' Guide. This fact </FONT>
<BR><FONT SIZE=3D2>that the Local Control Mode overrides the SDP is =
common practise the only </FONT>
<BR><FONT SIZE=3D2>problem is that it is not clearly stated.</FONT>
</P>

<P><FONT SIZE=3D2>I would propose that :</FONT>
<BR><FONT SIZE=3D2>7.1.7&nbsp;&nbsp; LocalControl descriptor</FONT>
<BR><FONT SIZE=3D2>...</FONT>
<BR><FONT SIZE=3D2>The allowed values for the mode property are =
send-only, receive-only, </FONT>
<BR><FONT SIZE=3D2>send/receive, inactive and loop-back. =
&quot;Send&quot; and &quot;receive&quot; are with respect to </FONT>
<BR><FONT SIZE=3D2>the exterior of the Context, so that, for example, a =
stream set to mode =3D </FONT>
<BR><FONT SIZE=3D2>sendOnly does not pass received media into the =
Context. The default value for </FONT>
<BR><FONT SIZE=3D2>the mode property is &quot;Inactive&quot;. Signals =
and Events are not affected by mode.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&gt;&gt; The local control mode property =
takes precedence over the local and remote </FONT>
<BR><FONT SIZE=3D2>descriptors.&lt;&lt;&lt;</FONT>
<BR><FONT SIZE=3D2>...</FONT>
</P>

<P><FONT SIZE=3D2>Regards, Christian</FONT>
</P>

<P><FONT SIZE=3D2>Pascal Lambers wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; So would I, but isn't there any RFC statement to =
enforce this opinion?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Pascal</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ----- Original Message ----- </FONT>
<BR><FONT SIZE=3D2>&gt; From: &quot;Tom Taylor&quot; =
&lt;taylor@nortelnetworks.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; To: &quot;Madhubabu Brahmanapally&quot; =
&lt;Madhubabu@veraznet.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: &quot;'Pascal Lambers'&quot; =
&lt;pascal.lambers@pandora.be&gt;; &lt;Megaco@ietf.org&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, December 05, 2003 12:31 AM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Megaco] SDP mode and Megaco mode =
question</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;I would put it bluntly that the MG must =
ignore mode in the SDP.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Madhubabu Brahmanapally wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;The Local Control Descriptor has high =
precedence over the SDP</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;information....</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *From:* Pascal =
Lambers [<A =
HREF=3D"mailto:pascal.lambers@pandora.be">mailto:pascal.lambers@pandora.=
be</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *Sent:* Thursday, =
December 04, 2003 3:05 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *To:* =
Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *Subject:* [Megaco] =
SDP mode and Megaco mode question</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Hello,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Don't know precisely =
how to forumulate this question clearly, so let</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; me put in in two =
different ways...</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; What does a MG have =
to do if an MGC sends a Modify with:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; - the Mode property =
of the LocalControl descriptor set to, for</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; instance, =
receive-only;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; - a Local/Remote =
Descriptor with an SDP-block containing an</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; =
&quot;a=3Dsendrecv&quot; parameter?</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; In other words, what =
is the relation beween the a=3Dsendrecv,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; a=3Dsendonly, =
a=3Dinactive, a=3Drecvonly parameters of the SDP protocol</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; and the Mode property =
of the LocalControl descriptor in the Megaco</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; protocol?</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Can sb give some =
advise? Thanks!</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Pascal</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;<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>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <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>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3BDB4.C5A195D0--

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


From exim@www1.ietf.org  Mon Dec  8 12:59:17 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21199
	for <megaco-archive@odin.ietf.org>; Mon, 8 Dec 2003 12:59:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATPey-0003Cf-7n
	for megaco-archive@odin.ietf.org; Mon, 08 Dec 2003 12:59:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Hx4Wf012307
	for megaco-archive@odin.ietf.org; Mon, 8 Dec 2003 12:59:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATPey-0003CQ-2I
	for megaco-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 12:59:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21168
	for <megaco-web-archive@ietf.org>; Mon, 8 Dec 2003 12:58:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATPew-0001Tn-00
	for megaco-web-archive@ietf.org; Mon, 08 Dec 2003 12:59:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATPev-0001Tj-00
	for megaco-web-archive@ietf.org; Mon, 08 Dec 2003 12:59:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATPev-0003Bo-Eb; Mon, 08 Dec 2003 12:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATPeN-0003BK-4D
	for megaco@optimus.ietf.org; Mon, 08 Dec 2003 12:58:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21159
	for <Megaco@ietf.org>; Mon, 8 Dec 2003 12:58:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATPeG-0001TM-00
	for Megaco@ietf.org; Mon, 08 Dec 2003 12:58:20 -0500
Received: from mx1.veraznet.com ([198.87.49.137])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATPeF-0001TC-00
	for Megaco@ietf.org; Mon, 08 Dec 2003 12:58:20 -0500
Received: from sapphire.veraznet.com ([198.87.49.5]) by mx1.veraznet.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 8 Dec 2003 09:57:46 -0800
Received: by mail.veraznet.com with Internet Mail Service (5.5.2656.59)
	id <YLJ3RSL0>; Mon, 8 Dec 2003 09:57:45 -0800
Message-ID: <9E388C880C1ED411AFE1009027E787250526F0AC@mail.veraznet.com>
From: Madhubabu Brahmanapally <Madhubabu@veraznet.com>
To: "'Christian Groves'" <Christian.Groves@ericsson.com>,
        Pascal Lambers
	 <pascal.lambers@pandora.be>
Cc: Tom Taylor <taylor@nortelnetworks.com>, Megaco@ietf.org
Subject: RE: [Megaco] SDP mode and Megaco mode question
Date: Mon, 8 Dec 2003 09:57:40 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3BDB4.C5A195D0"
X-OriginalArrivalTime: 08 Dec 2003 17:57:46.0274 (UTC) FILETIME=[C9225820:01C3BDB4]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3BDB4.C5A195D0
Content-Type: text/plain

Hi Christian,
Does the Local control mode property takes precedence or as Tom pointed out,
does the MG always disregard the mode in local/remote descriptors??

Regards
Madhubabu

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com]
Sent: Sunday, December 07, 2003 8:56 PM
To: Pascal Lambers
Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question


Hello Pascal,

I think you have pointed out an issue for the Implementors' Guide. This fact

that the Local Control Mode overrides the SDP is common practise the only 
problem is that it is not clearly stated.

I would propose that :
7.1.7	LocalControl descriptor
...
The allowed values for the mode property are send-only, receive-only, 
send/receive, inactive and loop-back. "Send" and "receive" are with respect
to 
the exterior of the Context, so that, for example, a stream set to mode = 
sendOnly does not pass received media into the Context. The default value
for 
the mode property is "Inactive". Signals and Events are not affected by
mode.
 >>> The local control mode property takes precedence over the local and
remote 
descriptors.<<<
...

Regards, Christian

Pascal Lambers wrote:

> So would I, but isn't there any RFC statement to enforce this opinion?
> 
> Pascal
> 
> 
> ----- Original Message ----- 
> From: "Tom Taylor" <taylor@nortelnetworks.com>
> To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
> Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>
> Sent: Friday, December 05, 2003 12:31 AM
> Subject: Re: [Megaco] SDP mode and Megaco mode question
> 
> 
> 
>>I would put it bluntly that the MG must ignore mode in the SDP.
>>
>>Madhubabu Brahmanapally wrote:
>>
>>
>>>The Local Control Descriptor has high precedence over the SDP
>>>information....
>>>
>>>    -----Original Message-----
>>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
>>>    *Sent:* Thursday, December 04, 2003 3:05 PM
>>>    *To:* Megaco@ietf.org
>>>    *Subject:* [Megaco] SDP mode and Megaco mode question
>>>
>>>    Hello,
>>>
>>>    Don't know precisely how to forumulate this question clearly, so let
>>>    me put in in two different ways...
>>>
>>>    What does a MG have to do if an MGC sends a Modify with:
>>>    - the Mode property of the LocalControl descriptor set to, for
>>>    instance, receive-only;
>>>    - a Local/Remote Descriptor with an SDP-block containing an
>>>    "a=sendrecv" parameter?
>>>
>>>    In other words, what is the relation beween the a=sendrecv,
>>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP protocol
>>>    and the Mode property of the LocalControl descriptor in the Megaco
>>>    protocol?
>>>
>>>
>>>    Can sb give some advise? Thanks!
>>>    Pascal
>>>
>>>
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
> 
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 

------_=_NextPart_001_01C3BDB4.C5A195D0
Content-Type: text/html
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=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.45">
<TITLE>RE: [Megaco] SDP mode and Megaco mode question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Christian,</FONT>
<BR><FONT SIZE=3D2>Does the Local control mode property takes =
precedence or as Tom pointed out, does the MG always disregard the mode =
in local/remote descriptors??</FONT></P>

<P><FONT SIZE=3D2>Regards</FONT>
<BR><FONT SIZE=3D2>Madhubabu</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Christian Groves [<A =
HREF=3D"mailto:Christian.Groves@ericsson.com">mailto:Christian.Groves@er=
icsson.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, December 07, 2003 8:56 PM</FONT>
<BR><FONT SIZE=3D2>To: Pascal Lambers</FONT>
<BR><FONT SIZE=3D2>Cc: Tom Taylor; Madhubabu Brahmanapally; =
Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Megaco] SDP mode and Megaco mode =
question</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hello Pascal,</FONT>
</P>

<P><FONT SIZE=3D2>I think you have pointed out an issue for the =
Implementors' Guide. This fact </FONT>
<BR><FONT SIZE=3D2>that the Local Control Mode overrides the SDP is =
common practise the only </FONT>
<BR><FONT SIZE=3D2>problem is that it is not clearly stated.</FONT>
</P>

<P><FONT SIZE=3D2>I would propose that :</FONT>
<BR><FONT SIZE=3D2>7.1.7&nbsp;&nbsp; LocalControl descriptor</FONT>
<BR><FONT SIZE=3D2>...</FONT>
<BR><FONT SIZE=3D2>The allowed values for the mode property are =
send-only, receive-only, </FONT>
<BR><FONT SIZE=3D2>send/receive, inactive and loop-back. =
&quot;Send&quot; and &quot;receive&quot; are with respect to </FONT>
<BR><FONT SIZE=3D2>the exterior of the Context, so that, for example, a =
stream set to mode =3D </FONT>
<BR><FONT SIZE=3D2>sendOnly does not pass received media into the =
Context. The default value for </FONT>
<BR><FONT SIZE=3D2>the mode property is &quot;Inactive&quot;. Signals =
and Events are not affected by mode.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&gt;&gt;&gt; The local control mode property =
takes precedence over the local and remote </FONT>
<BR><FONT SIZE=3D2>descriptors.&lt;&lt;&lt;</FONT>
<BR><FONT SIZE=3D2>...</FONT>
</P>

<P><FONT SIZE=3D2>Regards, Christian</FONT>
</P>

<P><FONT SIZE=3D2>Pascal Lambers wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; So would I, but isn't there any RFC statement to =
enforce this opinion?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Pascal</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ----- Original Message ----- </FONT>
<BR><FONT SIZE=3D2>&gt; From: &quot;Tom Taylor&quot; =
&lt;taylor@nortelnetworks.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; To: &quot;Madhubabu Brahmanapally&quot; =
&lt;Madhubabu@veraznet.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: &quot;'Pascal Lambers'&quot; =
&lt;pascal.lambers@pandora.be&gt;; &lt;Megaco@ietf.org&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, December 05, 2003 12:31 AM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Megaco] SDP mode and Megaco mode =
question</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;I would put it bluntly that the MG must =
ignore mode in the SDP.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Madhubabu Brahmanapally wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;The Local Control Descriptor has high =
precedence over the SDP</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;information....</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *From:* Pascal =
Lambers [<A =
HREF=3D"mailto:pascal.lambers@pandora.be">mailto:pascal.lambers@pandora.=
be</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *Sent:* Thursday, =
December 04, 2003 3:05 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *To:* =
Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *Subject:* [Megaco] =
SDP mode and Megaco mode question</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Hello,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Don't know precisely =
how to forumulate this question clearly, so let</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; me put in in two =
different ways...</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; What does a MG have =
to do if an MGC sends a Modify with:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; - the Mode property =
of the LocalControl descriptor set to, for</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; instance, =
receive-only;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; - a Local/Remote =
Descriptor with an SDP-block containing an</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; =
&quot;a=3Dsendrecv&quot; parameter?</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; In other words, what =
is the relation beween the a=3Dsendrecv,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; a=3Dsendonly, =
a=3Dinactive, a=3Drecvonly parameters of the SDP protocol</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; and the Mode property =
of the LocalControl descriptor in the Megaco</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; protocol?</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Can sb give some =
advise? Thanks!</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Pascal</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;<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>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <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>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3BDB4.C5A195D0--

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



From megaco-admin@ietf.org  Mon Dec  8 17:35:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07889
	for <megaco-archive@lists.ietf.org>; Mon, 8 Dec 2003 17:35:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATTy4-0000Sq-1l; Mon, 08 Dec 2003 17:35:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATTxm-0000RR-Dh
	for megaco@optimus.ietf.org; Mon, 08 Dec 2003 17:34:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07869
	for <Megaco@ietf.org>; Mon, 8 Dec 2003 17:34:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATTxj-0007ho-00
	for Megaco@ietf.org; Mon, 08 Dec 2003 17:34:43 -0500
Received: from astra.telenet-ops.be ([195.130.132.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATTxj-0007hk-00
	for Megaco@ietf.org; Mon, 08 Dec 2003 17:34:43 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by astra.telenet-ops.be (Postfix) with SMTP id A633637F70
	for <Megaco@ietf.org>; Mon,  8 Dec 2003 23:34:42 +0100 (MET)
Received: from pas (D5778DD3.kabel.telenet.be [213.119.141.211])
	by astra.telenet-ops.be (Postfix) with SMTP id 64ECD37ED2
	for <Megaco@ietf.org>; Mon,  8 Dec 2003 23:34:42 +0100 (MET)
Message-ID: <006401c3bddc$11acd4e0$b400a8c0@pandora.be>
Reply-To: "Pascal Lambers" <pascal.lambers@pandora.be>
From: "Pascal Lambers" <pascal.lambers@pandora.be>
To: <Megaco@ietf.org>
References: <9E388C880C1ED411AFE1009027E787250526F0AC@mail.veraznet.com> <3FD4F0F9.8080405@ericsson.com>
Subject: Re: [Megaco] SDP mode and Megaco mode question
Date: Mon, 8 Dec 2003 23:38:58 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

It would of course be interesting to know what most gateways currently do
with the "a=..." SDP mode parameter: will they deny it, even if no other
mode has been set? Are there some gateway experts reading this discussion?

I do see Christian's point here: the context prevails. You could look at the
context as as a shell around the RTP(s) it contains.

The annoying consequence is that a MGC which must talk to a Megaco MG has to
start parsing the SDP block. If  a MGC receives a message for its MG from,
say, another MGC, it has to translate the SDP mode to a local control
mode...

Kind regards,
Pascal


----- Original Message ----- 
From: "Christian Groves" <Christian.Groves@ericsson.com>
To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
Cc: "Pascal Lambers" <pascal.lambers@pandora.be>; "Tom Taylor"
<taylor@nortelnetworks.com>; <Megaco@ietf.org>
Sent: Monday, December 08, 2003 10:45 PM
Subject: Re: [Megaco] SDP mode and Megaco mode question


> Hello Madhubabu,
>
> The text I proposed below was:
> "The local control mode property takes precedence over the local and
remote
> descriptors."
>
> The local control mode property will always be set as it defaults to
"inactive".
> So as the local control mode property is set it always takes precedence.
>
> Christian
>
> Madhubabu Brahmanapally wrote:
>
> > Hi Christian,
> > Does the Local control mode property takes precedence or as Tom pointed
> > out, does the MG always disregard the mode in local/remote descriptors??
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Sunday, December 07, 2003 8:56 PM
> > To: Pascal Lambers
> > Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org
> > Subject: Re: [Megaco] SDP mode and Megaco mode question
> >
> >
> > Hello Pascal,
> >
> > I think you have pointed out an issue for the Implementors' Guide. This
> > fact
> > that the Local Control Mode overrides the SDP is common practise the
only
> > problem is that it is not clearly stated.
> >
> > I would propose that :
> > 7.1.7   LocalControl descriptor
> > ...
> > The allowed values for the mode property are send-only, receive-only,
> > send/receive, inactive and loop-back. "Send" and "receive" are with
> > respect to
> > the exterior of the Context, so that, for example, a stream set to mode
=
> > sendOnly does not pass received media into the Context. The default
> > value for
> > the mode property is "Inactive". Signals and Events are not affected by
> > mode.
> >  >>> The local control mode property takes precedence over the local and
> > remote
> > descriptors.<<<
> > ...
> >
> > Regards, Christian
> >
> > Pascal Lambers wrote:
> >
> >  > So would I, but isn't there any RFC statement to enforce this
opinion?
> >  >
> >  > Pascal
> >  >
> >  >
> >  > ----- Original Message -----
> >  > From: "Tom Taylor" <taylor@nortelnetworks.com>
> >  > To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
> >  > Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>
> >  > Sent: Friday, December 05, 2003 12:31 AM
> >  > Subject: Re: [Megaco] SDP mode and Megaco mode question
> >  >
> >  >
> >  >
> >  >>I would put it bluntly that the MG must ignore mode in the SDP.
> >  >>
> >  >>Madhubabu Brahmanapally wrote:
> >  >>
> >  >>
> >  >>>The Local Control Descriptor has high precedence over the SDP
> >  >>>information....
> >  >>>
> >  >>>    -----Original Message-----
> >  >>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
> >  >>>    *Sent:* Thursday, December 04, 2003 3:05 PM
> >  >>>    *To:* Megaco@ietf.org
> >  >>>    *Subject:* [Megaco] SDP mode and Megaco mode question
> >  >>>
> >  >>>    Hello,
> >  >>>
> >  >>>    Don't know precisely how to forumulate this question clearly, so
> > let
> >  >>>    me put in in two different ways...
> >  >>>
> >  >>>    What does a MG have to do if an MGC sends a Modify with:
> >  >>>    - the Mode property of the LocalControl descriptor set to, for
> >  >>>    instance, receive-only;
> >  >>>    - a Local/Remote Descriptor with an SDP-block containing an
> >  >>>    "a=sendrecv" parameter?
> >  >>>
> >  >>>    In other words, what is the relation beween the a=sendrecv,
> >  >>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP
protocol
> >  >>>    and the Mode property of the LocalControl descriptor in the
Megaco
> >  >>>    protocol?
> >  >>>
> >  >>>
> >  >>>    Can sb give some advise? Thanks!
> >  >>>    Pascal
> >  >>>
> >  >>>
> >  >>
> >  >>
> >  >>_______________________________________________
> >  >>Megaco mailing list
> >  >>Megaco@ietf.org
> >  >>https://www1.ietf.org/mailman/listinfo/megaco
> >  >>
> >  >>
> >  >>
> >  >
> >  >
> >  >
> >  >
> >  > _______________________________________________
> >  > Megaco mailing list
> >  > Megaco@ietf.org
> >  > https://www1.ietf.org/mailman/listinfo/megaco
> >  >
> >
>
>
>
>



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


From exim@www1.ietf.org  Mon Dec  8 17:35:29 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07936
	for <megaco-archive@odin.ietf.org>; Mon, 8 Dec 2003 17:35:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATTyG-0000XF-Iz
	for megaco-archive@odin.ietf.org; Mon, 08 Dec 2003 17:35:16 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8MZG2B002056
	for megaco-archive@odin.ietf.org; Mon, 8 Dec 2003 17:35:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATTyG-0000X5-G0
	for megaco-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 17:35:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07886
	for <megaco-web-archive@ietf.org>; Mon, 8 Dec 2003 17:34:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATTyD-0007ia-00
	for megaco-web-archive@ietf.org; Mon, 08 Dec 2003 17:35:13 -0500
Received: from manatick.foretec.com ([4.17.168.5] helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATTyD-0007iW-00
	for megaco-web-archive@ietf.org; Mon, 08 Dec 2003 17:35:13 -0500
Received: from [132.151.6.22] (helo=optimus.ietf.org)
	by manatick with esmtp (Exim 4.24)
	id 1ATTyK-0005s4-BY
	for megaco-web-archive@ietf.org; Mon, 08 Dec 2003 17:35:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATTy4-0000Sq-1l; Mon, 08 Dec 2003 17:35:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATTxm-0000RR-Dh
	for megaco@optimus.ietf.org; Mon, 08 Dec 2003 17:34:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07869
	for <Megaco@ietf.org>; Mon, 8 Dec 2003 17:34:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATTxj-0007ho-00
	for Megaco@ietf.org; Mon, 08 Dec 2003 17:34:43 -0500
Received: from astra.telenet-ops.be ([195.130.132.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATTxj-0007hk-00
	for Megaco@ietf.org; Mon, 08 Dec 2003 17:34:43 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by astra.telenet-ops.be (Postfix) with SMTP id A633637F70
	for <Megaco@ietf.org>; Mon,  8 Dec 2003 23:34:42 +0100 (MET)
Received: from pas (D5778DD3.kabel.telenet.be [213.119.141.211])
	by astra.telenet-ops.be (Postfix) with SMTP id 64ECD37ED2
	for <Megaco@ietf.org>; Mon,  8 Dec 2003 23:34:42 +0100 (MET)
Message-ID: <006401c3bddc$11acd4e0$b400a8c0@pandora.be>
Reply-To: "Pascal Lambers" <pascal.lambers@pandora.be>
From: "Pascal Lambers" <pascal.lambers@pandora.be>
To: <Megaco@ietf.org>
References: <9E388C880C1ED411AFE1009027E787250526F0AC@mail.veraznet.com> <3FD4F0F9.8080405@ericsson.com>
Subject: Re: [Megaco] SDP mode and Megaco mode question
Date: Mon, 8 Dec 2003 23:38:58 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

It would of course be interesting to know what most gateways currently do
with the "a=..." SDP mode parameter: will they deny it, even if no other
mode has been set? Are there some gateway experts reading this discussion?

I do see Christian's point here: the context prevails. You could look at the
context as as a shell around the RTP(s) it contains.

The annoying consequence is that a MGC which must talk to a Megaco MG has to
start parsing the SDP block. If  a MGC receives a message for its MG from,
say, another MGC, it has to translate the SDP mode to a local control
mode...

Kind regards,
Pascal


----- Original Message ----- 
From: "Christian Groves" <Christian.Groves@ericsson.com>
To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
Cc: "Pascal Lambers" <pascal.lambers@pandora.be>; "Tom Taylor"
<taylor@nortelnetworks.com>; <Megaco@ietf.org>
Sent: Monday, December 08, 2003 10:45 PM
Subject: Re: [Megaco] SDP mode and Megaco mode question


> Hello Madhubabu,
>
> The text I proposed below was:
> "The local control mode property takes precedence over the local and
remote
> descriptors."
>
> The local control mode property will always be set as it defaults to
"inactive".
> So as the local control mode property is set it always takes precedence.
>
> Christian
>
> Madhubabu Brahmanapally wrote:
>
> > Hi Christian,
> > Does the Local control mode property takes precedence or as Tom pointed
> > out, does the MG always disregard the mode in local/remote descriptors??
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Sunday, December 07, 2003 8:56 PM
> > To: Pascal Lambers
> > Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org
> > Subject: Re: [Megaco] SDP mode and Megaco mode question
> >
> >
> > Hello Pascal,
> >
> > I think you have pointed out an issue for the Implementors' Guide. This
> > fact
> > that the Local Control Mode overrides the SDP is common practise the
only
> > problem is that it is not clearly stated.
> >
> > I would propose that :
> > 7.1.7   LocalControl descriptor
> > ...
> > The allowed values for the mode property are send-only, receive-only,
> > send/receive, inactive and loop-back. "Send" and "receive" are with
> > respect to
> > the exterior of the Context, so that, for example, a stream set to mode
=
> > sendOnly does not pass received media into the Context. The default
> > value for
> > the mode property is "Inactive". Signals and Events are not affected by
> > mode.
> >  >>> The local control mode property takes precedence over the local and
> > remote
> > descriptors.<<<
> > ...
> >
> > Regards, Christian
> >
> > Pascal Lambers wrote:
> >
> >  > So would I, but isn't there any RFC statement to enforce this
opinion?
> >  >
> >  > Pascal
> >  >
> >  >
> >  > ----- Original Message -----
> >  > From: "Tom Taylor" <taylor@nortelnetworks.com>
> >  > To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
> >  > Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>
> >  > Sent: Friday, December 05, 2003 12:31 AM
> >  > Subject: Re: [Megaco] SDP mode and Megaco mode question
> >  >
> >  >
> >  >
> >  >>I would put it bluntly that the MG must ignore mode in the SDP.
> >  >>
> >  >>Madhubabu Brahmanapally wrote:
> >  >>
> >  >>
> >  >>>The Local Control Descriptor has high precedence over the SDP
> >  >>>information....
> >  >>>
> >  >>>    -----Original Message-----
> >  >>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
> >  >>>    *Sent:* Thursday, December 04, 2003 3:05 PM
> >  >>>    *To:* Megaco@ietf.org
> >  >>>    *Subject:* [Megaco] SDP mode and Megaco mode question
> >  >>>
> >  >>>    Hello,
> >  >>>
> >  >>>    Don't know precisely how to forumulate this question clearly, so
> > let
> >  >>>    me put in in two different ways...
> >  >>>
> >  >>>    What does a MG have to do if an MGC sends a Modify with:
> >  >>>    - the Mode property of the LocalControl descriptor set to, for
> >  >>>    instance, receive-only;
> >  >>>    - a Local/Remote Descriptor with an SDP-block containing an
> >  >>>    "a=sendrecv" parameter?
> >  >>>
> >  >>>    In other words, what is the relation beween the a=sendrecv,
> >  >>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP
protocol
> >  >>>    and the Mode property of the LocalControl descriptor in the
Megaco
> >  >>>    protocol?
> >  >>>
> >  >>>
> >  >>>    Can sb give some advise? Thanks!
> >  >>>    Pascal
> >  >>>
> >  >>>
> >  >>
> >  >>
> >  >>_______________________________________________
> >  >>Megaco mailing list
> >  >>Megaco@ietf.org
> >  >>https://www1.ietf.org/mailman/listinfo/megaco
> >  >>
> >  >>
> >  >>
> >  >
> >  >
> >  >
> >  >
> >  > _______________________________________________
> >  > Megaco mailing list
> >  > Megaco@ietf.org
> >  > https://www1.ietf.org/mailman/listinfo/megaco
> >  >
> >
>
>
>
>



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



From megaco-admin@ietf.org  Tue Dec  9 01:54:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00272
	for <megaco-archive@lists.ietf.org>; Tue, 9 Dec 2003 01:54:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATbkv-0002rm-J5; Tue, 09 Dec 2003 01:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATbjx-0002qr-M4
	for megaco@optimus.ietf.org; Tue, 09 Dec 2003 01:53:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00221
	for <megaco@ietf.org>; Tue, 9 Dec 2003 01:52:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATbju-0001ZG-00
	for megaco@ietf.org; Tue, 09 Dec 2003 01:52:58 -0500
Received: from manatick.foretec.com ([4.17.168.5] helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATbjt-0001ZD-00
	for megaco@ietf.org; Tue, 09 Dec 2003 01:52:57 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by manatick with esmtp (Exim 4.24)
	id 1ATbk3-0002G2-0e
	for megaco@ietf.org; Tue, 09 Dec 2003 01:53:07 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hB8M2iv04212
	for <megaco@ietf.org>; Tue, 9 Dec 2003 09:02:46 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.177]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YHH30GQC; Tue, 9 Dec 2003 09:04:39 +1100
Message-ID: <3FD4F521.6020002@ericsson.com>
Date: Tue, 09 Dec 2003 09:03:13 +1100
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: FND-AD Wang JuLin <JuLin.Wang@alcatel-sbell.com.cn>
CC: megaco@ietf.org
Subject: Re: [Megaco] about error code
References: <C2DB7F5BC458EA4C8EB46B7A4EFF7E76BB1379@bellnet-mail1.sbell.com.cn>
In-Reply-To: <C2DB7F5BC458EA4C8EB46B7A4EFF7E76BB1379@bellnet-mail1.sbell.com.cn>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hello Jerry,

Q.1 The specific context where the termination already resides is returned.

Q.2 Is intereresing... The protocol doesn't specifically disallow
Context=?(Sub,TID=*), it does disallow Context=a(Sub,TID=?). The reason it
disallowed choose on TID in subtract is that there's no point creating resources
and then deleting them. I think this assumption is also valid for choose of
ContextIDs for subtract commands. So as choosing a contextID in subtract is a
violation of this assumption I would say that 401 Protocol Error may be more
appropriate.

Regards, Christian

FND-AD Wang JuLin wrote:
> Hello list,
> 1) Suppose a term has already been added to a specific context. When we add this term again with choose $ context, does the reply message(433 error) contain the old specific context or just the latest choose context?
> 
> As follows:
> MGC to MG
> MEGACO/1 [10.10.0.4] Transaction =1372  {     Context = $ {         Add = tdm/2/1 {                 Media {LocalControl {Mode = SendReceive}}                 }  ,        Add = $ {                Media {Stream=1{LocalControl {Mode = ReceiveOnly},Local { v=0   c=IN IP4 $ m=audio $ RTP/AVP 8 a=ptime:30 }}}                }  }     } 
> 
> MG reply message
> !/1 [10.10.0.11] P=1372{C=${A=tdm/2/1{ER=433{"TerminationID is already in a Context"}}}}
> or
> !/1 [10.10.0.11] P=1372{C=416{A=tdm/2/1{ER=433{"TerminationID is already in a Context"}}}}
> 
> 2) What error will be triggerred if mgc issue subtract message with choose context on all term(*)?
> i.e.
> MGC to MG
> MEGACO/1 [10.10.0.4] Transaction =133 {
>     Context = ${  
>        Subtract  = *
>     }}
> MG reply message
> 
> !/1 [10.10.0.11] P=133{C=${S=*{ER=411{"Transaction refers to an unknown ContextID"}}}}
> 
> 
> Thank you  very much! 
> 
> 
> 
>  best  regards
> 
>>:-)Jerry Wang
> 
> tel:(8621)58541240 ext 9531
> MP:13621761050
> mailto:Julin.Wang@alcatel-sbell.com.cn 
> Alcatel Shanghai Bell Co.LTD
> 
> 
> _______________________________________________
> 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 exim@www1.ietf.org  Tue Dec  9 01:54:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00298
	for <megaco-archive@odin.ietf.org>; Tue, 9 Dec 2003 01:54:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATbl0-0002uR-Ix
	for megaco-archive@odin.ietf.org; Tue, 09 Dec 2003 01:54:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB96s6Au011176
	for megaco-archive@odin.ietf.org; Tue, 9 Dec 2003 01:54:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATbl0-0002u9-Bl
	for megaco-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 01:54:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00265
	for <megaco-web-archive@ietf.org>; Tue, 9 Dec 2003 01:53:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATbkw-0001aI-00
	for megaco-web-archive@ietf.org; Tue, 09 Dec 2003 01:54:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATbkw-0001aC-00
	for megaco-web-archive@ietf.org; Tue, 09 Dec 2003 01:54:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATbkv-0002rm-J5; Tue, 09 Dec 2003 01:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATbjx-0002qr-M4
	for megaco@optimus.ietf.org; Tue, 09 Dec 2003 01:53:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00221
	for <megaco@ietf.org>; Tue, 9 Dec 2003 01:52:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATbju-0001ZG-00
	for megaco@ietf.org; Tue, 09 Dec 2003 01:52:58 -0500
Received: from manatick.foretec.com ([4.17.168.5] helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATbjt-0001ZD-00
	for megaco@ietf.org; Tue, 09 Dec 2003 01:52:57 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by manatick with esmtp (Exim 4.24)
	id 1ATbk3-0002G2-0e
	for megaco@ietf.org; Tue, 09 Dec 2003 01:53:07 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hB8M2iv04212
	for <megaco@ietf.org>; Tue, 9 Dec 2003 09:02:46 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.177]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YHH30GQC; Tue, 9 Dec 2003 09:04:39 +1100
Message-ID: <3FD4F521.6020002@ericsson.com>
Date: Tue, 09 Dec 2003 09:03:13 +1100
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: FND-AD Wang JuLin <JuLin.Wang@alcatel-sbell.com.cn>
CC: megaco@ietf.org
Subject: Re: [Megaco] about error code
References: <C2DB7F5BC458EA4C8EB46B7A4EFF7E76BB1379@bellnet-mail1.sbell.com.cn>
In-Reply-To: <C2DB7F5BC458EA4C8EB46B7A4EFF7E76BB1379@bellnet-mail1.sbell.com.cn>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Jerry,

Q.1 The specific context where the termination already resides is returned.

Q.2 Is intereresing... The protocol doesn't specifically disallow
Context=?(Sub,TID=*), it does disallow Context=a(Sub,TID=?). The reason it
disallowed choose on TID in subtract is that there's no point creating resources
and then deleting them. I think this assumption is also valid for choose of
ContextIDs for subtract commands. So as choosing a contextID in subtract is a
violation of this assumption I would say that 401 Protocol Error may be more
appropriate.

Regards, Christian

FND-AD Wang JuLin wrote:
> Hello list,
> 1) Suppose a term has already been added to a specific context. When we add this term again with choose $ context, does the reply message(433 error) contain the old specific context or just the latest choose context?
> 
> As follows:
> MGC to MG
> MEGACO/1 [10.10.0.4] Transaction =1372  {     Context = $ {         Add = tdm/2/1 {                 Media {LocalControl {Mode = SendReceive}}                 }  ,        Add = $ {                Media {Stream=1{LocalControl {Mode = ReceiveOnly},Local { v=0   c=IN IP4 $ m=audio $ RTP/AVP 8 a=ptime:30 }}}                }  }     } 
> 
> MG reply message
> !/1 [10.10.0.11] P=1372{C=${A=tdm/2/1{ER=433{"TerminationID is already in a Context"}}}}
> or
> !/1 [10.10.0.11] P=1372{C=416{A=tdm/2/1{ER=433{"TerminationID is already in a Context"}}}}
> 
> 2) What error will be triggerred if mgc issue subtract message with choose context on all term(*)?
> i.e.
> MGC to MG
> MEGACO/1 [10.10.0.4] Transaction =133 {
>     Context = ${  
>        Subtract  = *
>     }}
> MG reply message
> 
> !/1 [10.10.0.11] P=133{C=${S=*{ER=411{"Transaction refers to an unknown ContextID"}}}}
> 
> 
> Thank you  very much! 
> 
> 
> 
>  best  regards
> 
>>:-)Jerry Wang
> 
> tel:(8621)58541240 ext 9531
> MP:13621761050
> mailto:Julin.Wang@alcatel-sbell.com.cn 
> Alcatel Shanghai Bell Co.LTD
> 
> 
> _______________________________________________
> 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 exim@www1.ietf.org  Tue Dec  9 01:54:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00313
	for <megaco-archive@odin.ietf.org>; Tue, 9 Dec 2003 01:54:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATbl0-0002uO-IT
	for megaco-archive@odin.ietf.org; Tue, 09 Dec 2003 01:54:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB96s6D8011174
	for megaco-archive@odin.ietf.org; Tue, 9 Dec 2003 01:54:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATbl0-0002u4-7q
	for megaco-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 01:54:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00262
	for <megaco-web-archive@ietf.org>; Tue, 9 Dec 2003 01:53:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATbkw-0001aF-00
	for megaco-web-archive@ietf.org; Tue, 09 Dec 2003 01:54:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATbkw-0001aB-00
	for megaco-web-archive@ietf.org; Tue, 09 Dec 2003 01:54:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATbkw-0002rw-CX; Tue, 09 Dec 2003 01:54:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATbjz-0002qw-JQ
	for megaco@optimus.ietf.org; Tue, 09 Dec 2003 01:53:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00227
	for <Megaco@ietf.org>; Tue, 9 Dec 2003 01:52:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATbjw-0001ZN-00
	for Megaco@ietf.org; Tue, 09 Dec 2003 01:53:00 -0500
Received: from manatick.foretec.com ([4.17.168.5] helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATbjv-0001ZJ-00
	for Megaco@ietf.org; Tue, 09 Dec 2003 01:52:59 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by manatick with esmtp (Exim 4.24)
	id 1ATbk5-0002G2-Bk
	for Megaco@ietf.org; Tue, 09 Dec 2003 01:53:10 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hB8M3Rv06682;
	Tue, 9 Dec 2003 09:03:28 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.177]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YHH30GRF; Tue, 9 Dec 2003 09:05:21 +1100
Message-ID: <3FD4F0F9.8080405@ericsson.com>
Date: Tue, 09 Dec 2003 08:45:29 +1100
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: Madhubabu Brahmanapally <Madhubabu@veraznet.com>
CC: Pascal Lambers <pascal.lambers@pandora.be>,
        Tom Taylor <taylor@nortelnetworks.com>, Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question
References: <9E388C880C1ED411AFE1009027E787250526F0AC@mail.veraznet.com>
In-Reply-To: <9E388C880C1ED411AFE1009027E787250526F0AC@mail.veraznet.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Madhubabu,

The text I proposed below was:
"The local control mode property takes precedence over the local and remote 
descriptors."

The local control mode property will always be set as it defaults to "inactive". 
So as the local control mode property is set it always takes precedence.

Christian

Madhubabu Brahmanapally wrote:

> Hi Christian,
> Does the Local control mode property takes precedence or as Tom pointed 
> out, does the MG always disregard the mode in local/remote descriptors??
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Sunday, December 07, 2003 8:56 PM
> To: Pascal Lambers
> Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org
> Subject: Re: [Megaco] SDP mode and Megaco mode question
> 
> 
> Hello Pascal,
> 
> I think you have pointed out an issue for the Implementors' Guide. This 
> fact
> that the Local Control Mode overrides the SDP is common practise the only
> problem is that it is not clearly stated.
> 
> I would propose that :
> 7.1.7   LocalControl descriptor
> ...
> The allowed values for the mode property are send-only, receive-only,
> send/receive, inactive and loop-back. "Send" and "receive" are with 
> respect to
> the exterior of the Context, so that, for example, a stream set to mode =
> sendOnly does not pass received media into the Context. The default 
> value for
> the mode property is "Inactive". Signals and Events are not affected by 
> mode.
>  >>> The local control mode property takes precedence over the local and 
> remote
> descriptors.<<<
> ...
> 
> Regards, Christian
> 
> Pascal Lambers wrote:
> 
>  > So would I, but isn't there any RFC statement to enforce this opinion?
>  >
>  > Pascal
>  >
>  >
>  > ----- Original Message -----
>  > From: "Tom Taylor" <taylor@nortelnetworks.com>
>  > To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
>  > Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>
>  > Sent: Friday, December 05, 2003 12:31 AM
>  > Subject: Re: [Megaco] SDP mode and Megaco mode question
>  >
>  >
>  >
>  >>I would put it bluntly that the MG must ignore mode in the SDP.
>  >>
>  >>Madhubabu Brahmanapally wrote:
>  >>
>  >>
>  >>>The Local Control Descriptor has high precedence over the SDP
>  >>>information....
>  >>>
>  >>>    -----Original Message-----
>  >>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
>  >>>    *Sent:* Thursday, December 04, 2003 3:05 PM
>  >>>    *To:* Megaco@ietf.org
>  >>>    *Subject:* [Megaco] SDP mode and Megaco mode question
>  >>>
>  >>>    Hello,
>  >>>
>  >>>    Don't know precisely how to forumulate this question clearly, so 
> let
>  >>>    me put in in two different ways...
>  >>>
>  >>>    What does a MG have to do if an MGC sends a Modify with:
>  >>>    - the Mode property of the LocalControl descriptor set to, for
>  >>>    instance, receive-only;
>  >>>    - a Local/Remote Descriptor with an SDP-block containing an
>  >>>    "a=sendrecv" parameter?
>  >>>
>  >>>    In other words, what is the relation beween the a=sendrecv,
>  >>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP protocol
>  >>>    and the Mode property of the LocalControl descriptor in the Megaco
>  >>>    protocol?
>  >>>
>  >>>
>  >>>    Can sb give some advise? Thanks!
>  >>>    Pascal
>  >>>
>  >>>
>  >>
>  >>
>  >>_______________________________________________
>  >>Megaco mailing list
>  >>Megaco@ietf.org
>  >>https://www1.ietf.org/mailman/listinfo/megaco
>  >>
>  >>
>  >>
>  >
>  >
>  >
>  >
>  > _______________________________________________
>  > Megaco mailing list
>  > Megaco@ietf.org
>  > https://www1.ietf.org/mailman/listinfo/megaco
>  >
> 



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



From megaco-admin@ietf.org  Tue Dec  9 02:40:55 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00271
	for <megaco-archive@lists.ietf.org>; Tue, 9 Dec 2003 01:54:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATbkw-0002rw-CX; Tue, 09 Dec 2003 01:54:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATbjz-0002qw-JQ
	for megaco@optimus.ietf.org; Tue, 09 Dec 2003 01:53:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00227
	for <Megaco@ietf.org>; Tue, 9 Dec 2003 01:52:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATbjw-0001ZN-00
	for Megaco@ietf.org; Tue, 09 Dec 2003 01:53:00 -0500
Received: from manatick.foretec.com ([4.17.168.5] helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATbjv-0001ZJ-00
	for Megaco@ietf.org; Tue, 09 Dec 2003 01:52:59 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by manatick with esmtp (Exim 4.24)
	id 1ATbk5-0002G2-Bk
	for Megaco@ietf.org; Tue, 09 Dec 2003 01:53:10 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hB8M3Rv06682;
	Tue, 9 Dec 2003 09:03:28 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.177]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YHH30GRF; Tue, 9 Dec 2003 09:05:21 +1100
Message-ID: <3FD4F0F9.8080405@ericsson.com>
Date: Tue, 09 Dec 2003 08:45:29 +1100
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: Madhubabu Brahmanapally <Madhubabu@veraznet.com>
CC: Pascal Lambers <pascal.lambers@pandora.be>,
        Tom Taylor <taylor@nortelnetworks.com>, Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question
References: <9E388C880C1ED411AFE1009027E787250526F0AC@mail.veraznet.com>
In-Reply-To: <9E388C880C1ED411AFE1009027E787250526F0AC@mail.veraznet.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hello Madhubabu,

The text I proposed below was:
"The local control mode property takes precedence over the local and remote 
descriptors."

The local control mode property will always be set as it defaults to "inactive". 
So as the local control mode property is set it always takes precedence.

Christian

Madhubabu Brahmanapally wrote:

> Hi Christian,
> Does the Local control mode property takes precedence or as Tom pointed 
> out, does the MG always disregard the mode in local/remote descriptors??
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Sunday, December 07, 2003 8:56 PM
> To: Pascal Lambers
> Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org
> Subject: Re: [Megaco] SDP mode and Megaco mode question
> 
> 
> Hello Pascal,
> 
> I think you have pointed out an issue for the Implementors' Guide. This 
> fact
> that the Local Control Mode overrides the SDP is common practise the only
> problem is that it is not clearly stated.
> 
> I would propose that :
> 7.1.7   LocalControl descriptor
> ...
> The allowed values for the mode property are send-only, receive-only,
> send/receive, inactive and loop-back. "Send" and "receive" are with 
> respect to
> the exterior of the Context, so that, for example, a stream set to mode =
> sendOnly does not pass received media into the Context. The default 
> value for
> the mode property is "Inactive". Signals and Events are not affected by 
> mode.
>  >>> The local control mode property takes precedence over the local and 
> remote
> descriptors.<<<
> ...
> 
> Regards, Christian
> 
> Pascal Lambers wrote:
> 
>  > So would I, but isn't there any RFC statement to enforce this opinion?
>  >
>  > Pascal
>  >
>  >
>  > ----- Original Message -----
>  > From: "Tom Taylor" <taylor@nortelnetworks.com>
>  > To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
>  > Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>
>  > Sent: Friday, December 05, 2003 12:31 AM
>  > Subject: Re: [Megaco] SDP mode and Megaco mode question
>  >
>  >
>  >
>  >>I would put it bluntly that the MG must ignore mode in the SDP.
>  >>
>  >>Madhubabu Brahmanapally wrote:
>  >>
>  >>
>  >>>The Local Control Descriptor has high precedence over the SDP
>  >>>information....
>  >>>
>  >>>    -----Original Message-----
>  >>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
>  >>>    *Sent:* Thursday, December 04, 2003 3:05 PM
>  >>>    *To:* Megaco@ietf.org
>  >>>    *Subject:* [Megaco] SDP mode and Megaco mode question
>  >>>
>  >>>    Hello,
>  >>>
>  >>>    Don't know precisely how to forumulate this question clearly, so 
> let
>  >>>    me put in in two different ways...
>  >>>
>  >>>    What does a MG have to do if an MGC sends a Modify with:
>  >>>    - the Mode property of the LocalControl descriptor set to, for
>  >>>    instance, receive-only;
>  >>>    - a Local/Remote Descriptor with an SDP-block containing an
>  >>>    "a=sendrecv" parameter?
>  >>>
>  >>>    In other words, what is the relation beween the a=sendrecv,
>  >>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP protocol
>  >>>    and the Mode property of the LocalControl descriptor in the Megaco
>  >>>    protocol?
>  >>>
>  >>>
>  >>>    Can sb give some advise? Thanks!
>  >>>    Pascal
>  >>>
>  >>>
>  >>
>  >>
>  >>_______________________________________________
>  >>Megaco mailing list
>  >>Megaco@ietf.org
>  >>https://www1.ietf.org/mailman/listinfo/megaco
>  >>
>  >>
>  >>
>  >
>  >
>  >
>  >
>  > _______________________________________________
>  > Megaco mailing list
>  > Megaco@ietf.org
>  > https://www1.ietf.org/mailman/listinfo/megaco
>  >
> 



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


From megaco-admin@ietf.org  Tue Dec  9 18:13:17 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22991
	for <megaco-archive@lists.ietf.org>; Tue, 9 Dec 2003 18:13:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr2L-0007Gr-RO; Tue, 09 Dec 2003 18:13:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr1Z-0007FZ-9b
	for megaco@optimus.ietf.org; Tue, 09 Dec 2003 18:12:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22827
	for <Megaco@ietf.org>; Tue, 9 Dec 2003 18:11:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr1W-0003B2-00
	for Megaco@ietf.org; Tue, 09 Dec 2003 18:12:10 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr1V-0003AE-00
	for Megaco@ietf.org; Tue, 09 Dec 2003 18:12:09 -0500
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 hB9NBcr21166
	for <Megaco@ietf.org>; Tue, 9 Dec 2003 18:11:38 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1XNTV>; Tue, 9 Dec 2003 18:11:39 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D1CAADF@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Pascal Lambers <pascal.lambers@pandora.be>, Megaco@ietf.org
Subject: RE: [Megaco] SDP mode and Megaco mode question
Date: Tue, 9 Dec 2003 18:11:35 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

I don't see that the MGC has to parse SDP.  I think the mode in the SDP
could be used as a suggestion, but the MGC will certainly know whether or
not it wants the media stream flowing.  That is to say, what the MGC wants
trumps what the far-end wants.

Kevin 

-----Original Message-----
From: Pascal Lambers [mailto:pascal.lambers@pandora.be] 
Sent: Monday, December 08, 2003 5:39 PM
To: Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question

It would of course be interesting to know what most gateways currently do
with the "a=..." SDP mode parameter: will they deny it, even if no other
mode has been set? Are there some gateway experts reading this discussion?

I do see Christian's point here: the context prevails. You could look at the
context as as a shell around the RTP(s) it contains.

The annoying consequence is that a MGC which must talk to a Megaco MG has to
start parsing the SDP block. If  a MGC receives a message for its MG from,
say, another MGC, it has to translate the SDP mode to a local control
mode...

Kind regards,
Pascal


----- Original Message -----
From: "Christian Groves" <Christian.Groves@ericsson.com>
To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
Cc: "Pascal Lambers" <pascal.lambers@pandora.be>; "Tom Taylor"
<taylor@nortelnetworks.com>; <Megaco@ietf.org>
Sent: Monday, December 08, 2003 10:45 PM
Subject: Re: [Megaco] SDP mode and Megaco mode question


> Hello Madhubabu,
>
> The text I proposed below was:
> "The local control mode property takes precedence over the local and
remote
> descriptors."
>
> The local control mode property will always be set as it defaults to
"inactive".
> So as the local control mode property is set it always takes precedence.
>
> Christian
>
> Madhubabu Brahmanapally wrote:
>
> > Hi Christian,
> > Does the Local control mode property takes precedence or as Tom pointed
> > out, does the MG always disregard the mode in local/remote descriptors??
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Sunday, December 07, 2003 8:56 PM
> > To: Pascal Lambers
> > Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org
> > Subject: Re: [Megaco] SDP mode and Megaco mode question
> >
> >
> > Hello Pascal,
> >
> > I think you have pointed out an issue for the Implementors' Guide. This
> > fact
> > that the Local Control Mode overrides the SDP is common practise the
only
> > problem is that it is not clearly stated.
> >
> > I would propose that :
> > 7.1.7   LocalControl descriptor
> > ...
> > The allowed values for the mode property are send-only, receive-only,
> > send/receive, inactive and loop-back. "Send" and "receive" are with
> > respect to
> > the exterior of the Context, so that, for example, a stream set to mode
=
> > sendOnly does not pass received media into the Context. The default
> > value for
> > the mode property is "Inactive". Signals and Events are not affected by
> > mode.
> >  >>> The local control mode property takes precedence over the local and
> > remote
> > descriptors.<<<
> > ...
> >
> > Regards, Christian
> >
> > Pascal Lambers wrote:
> >
> >  > So would I, but isn't there any RFC statement to enforce this
opinion?
> >  >
> >  > Pascal
> >  >
> >  >
> >  > ----- Original Message -----
> >  > From: "Tom Taylor" <taylor@nortelnetworks.com>
> >  > To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
> >  > Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>
> >  > Sent: Friday, December 05, 2003 12:31 AM
> >  > Subject: Re: [Megaco] SDP mode and Megaco mode question
> >  >
> >  >
> >  >
> >  >>I would put it bluntly that the MG must ignore mode in the SDP.
> >  >>
> >  >>Madhubabu Brahmanapally wrote:
> >  >>
> >  >>
> >  >>>The Local Control Descriptor has high precedence over the SDP
> >  >>>information....
> >  >>>
> >  >>>    -----Original Message-----
> >  >>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
> >  >>>    *Sent:* Thursday, December 04, 2003 3:05 PM
> >  >>>    *To:* Megaco@ietf.org
> >  >>>    *Subject:* [Megaco] SDP mode and Megaco mode question
> >  >>>
> >  >>>    Hello,
> >  >>>
> >  >>>    Don't know precisely how to forumulate this question clearly, so
> > let
> >  >>>    me put in in two different ways...
> >  >>>
> >  >>>    What does a MG have to do if an MGC sends a Modify with:
> >  >>>    - the Mode property of the LocalControl descriptor set to, for
> >  >>>    instance, receive-only;
> >  >>>    - a Local/Remote Descriptor with an SDP-block containing an
> >  >>>    "a=sendrecv" parameter?
> >  >>>
> >  >>>    In other words, what is the relation beween the a=sendrecv,
> >  >>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP
protocol
> >  >>>    and the Mode property of the LocalControl descriptor in the
Megaco
> >  >>>    protocol?
> >  >>>
> >  >>>
> >  >>>    Can sb give some advise? Thanks!
> >  >>>    Pascal
> >  >>>
> >  >>>
> >  >>
> >  >>
> >  >>_______________________________________________
> >  >>Megaco mailing list
> >  >>Megaco@ietf.org
> >  >>https://www1.ietf.org/mailman/listinfo/megaco
> >  >>
> >  >>
> >  >>
> >  >
> >  >
> >  >
> >  >
> >  > _______________________________________________
> >  > Megaco mailing list
> >  > Megaco@ietf.org
> >  > https://www1.ietf.org/mailman/listinfo/megaco
> >  >
> >
>
>
>
>



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

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


From megaco-admin@ietf.org  Tue Dec  9 18:13:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22990
	for <megaco-archive@lists.ietf.org>; Tue, 9 Dec 2003 18:13:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr2L-0007Gh-6l; Tue, 09 Dec 2003 18:13:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr1Z-0007FY-1a
	for megaco@optimus.ietf.org; Tue, 09 Dec 2003 18:12:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22824
	for <Megaco@ietf.org>; Tue, 9 Dec 2003 18:11:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr1W-0003Az-00
	for Megaco@ietf.org; Tue, 09 Dec 2003 18:12:10 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr1V-0003AD-00
	for Megaco@ietf.org; Tue, 09 Dec 2003 18:12:09 -0500
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 hB9NBcF16061
	for <Megaco@ietf.org>; Tue, 9 Dec 2003 18:11:38 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1XNTX>; Tue, 9 Dec 2003 18:11:39 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D1CAADE@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Christian Groves <Christian.Groves@ericsson.com>,
        Madhubabu Brahmanapally <Madhubabu@veraznet.com>
Cc: Pascal Lambers <pascal.lambers@pandora.be>,
        "Tom-PT Taylor" <taylor@nortelnetworks.com>, Megaco@ietf.org
Subject: RE: [Megaco] SDP mode and Megaco mode question
Date: Tue, 9 Dec 2003 18:11:33 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

If there are no objections, I will include this in the editor's draft of the
IG that I will take to the January SG16 meeting.

The text I have entered is this:

7.1.7	LocalControl descriptor
...
The allowed values for the mode property are send-only, receive-only,
send/receive, inactive and loop-back. "Send" and "receive" are with respect
to the exterior of the Context, so that, for example, a stream set to mode =
sendOnly does not pass received media into the Context. The default value
for the mode property is "Inactive". Signals and Events are not affected by
mode.  >>The LocalControl Mode property takes precedence over any mode
specified in the Local and Remote descriptors.<<

Does that look OK?

Kevin 

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com] 
Sent: Monday, December 08, 2003 4:45 PM
To: Madhubabu Brahmanapally
Cc: Pascal Lambers; Taylor, Tom-PT [CAR:5N00:EXCH]; Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question

Hello Madhubabu,

The text I proposed below was:
"The local control mode property takes precedence over the local and remote
descriptors."

The local control mode property will always be set as it defaults to
"inactive". 
So as the local control mode property is set it always takes precedence.

Christian

Madhubabu Brahmanapally wrote:

> Hi Christian,
> Does the Local control mode property takes precedence or as Tom 
> pointed out, does the MG always disregard the mode in local/remote
descriptors??
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Sunday, December 07, 2003 8:56 PM
> To: Pascal Lambers
> Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org
> Subject: Re: [Megaco] SDP mode and Megaco mode question
> 
> 
> Hello Pascal,
> 
> I think you have pointed out an issue for the Implementors' Guide. 
> This fact that the Local Control Mode overrides the SDP is common 
> practise the only problem is that it is not clearly stated.
> 
> I would propose that :
> 7.1.7   LocalControl descriptor
> ...
> The allowed values for the mode property are send-only, receive-only, 
> send/receive, inactive and loop-back. "Send" and "receive" are with 
> respect to the exterior of the Context, so that, for example, a stream 
> set to mode = sendOnly does not pass received media into the Context. 
> The default value for the mode property is "Inactive". Signals and 
> Events are not affected by mode.
>  >>> The local control mode property takes precedence over the local 
> and remote descriptors.<<< ...
> 
> Regards, Christian
> 
> Pascal Lambers wrote:
> 
>  > So would I, but isn't there any RFC statement to enforce this opinion?
>  >
>  > Pascal
>  >
>  >
>  > ----- Original Message -----
>  > From: "Tom Taylor" <taylor@nortelnetworks.com>  > To: "Madhubabu 
> Brahmanapally" <Madhubabu@veraznet.com>  > Cc: "'Pascal Lambers'" 
> <pascal.lambers@pandora.be>; <Megaco@ietf.org>  > Sent: Friday, 
> December 05, 2003 12:31 AM  > Subject: Re: [Megaco] SDP mode and 
> Megaco mode question  >  >  >  >>I would put it bluntly that the MG 
> must ignore mode in the SDP.
>  >>
>  >>Madhubabu Brahmanapally wrote:
>  >>
>  >>
>  >>>The Local Control Descriptor has high precedence over the SDP  
> >>>information....
>  >>>
>  >>>    -----Original Message-----
>  >>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
>  >>>    *Sent:* Thursday, December 04, 2003 3:05 PM
>  >>>    *To:* Megaco@ietf.org
>  >>>    *Subject:* [Megaco] SDP mode and Megaco mode question
>  >>>
>  >>>    Hello,
>  >>>
>  >>>    Don't know precisely how to forumulate this question clearly, so 
> let
>  >>>    me put in in two different ways...
>  >>>
>  >>>    What does a MG have to do if an MGC sends a Modify with:
>  >>>    - the Mode property of the LocalControl descriptor set to, for
>  >>>    instance, receive-only;
>  >>>    - a Local/Remote Descriptor with an SDP-block containing an
>  >>>    "a=sendrecv" parameter?
>  >>>
>  >>>    In other words, what is the relation beween the a=sendrecv,
>  >>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP protocol
>  >>>    and the Mode property of the LocalControl descriptor in the Megaco
>  >>>    protocol?
>  >>>
>  >>>
>  >>>    Can sb give some advise? Thanks!
>  >>>    Pascal
>  >>>
>  >>>
>  >>
>  >>
>  >>_______________________________________________
>  >>Megaco mailing list
>  >>Megaco@ietf.org
>  >>https://www1.ietf.org/mailman/listinfo/megaco
>  >>
>  >>
>  >>
>  >
>  >
>  >
>  >
>  > _______________________________________________
>  > Megaco mailing list
>  > Megaco@ietf.org
>  > https://www1.ietf.org/mailman/listinfo/megaco
>  >
> 



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

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


From exim@www1.ietf.org  Tue Dec  9 18:13:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23025
	for <megaco-archive@odin.ietf.org>; Tue, 9 Dec 2003 18:13:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr2S-0007IX-Bo
	for megaco-archive@odin.ietf.org; Tue, 09 Dec 2003 18:13:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9ND85W028049
	for megaco-archive@odin.ietf.org; Tue, 9 Dec 2003 18:13:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr2S-0007IK-7L
	for megaco-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 18:13:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22945
	for <megaco-web-archive@ietf.org>; Tue, 9 Dec 2003 18:12:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr2N-0003D1-00
	for megaco-web-archive@ietf.org; Tue, 09 Dec 2003 18:13:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr2N-0003Cv-00
	for megaco-web-archive@ietf.org; Tue, 09 Dec 2003 18:13:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr2L-0007Gh-6l; Tue, 09 Dec 2003 18:13:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr1Z-0007FY-1a
	for megaco@optimus.ietf.org; Tue, 09 Dec 2003 18:12:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22824
	for <Megaco@ietf.org>; Tue, 9 Dec 2003 18:11:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr1W-0003Az-00
	for Megaco@ietf.org; Tue, 09 Dec 2003 18:12:10 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr1V-0003AD-00
	for Megaco@ietf.org; Tue, 09 Dec 2003 18:12:09 -0500
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 hB9NBcF16061
	for <Megaco@ietf.org>; Tue, 9 Dec 2003 18:11:38 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1XNTX>; Tue, 9 Dec 2003 18:11:39 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D1CAADE@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Christian Groves <Christian.Groves@ericsson.com>,
        Madhubabu Brahmanapally <Madhubabu@veraznet.com>
Cc: Pascal Lambers <pascal.lambers@pandora.be>,
        "Tom-PT Taylor" <taylor@nortelnetworks.com>, Megaco@ietf.org
Subject: RE: [Megaco] SDP mode and Megaco mode question
Date: Tue, 9 Dec 2003 18:11:33 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

If there are no objections, I will include this in the editor's draft of the
IG that I will take to the January SG16 meeting.

The text I have entered is this:

7.1.7	LocalControl descriptor
...
The allowed values for the mode property are send-only, receive-only,
send/receive, inactive and loop-back. "Send" and "receive" are with respect
to the exterior of the Context, so that, for example, a stream set to mode =
sendOnly does not pass received media into the Context. The default value
for the mode property is "Inactive". Signals and Events are not affected by
mode.  >>The LocalControl Mode property takes precedence over any mode
specified in the Local and Remote descriptors.<<

Does that look OK?

Kevin 

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com] 
Sent: Monday, December 08, 2003 4:45 PM
To: Madhubabu Brahmanapally
Cc: Pascal Lambers; Taylor, Tom-PT [CAR:5N00:EXCH]; Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question

Hello Madhubabu,

The text I proposed below was:
"The local control mode property takes precedence over the local and remote
descriptors."

The local control mode property will always be set as it defaults to
"inactive". 
So as the local control mode property is set it always takes precedence.

Christian

Madhubabu Brahmanapally wrote:

> Hi Christian,
> Does the Local control mode property takes precedence or as Tom 
> pointed out, does the MG always disregard the mode in local/remote
descriptors??
> 
> Regards
> Madhubabu
> 
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Sunday, December 07, 2003 8:56 PM
> To: Pascal Lambers
> Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org
> Subject: Re: [Megaco] SDP mode and Megaco mode question
> 
> 
> Hello Pascal,
> 
> I think you have pointed out an issue for the Implementors' Guide. 
> This fact that the Local Control Mode overrides the SDP is common 
> practise the only problem is that it is not clearly stated.
> 
> I would propose that :
> 7.1.7   LocalControl descriptor
> ...
> The allowed values for the mode property are send-only, receive-only, 
> send/receive, inactive and loop-back. "Send" and "receive" are with 
> respect to the exterior of the Context, so that, for example, a stream 
> set to mode = sendOnly does not pass received media into the Context. 
> The default value for the mode property is "Inactive". Signals and 
> Events are not affected by mode.
>  >>> The local control mode property takes precedence over the local 
> and remote descriptors.<<< ...
> 
> Regards, Christian
> 
> Pascal Lambers wrote:
> 
>  > So would I, but isn't there any RFC statement to enforce this opinion?
>  >
>  > Pascal
>  >
>  >
>  > ----- Original Message -----
>  > From: "Tom Taylor" <taylor@nortelnetworks.com>  > To: "Madhubabu 
> Brahmanapally" <Madhubabu@veraznet.com>  > Cc: "'Pascal Lambers'" 
> <pascal.lambers@pandora.be>; <Megaco@ietf.org>  > Sent: Friday, 
> December 05, 2003 12:31 AM  > Subject: Re: [Megaco] SDP mode and 
> Megaco mode question  >  >  >  >>I would put it bluntly that the MG 
> must ignore mode in the SDP.
>  >>
>  >>Madhubabu Brahmanapally wrote:
>  >>
>  >>
>  >>>The Local Control Descriptor has high precedence over the SDP  
> >>>information....
>  >>>
>  >>>    -----Original Message-----
>  >>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
>  >>>    *Sent:* Thursday, December 04, 2003 3:05 PM
>  >>>    *To:* Megaco@ietf.org
>  >>>    *Subject:* [Megaco] SDP mode and Megaco mode question
>  >>>
>  >>>    Hello,
>  >>>
>  >>>    Don't know precisely how to forumulate this question clearly, so 
> let
>  >>>    me put in in two different ways...
>  >>>
>  >>>    What does a MG have to do if an MGC sends a Modify with:
>  >>>    - the Mode property of the LocalControl descriptor set to, for
>  >>>    instance, receive-only;
>  >>>    - a Local/Remote Descriptor with an SDP-block containing an
>  >>>    "a=sendrecv" parameter?
>  >>>
>  >>>    In other words, what is the relation beween the a=sendrecv,
>  >>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP protocol
>  >>>    and the Mode property of the LocalControl descriptor in the Megaco
>  >>>    protocol?
>  >>>
>  >>>
>  >>>    Can sb give some advise? Thanks!
>  >>>    Pascal
>  >>>
>  >>>
>  >>
>  >>
>  >>_______________________________________________
>  >>Megaco mailing list
>  >>Megaco@ietf.org
>  >>https://www1.ietf.org/mailman/listinfo/megaco
>  >>
>  >>
>  >>
>  >
>  >
>  >
>  >
>  > _______________________________________________
>  > Megaco mailing list
>  > Megaco@ietf.org
>  > https://www1.ietf.org/mailman/listinfo/megaco
>  >
> 



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

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



From exim@www1.ietf.org  Tue Dec  9 18:13:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23055
	for <megaco-archive@odin.ietf.org>; Tue, 9 Dec 2003 18:13:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr2d-0007Jy-4l
	for megaco-archive@odin.ietf.org; Tue, 09 Dec 2003 18:13:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9NDJcq028136
	for megaco-archive@odin.ietf.org; Tue, 9 Dec 2003 18:13:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr2d-0007Jj-1H
	for megaco-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 18:13:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22964
	for <megaco-web-archive@ietf.org>; Tue, 9 Dec 2003 18:13:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr2N-0003D4-00
	for megaco-web-archive@ietf.org; Tue, 09 Dec 2003 18:13:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr2N-0003Cw-00
	for megaco-web-archive@ietf.org; Tue, 09 Dec 2003 18:13:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr2L-0007Gr-RO; Tue, 09 Dec 2003 18:13:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr1Z-0007FZ-9b
	for megaco@optimus.ietf.org; Tue, 09 Dec 2003 18:12:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22827
	for <Megaco@ietf.org>; Tue, 9 Dec 2003 18:11:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr1W-0003B2-00
	for Megaco@ietf.org; Tue, 09 Dec 2003 18:12:10 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr1V-0003AE-00
	for Megaco@ietf.org; Tue, 09 Dec 2003 18:12:09 -0500
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 hB9NBcr21166
	for <Megaco@ietf.org>; Tue, 9 Dec 2003 18:11:38 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1XNTV>; Tue, 9 Dec 2003 18:11:39 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D1CAADF@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Pascal Lambers <pascal.lambers@pandora.be>, Megaco@ietf.org
Subject: RE: [Megaco] SDP mode and Megaco mode question
Date: Tue, 9 Dec 2003 18:11:35 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

I don't see that the MGC has to parse SDP.  I think the mode in the SDP
could be used as a suggestion, but the MGC will certainly know whether or
not it wants the media stream flowing.  That is to say, what the MGC wants
trumps what the far-end wants.

Kevin 

-----Original Message-----
From: Pascal Lambers [mailto:pascal.lambers@pandora.be] 
Sent: Monday, December 08, 2003 5:39 PM
To: Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question

It would of course be interesting to know what most gateways currently do
with the "a=..." SDP mode parameter: will they deny it, even if no other
mode has been set? Are there some gateway experts reading this discussion?

I do see Christian's point here: the context prevails. You could look at the
context as as a shell around the RTP(s) it contains.

The annoying consequence is that a MGC which must talk to a Megaco MG has to
start parsing the SDP block. If  a MGC receives a message for its MG from,
say, another MGC, it has to translate the SDP mode to a local control
mode...

Kind regards,
Pascal


----- Original Message -----
From: "Christian Groves" <Christian.Groves@ericsson.com>
To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
Cc: "Pascal Lambers" <pascal.lambers@pandora.be>; "Tom Taylor"
<taylor@nortelnetworks.com>; <Megaco@ietf.org>
Sent: Monday, December 08, 2003 10:45 PM
Subject: Re: [Megaco] SDP mode and Megaco mode question


> Hello Madhubabu,
>
> The text I proposed below was:
> "The local control mode property takes precedence over the local and
remote
> descriptors."
>
> The local control mode property will always be set as it defaults to
"inactive".
> So as the local control mode property is set it always takes precedence.
>
> Christian
>
> Madhubabu Brahmanapally wrote:
>
> > Hi Christian,
> > Does the Local control mode property takes precedence or as Tom pointed
> > out, does the MG always disregard the mode in local/remote descriptors??
> >
> > Regards
> > Madhubabu
> >
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Sunday, December 07, 2003 8:56 PM
> > To: Pascal Lambers
> > Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org
> > Subject: Re: [Megaco] SDP mode and Megaco mode question
> >
> >
> > Hello Pascal,
> >
> > I think you have pointed out an issue for the Implementors' Guide. This
> > fact
> > that the Local Control Mode overrides the SDP is common practise the
only
> > problem is that it is not clearly stated.
> >
> > I would propose that :
> > 7.1.7   LocalControl descriptor
> > ...
> > The allowed values for the mode property are send-only, receive-only,
> > send/receive, inactive and loop-back. "Send" and "receive" are with
> > respect to
> > the exterior of the Context, so that, for example, a stream set to mode
=
> > sendOnly does not pass received media into the Context. The default
> > value for
> > the mode property is "Inactive". Signals and Events are not affected by
> > mode.
> >  >>> The local control mode property takes precedence over the local and
> > remote
> > descriptors.<<<
> > ...
> >
> > Regards, Christian
> >
> > Pascal Lambers wrote:
> >
> >  > So would I, but isn't there any RFC statement to enforce this
opinion?
> >  >
> >  > Pascal
> >  >
> >  >
> >  > ----- Original Message -----
> >  > From: "Tom Taylor" <taylor@nortelnetworks.com>
> >  > To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>
> >  > Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>
> >  > Sent: Friday, December 05, 2003 12:31 AM
> >  > Subject: Re: [Megaco] SDP mode and Megaco mode question
> >  >
> >  >
> >  >
> >  >>I would put it bluntly that the MG must ignore mode in the SDP.
> >  >>
> >  >>Madhubabu Brahmanapally wrote:
> >  >>
> >  >>
> >  >>>The Local Control Descriptor has high precedence over the SDP
> >  >>>information....
> >  >>>
> >  >>>    -----Original Message-----
> >  >>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]
> >  >>>    *Sent:* Thursday, December 04, 2003 3:05 PM
> >  >>>    *To:* Megaco@ietf.org
> >  >>>    *Subject:* [Megaco] SDP mode and Megaco mode question
> >  >>>
> >  >>>    Hello,
> >  >>>
> >  >>>    Don't know precisely how to forumulate this question clearly, so
> > let
> >  >>>    me put in in two different ways...
> >  >>>
> >  >>>    What does a MG have to do if an MGC sends a Modify with:
> >  >>>    - the Mode property of the LocalControl descriptor set to, for
> >  >>>    instance, receive-only;
> >  >>>    - a Local/Remote Descriptor with an SDP-block containing an
> >  >>>    "a=sendrecv" parameter?
> >  >>>
> >  >>>    In other words, what is the relation beween the a=sendrecv,
> >  >>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP
protocol
> >  >>>    and the Mode property of the LocalControl descriptor in the
Megaco
> >  >>>    protocol?
> >  >>>
> >  >>>
> >  >>>    Can sb give some advise? Thanks!
> >  >>>    Pascal
> >  >>>
> >  >>>
> >  >>
> >  >>
> >  >>_______________________________________________
> >  >>Megaco mailing list
> >  >>Megaco@ietf.org
> >  >>https://www1.ietf.org/mailman/listinfo/megaco
> >  >>
> >  >>
> >  >>
> >  >
> >  >
> >  >
> >  >
> >  > _______________________________________________
> >  > Megaco mailing list
> >  > Megaco@ietf.org
> >  > https://www1.ietf.org/mailman/listinfo/megaco
> >  >
> >
>
>
>
>



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

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



From megaco-admin@ietf.org  Tue Dec  9 18:52:14 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24906
	for <megaco-archive@lists.ietf.org>; Tue, 9 Dec 2003 18:52:14 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATre4-00008N-P3; Tue, 09 Dec 2003 18:52:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr1x-0007GT-86
	for megaco@optimus.ietf.org; Tue, 09 Dec 2003 18:12:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22861
	for <megaco@ietf.org>; Tue, 9 Dec 2003 18:12:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr1m-0003Bp-00
	for megaco@ietf.org; Tue, 09 Dec 2003 18:12:26 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr1l-0003Ab-00
	for megaco@ietf.org; Tue, 09 Dec 2003 18:12:25 -0500
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 hB9NBcr21163;
	Tue, 9 Dec 2003 18:11:38 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1XNT4>; Tue, 9 Dec 2003 18:11:39 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D1CAAE3@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Christian Groves <Christian.Groves@ericsson.com>,
        Steve Cipolli
	 <SCipolli@radvision.com>
Cc: "'Troy Cauble'" <troy@bell-labs.com>, megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 L), & Short T imers (S)
Date: Tue, 9 Dec 2003 18:11:37 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3BEA9.CBA61CBC"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3BEA9.CBA61CBC
Content-Type: text/plain

Do we need an IG item to outline all this?  I haven't drafted any text, but
I can if we think it would be best.

Kevin 

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com] 
Sent: Sunday, December 07, 2003 11:34 PM
To: Steve Cipolli
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Troy Cauble'; megaco@ietf.org
Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)

Hello Steve,

Nortel were instrumental in coming up with this digit map section so you've
probably got the original intention from Kevin :).

Christian

Steve Cipolli wrote:

> While I tend to agree with most of the answers below, I don't see any 
> of this specified in the specification.  If we can agree that the 
> answers below are the correct interpretation, then we still need 
> clarification in the spec or implementors guide.  I'm still hoping the 
> original author of this section of the spec will clarify the original
intention.
>  
> --Stephen
> 
>     -----Original Message-----
>     From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>     Sent: Tuesday, December 02, 2003 3:18 PM
>     To: Steve Cipolli; 'Troy Cauble'
>     Cc: megaco@ietf.org
>     Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>     Timers ( L), & Short T imers (S)
> 
>     Comments inline. [KJBII]
> 
>     Kevin
> 
>     -----Original Message-----
>     From: Steve Cipolli [mailto:SCipolli@radvision.com]
>     Sent: Tuesday, December 02, 2003 2:40 PM
>     To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH]
>     Cc: megaco@ietf.org
>     Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>     Timers ( L), & Short T imers (S)
> 
>     Perhaps I moved us off track a bit.  It is clear that there is more
>     than one interpretation of the specification with regard to L, S,
>     and to a lesser extent Z.  Can the authors comment on what the
>     intent of the specification was and then perhaps we can reach some
>     conclusion?
> 
>     Here is a partial list of odd digitmaps that seem to defy
>     interpretation:
>             "123Z"                          - "Z" ignored or error?
>     [KJBII] Z here has nothing to modify.  Error.
> 
>             "123S"                  - "S" (or "L") ignored or error?
>     [KJBII] In this instance, the digitmap switches to short interdigit
>     timing after detecting "123".  So, neither.
> 
>             "1ZZ23"                 - First "Z" ignored or error?
>     [KJBII] Because Z is defined as modifying the following digit, and Z
>     cannot modify Z, this should be an error.
> 
>             "1ZSSSSSSSSS23"         - "Z" applied to the "2" or ignored
>     or error?
>     [KJBII] See above.  Error as Z cannot modify S (or L).
> 
>             "135[2Z46]"                     - "Z" applied to "4" or to
>     all in the range (246) or ignored or error?
>     [KJBII] Z applies solely to the 4 here.
> 
>             "135[246Z]79"           - "Z" applied to "7" or ignored or
>     error?
>     [KJBII] Nothing for Z to modify.  Error.
> 
>             "135[2S46]"                     - "S" (or "L") applied to
>     all in range (246) or ignored or error?
>     [KJBII] This is the root of our earlier discussion.  L and S do not
>     modify digits -- they modify timing strategy for the digitmap at the
>     time they are encountered.  [246] means "match 2, 4 or 6".  So
>     [2S46] means... What exactly? "Match 2, short timeout, 4 or 6"?  Or
>     "match 2, 4 or 6 while running the short timer for this digit
>     only"?  Or "run the short timer S after detecting 2, but not if 4 or
>     6 is detected"?  If the string were "135S[246]" then we would start
>     using the short timer before looking for 2, 4 or 6.  If it were
>     "135[246]S", we would start using the short timer AFTER matching 2,
>     4 or 6.  But, with the S timer INSIDE the range, that would indicate
>     that the timer would have to fire to continue.  For instance, if the
>     string were "135[2S46]79", that would seem to indicate that if NO
>     digit was detected for the duration of the short timer, then we
>     should continue with the string to find 7.  This is a contrary usage
>     to S and L at any other point in a digitmap.  I think S and L should
>     be ignored within ranges.  If the MGC wants to use the S or L timer,
>     then put them outside the range.
> 
>             "135[2L4S6]"            - "L" or "S" applied or both
>     (somehow?) or ignored or error?
>     [KJBII] See above -- the same arguments apply here.  I would note
>     that L would never get "detected" here, since S would match first.
> 
>     Thanks,
>     --Stephen
> 
>            
> 
>      > -----Original Message-----
>      > From: Steve Cipolli [mailto:SCipolli@radvision.com]
>      > Sent: Monday, December 01, 2003 8:01 PM
>      > To: 'Troy Cauble'; Kevin Boyle
>      > Cc: megaco@ietf.org
>      > Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>      > Timers ( L), & Short T imers (S)
>      >
>      >
>      > Part of the problem is the term "alternatives" is not clear. 
>      > The text in
>      > 7.1.14.3 says of "alternatives":
>      > A DigitMap, according to this syntax, is defined either by a
>     string or
>      > by a list of strings.  Each string in the list is an alternative
>     event
>      > sequence, specified either as a sequence of digit map symbols or
>     as a
>      > regular expression of digit map symbols.
>      >
>      > My reading of this is that "alternatives" are each string and not
>     the
>      > possible sequences through a range, but admittedly this is not
>     clear.
>      >
>      > The section doesn't seem to explain other odd sequences like
"123Z".
>      > Presumably the "Z" is simply ignored although an error could also
be
>      > considered the proper outcome.
>      >
>      > I must say I prefer an interpretation in which the number of
>     possible
>      > ways to perform the same action is as close to 1 and possible.
>      > Therefore, I'd
>      > prefer to ban (or at least ignore) "L" and "S" within ranges.
>      >
>      > --Stephen
>      >
>      > > -----Original Message-----
>      > > From: Troy Cauble [mailto:troy@bell-labs.com]
>      > > Sent: Monday, December 01, 2003 6:33 PM
>      > > To: Kevin Boyle
>      > > Cc: megaco@ietf.org
>      > > Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>      > > Timers ( L), & Short T imers (S)
>      > >
>      > >
>      > >
>      > >
>      > > I disagree that "L" and "S" are meaningless within a range.
>      > >
>      > > "L" and "S" are used to specify the timer used for "subsequent
>      > > events".
>      > >
>      > > I would argue that the "5" is a subsequent event in "[34L]5",
just
>      > > as it is in "[34]L5".
>      > >
>      > > I would also argue that the "4" in "[3L4]5" is NOT a "subsequent
>      > > event", although one might debate the definition of "subsequent".
>      > >
>      > > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and
>      > "[34]L5" are all
>      > > the same. (And the "L" is not meaningless.)
>      > >
>      > >
>      > > Note that section 7.1.14.3 does bother to specify what happens
>     when
>      > > explicit timing specifiers are only active in some
"alternatives",
>      > or when they
>      > > differ in among alternatives -- the same timer value is used
>     for all
>      > > alternatives.
>      > >
>      > >
>      > > 7.1.14.3:
>      > >
>      > >  > In addition to these event symbols, the string may contain "S"
>      > > and "L"
>      > >  > inter-event timing specifiers and the "Z" duration modifier.
>     "S"
>      > > and "L"
>      > >  > respectively indicate that the MG should use the short (S)
>     timer
>      > > or the  > long (L) timer for subsequent events, overriding the
>      > > timing rules  > described above. If an explicit timing
>     specifier is
>      > > in effect in one  > alternative event sequence, but none is
>     given in
>      > > any other candidate  > alternative, the timer value set by the
>      > > explicit timing specifier must be  > used. If all sequences with
>      > > explicit timing controls are dropped from the  > candidate set,
>      > > timing reverts to the default rules given above. Finally,  > if
>      > > conflicting timing specifiers are in effect in different
>     alternative 
>      > > > sequences, the long timer shall be used.
>      > >
>      > >
>      > > -troy
>      > >
>      > >
>      > >
>      > > Kevin Boyle wrote:
>      > >
>      > > > Since a range means "match one of these", I would agree
>      > > with the assessment
>      > > > that L and S are meaningless within a range.
>      > > > 
>      > > > Kevin
>      > > >
>      > > >
>      > > >   _____
>      > > >
>      > > > From: Steve Cipolli [mailto:SCipolli@radvision.com]
>      > > > Sent: Monday, December 01, 2003 5:22 PM
>      > > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
>      > > > Subject: RE: [Megaco] Digit Maps: Long Duration
>      > > Modifier(Z), Long Timers (
>      > > > L), & Short T imers (S)
>      > > >
>      > > >
>      > > > Thanks for the feedback. 
>      > > > 
>      > > > Just to make sure I understand the L and S cases:
>      > > > They are syntactically legal in a range specification, but
>      > > semantically they
>      > > > have no effect.  Correct?
>      > > > 
>      > > > --Stephen
>      > > >
>      > > > -----Original Message-----
>      > > > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>      > > > Sent: Monday, December 01, 2003 5:15 PM
>      > > > To: Steve Cipolli; megaco@ietf.org
>      > > > Subject: RE: [Megaco] Digit Maps: Long Duration
>      > > Modifier(Z), Long Timers (
>      > > > L), & Short T imers (S)
>      > > >
>      > > >
>      > > > Your interpretation is correct.  Because Z changes how a
>      > > digit is matched,
>      > > > it makes sense within a range.  Think of Z as part of the
>      > > digit it modifies,
>      > > > rather than a separate symbol.
>      > > > 
>      > > > The L and S timers within a digitmap give specific
>      > > instruction as to which
>      > > > timer to run at that point in the digitmap.  While allowed
>      > > in a range, I
>      > > > don't think they provide much value within a range since
>      > they do not
>      > > > actually match anything.  For effective use, they should be
>      > > outside the
>      > > > range.
>      > > > 
>      > > > Kevin
>      > > >
>      > > >
>      > > >   _____
>      > > >
>      > > > From: Steve Cipolli [mailto:SCipolli@radvision.com]
>      > > > Sent: Monday, December 01, 2003 3:26 PM
>      > > > To: megaco@ietf.org
>      > > > Subject: [Megaco] Digit Maps: Long Duration Modifier(Z),
>      > > Long Timers (L), &
>      > > > Short T imers (S)
>      > > >
>      > > >
>      > > > 
>      > > > According to the syntax in RFCs 3015 & 3525 the long
>      > > duration modifier (Z),
>      > > > Long Timers (L), & Short Timers (S) in digit maps can
>      > > appear in a digit
>      > > > range.  For example (where Z is 1000ms):
>      > > >     "135[2Z46]"
>      > > > 
>      > > > Is this valid?  If it is valid, does this mean that the
>      > > fourth digit event
>      > > > must be either 2, 6 (held for any duration) or 4 held for
>     1000 ms?
>      > > > 
>      > > > How does long timer (L) and short timer (S) in a digit
>      > range apply?
>      > > > 
>      > > > --Stephen
>      > > > 
>      > > > 
>      > > >
>      > > >
>      > > > _______________________________________________
>      > > > 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
>      >
> 


------_=_NextPart_001_01C3BEA9.CBA61CBC
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers =
( L), &amp; Short T imers (S)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Do we need an IG item to outline all this?&nbsp; I =
haven't drafted any text, but I can if we think it would be =
best.</FONT>
</P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Christian Groves [<A =
HREF=3D"mailto:Christian.Groves@ericsson.com">mailto:Christian.Groves@er=
icsson.com</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, December 07, 2003 11:34 PM</FONT>
<BR><FONT SIZE=3D2>To: Steve Cipolli</FONT>
<BR><FONT SIZE=3D2>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Troy Cauble'; =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Megaco] Digit Maps: Long Duration =
Modifier(Z), Long Timers ( L), &amp; Short T imers (S)</FONT>
</P>

<P><FONT SIZE=3D2>Hello Steve,</FONT>
</P>

<P><FONT SIZE=3D2>Nortel were instrumental in coming up with this digit =
map section so you've probably got the original intention from Kevin =
:).</FONT></P>

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

<P><FONT SIZE=3D2>Steve Cipolli wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; While I tend to agree with most of the answers =
below, I don't see any </FONT>
<BR><FONT SIZE=3D2>&gt; of this specified in the specification.&nbsp; =
If we can agree that the </FONT>
<BR><FONT SIZE=3D2>&gt; answers below are the correct interpretation, =
then we still need </FONT>
<BR><FONT SIZE=3D2>&gt; clarification in the spec or implementors =
guide.&nbsp; I'm still hoping the </FONT>
<BR><FONT SIZE=3D2>&gt; original author of this section of the spec =
will clarify the original intention.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; --Stephen</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; From: Kevin Boyle [<A =
HREF=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Sent: Tuesday, December =
02, 2003 3:18 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; To: Steve Cipolli; =
'Troy Cauble'</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Cc: =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Subject: RE: [Megaco] =
Digit Maps: Long Duration Modifier(Z), Long</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Timers ( L), &amp; =
Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Comments inline. =
[KJBII]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Kevin</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; From: Steve Cipolli [<A =
HREF=3D"mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Sent: Tuesday, December =
02, 2003 2:40 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; To: 'Troy Cauble'; =
Boyle, Kevin [NCRTP:3Z40:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Cc: =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Subject: RE: [Megaco] =
Digit Maps: Long Duration Modifier(Z), Long</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Timers ( L), &amp; =
Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Perhaps I moved us off =
track a bit.&nbsp; It is clear that there is more</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; than one interpretation =
of the specification with regard to L, S,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; and to a lesser extent =
Z.&nbsp; Can the authors comment on what the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; intent of the =
specification was and then perhaps we can reach some</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; conclusion?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Here is a partial list =
of odd digitmaps that seem to defy</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; interpretation:</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;123Z&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; - &quot;Z&quot; ignored or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] Z here has =
nothing to modify.&nbsp; Error.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;123S&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - &quot;S&quot; (or =
&quot;L&quot;) ignored or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] In this =
instance, the digitmap switches to short interdigit</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; timing after detecting =
&quot;123&quot;.&nbsp; So, neither.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;1ZZ23&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - First &quot;Z&quot; ignored =
or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] Because Z is =
defined as modifying the following digit, and Z</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; cannot modify Z, this =
should be an error.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;1ZSSSSSSSSS23&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; - &quot;Z&quot; applied to the &quot;2&quot; or ignored</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] See =
above.&nbsp; Error as Z cannot modify S (or L).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;135[2Z46]&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
&quot;Z&quot; applied to &quot;4&quot; or to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; all in the range (246) =
or ignored or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] Z applies =
solely to the 4 here.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;135[246Z]79&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; - &quot;Z&quot; applied to &quot;7&quot; or ignored =
or</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] Nothing for Z =
to modify.&nbsp; Error.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;135[2S46]&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
&quot;S&quot; (or &quot;L&quot;) applied to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; all in range (246) or =
ignored or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] This is the =
root of our earlier discussion.&nbsp; L and S do not</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; modify digits -- they =
modify timing strategy for the digitmap at the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; time they are =
encountered.&nbsp; [246] means &quot;match 2, 4 or 6&quot;.&nbsp; =
So</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [2S46] means... What =
exactly? &quot;Match 2, short timeout, 4 or 6&quot;?&nbsp; Or</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &quot;match 2, 4 or 6 =
while running the short timer for this digit</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; only&quot;?&nbsp; Or =
&quot;run the short timer S after detecting 2, but not if 4 or</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 6 is =
detected&quot;?&nbsp; If the string were &quot;135S[246]&quot; then we =
would start</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; using the short timer =
before looking for 2, 4 or 6.&nbsp; If it were</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &quot;135[246]S&quot;, =
we would start using the short timer AFTER matching 2,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 4 or 6.&nbsp; But, with =
the S timer INSIDE the range, that would indicate</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; that the timer would =
have to fire to continue.&nbsp; For instance, if the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; string were =
&quot;135[2S46]79&quot;, that would seem to indicate that if NO</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; digit was detected for =
the duration of the short timer, then we</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; should continue with =
the string to find 7.&nbsp; This is a contrary usage</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; to S and L at any other =
point in a digitmap.&nbsp; I think S and L should</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; be ignored within =
ranges.&nbsp; If the MGC wants to use the S or L timer,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; then put them outside =
the range.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;135[2L4S6]&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; - &quot;L&quot; or &quot;S&quot; applied or =
both</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; (somehow?) or ignored =
or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] See above -- =
the same arguments apply here.&nbsp; I would note</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; that L would never get =
&quot;detected&quot; here, since S would match first.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; --Stephen</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; =
-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; From: Steve =
Cipolli [<A =
HREF=3D"mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Sent: =
Monday, December 01, 2003 8:01 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; To: 'Troy =
Cauble'; Kevin Boyle</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Cc: =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Subject: RE: =
[Megaco] Digit Maps: Long Duration Modifier(Z), Long</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Timers ( L), =
&amp; Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Part of the =
problem is the term &quot;alternatives&quot; is not clear. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; The text =
in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; 7.1.14.3 =
says of &quot;alternatives&quot;:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; A DigitMap, =
according to this syntax, is defined either by a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; string or</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; by a list of =
strings.&nbsp; Each string in the list is an alternative</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; event</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; sequence, =
specified either as a sequence of digit map symbols or</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; as a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; regular =
expression of digit map symbols.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; My reading =
of this is that &quot;alternatives&quot; are each string and not</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; possible =
sequences through a range, but admittedly this is not</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; clear.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; The section =
doesn't seem to explain other odd sequences like =
&quot;123Z&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Presumably =
the &quot;Z&quot; is simply ignored although an error could also =
be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; considered =
the proper outcome.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; I must say I =
prefer an interpretation in which the number of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; possible</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; ways to =
perform the same action is as close to 1 and possible.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Therefore, =
I'd</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; prefer to =
ban (or at least ignore) &quot;L&quot; and &quot;S&quot; within =
ranges.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; =
--Stephen</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; From: =
Troy Cauble [<A =
HREF=3D"mailto:troy@bell-labs.com">mailto:troy@bell-labs.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Sent: =
Monday, December 01, 2003 6:33 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; To: =
Kevin Boyle</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Cc: =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), =
Long</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Timers =
( L), &amp; Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; I =
disagree that &quot;L&quot; and &quot;S&quot; are meaningless within a =
range.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&quot;L&quot; and &quot;S&quot; are used to specify the timer used for =
&quot;subsequent</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
events&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; I would =
argue that the &quot;5&quot; is a subsequent event in =
&quot;[34L]5&quot;, just</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; as it =
is in &quot;[34]L5&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; I would =
also argue that the &quot;4&quot; in &quot;[3L4]5&quot; is NOT a =
&quot;subsequent</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
event&quot;, although one might debate the definition of =
&quot;subsequent&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; In =
summary, I think &quot;[L34]5&quot;, &quot;[3L4]5&quot;, =
&quot;[34L]5&quot;, and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; =
&quot;[34]L5&quot; are all</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; the =
same. (And the &quot;L&quot; is not meaningless.)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Note =
that section 7.1.14.3 does bother to specify what happens</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; when</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
explicit timing specifiers are only active in some =
&quot;alternatives&quot;,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; or when =
they</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; differ =
in among alternatives -- the same timer value is used</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; for all</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
alternatives.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
7.1.14.3:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;&nbsp; =
&gt; In addition to these event symbols, the string may contain =
&quot;S&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; and =
&quot;L&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;&nbsp; =
&gt; inter-event timing specifiers and the &quot;Z&quot; duration =
modifier.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &quot;S&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; and =
&quot;L&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;&nbsp; =
&gt; respectively indicate that the MG should use the short (S)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; timer</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; or =
the&nbsp; &gt; long (L) timer for subsequent events, overriding =
the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; timing =
rules&nbsp; &gt; described above. If an explicit timing</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; specifier is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; in =
effect in one&nbsp; &gt; alternative event sequence, but none is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; given in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; any =
other candidate&nbsp; &gt; alternative, the timer value set by =
the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
explicit timing specifier must be&nbsp; &gt; used. If all sequences =
with</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
explicit timing controls are dropped from the&nbsp; &gt; candidate =
set,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; timing =
reverts to the default rules given above. Finally,&nbsp; &gt; if</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
conflicting timing specifiers are in effect in different</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; alternative </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
sequences, the long timer shall be used.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
-troy</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Kevin =
Boyle wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Since a range means &quot;match one of these&quot;, I would =
agree</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; with =
the assessment</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
that L and S are meaningless within a range.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Kevin</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;&nbsp;&nbsp; _____</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
From: Steve Cipolli [<A =
HREF=3D"mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Sent: Monday, December 01, 2003 5:22 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Subject: RE: [Megaco] Digit Maps: Long Duration</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
Modifier(Z), Long Timers (</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
L), &amp; Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Thanks for the feedback. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Just to make sure I understand the L and S cases:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
They are syntactically legal in a range specification, but</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
semantically they</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
have no effect.&nbsp; Correct?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
--Stephen</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
From: Kevin Boyle [<A =
HREF=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Sent: Monday, December 01, 2003 5:15 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
To: Steve Cipolli; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Subject: RE: [Megaco] Digit Maps: Long Duration</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
Modifier(Z), Long Timers (</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
L), &amp; Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Your interpretation is correct.&nbsp; Because Z changes how a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; digit =
is matched,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; it =
makes sense within a range.&nbsp; Think of Z as part of the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; digit =
it modifies,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
rather than a separate symbol.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
The L and S timers within a digitmap give specific</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
instruction as to which</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
timer to run at that point in the digitmap.&nbsp; While allowed</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; in a =
range, I</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
don't think they provide much value within a range since</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; they do =
not</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
actually match anything.&nbsp; For effective use, they should be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; outside =
the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
range.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Kevin</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;&nbsp;&nbsp; _____</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
From: Steve Cipolli [<A =
HREF=3D"mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Sent: Monday, December 01, 2003 3:26 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
To: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Subject: [Megaco] Digit Maps: Long Duration Modifier(Z),</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Long =
Timers (L), &amp;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
According to the syntax in RFCs 3015 &amp; 3525 the long</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
duration modifier (Z),</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Long Timers (L), &amp; Short Timers (S) in digit maps can</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; appear =
in a digit</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
range.&nbsp; For example (where Z is 1000ms):</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp; &quot;135[2Z46]&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; Is =
this valid?&nbsp; If it is valid, does this mean that the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; fourth =
digit event</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
must be either 2, 6 (held for any duration) or 4 held for</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 1000 ms?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
How does long timer (L) and short timer (S) in a digit</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; range =
apply?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
--Stephen</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; <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>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Megaco =
mailing list</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; <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>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Megaco =
mailing list</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; =
Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; <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>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3BEA9.CBA61CBC--

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


From exim@www1.ietf.org  Tue Dec  9 18:52:17 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24923
	for <megaco-archive@odin.ietf.org>; Tue, 9 Dec 2003 18:52:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATre8-0000A7-O8
	for megaco-archive@odin.ietf.org; Tue, 09 Dec 2003 18:52:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9Nq4Za000611
	for megaco-archive@odin.ietf.org; Tue, 9 Dec 2003 18:52:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATre8-00009M-Eu
	for megaco-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 18:52:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24898
	for <megaco-web-archive@ietf.org>; Tue, 9 Dec 2003 18:51:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATre4-0003yc-00
	for megaco-web-archive@ietf.org; Tue, 09 Dec 2003 18:52:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATre4-0003yZ-00
	for megaco-web-archive@ietf.org; Tue, 09 Dec 2003 18:52:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATre4-00008N-P3; Tue, 09 Dec 2003 18:52:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATr1x-0007GT-86
	for megaco@optimus.ietf.org; Tue, 09 Dec 2003 18:12:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22861
	for <megaco@ietf.org>; Tue, 9 Dec 2003 18:12:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr1m-0003Bp-00
	for megaco@ietf.org; Tue, 09 Dec 2003 18:12:26 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATr1l-0003Ab-00
	for megaco@ietf.org; Tue, 09 Dec 2003 18:12:25 -0500
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 hB9NBcr21163;
	Tue, 9 Dec 2003 18:11:38 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1XNT4>; Tue, 9 Dec 2003 18:11:39 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D1CAAE3@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Christian Groves <Christian.Groves@ericsson.com>,
        Steve Cipolli
	 <SCipolli@radvision.com>
Cc: "'Troy Cauble'" <troy@bell-labs.com>, megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 L), & Short T imers (S)
Date: Tue, 9 Dec 2003 18:11:37 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3BEA9.CBA61CBC"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3BEA9.CBA61CBC
Content-Type: text/plain

Do we need an IG item to outline all this?  I haven't drafted any text, but
I can if we think it would be best.

Kevin 

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com] 
Sent: Sunday, December 07, 2003 11:34 PM
To: Steve Cipolli
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Troy Cauble'; megaco@ietf.org
Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)

Hello Steve,

Nortel were instrumental in coming up with this digit map section so you've
probably got the original intention from Kevin :).

Christian

Steve Cipolli wrote:

> While I tend to agree with most of the answers below, I don't see any 
> of this specified in the specification.  If we can agree that the 
> answers below are the correct interpretation, then we still need 
> clarification in the spec or implementors guide.  I'm still hoping the 
> original author of this section of the spec will clarify the original
intention.
>  
> --Stephen
> 
>     -----Original Message-----
>     From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>     Sent: Tuesday, December 02, 2003 3:18 PM
>     To: Steve Cipolli; 'Troy Cauble'
>     Cc: megaco@ietf.org
>     Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>     Timers ( L), & Short T imers (S)
> 
>     Comments inline. [KJBII]
> 
>     Kevin
> 
>     -----Original Message-----
>     From: Steve Cipolli [mailto:SCipolli@radvision.com]
>     Sent: Tuesday, December 02, 2003 2:40 PM
>     To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH]
>     Cc: megaco@ietf.org
>     Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>     Timers ( L), & Short T imers (S)
> 
>     Perhaps I moved us off track a bit.  It is clear that there is more
>     than one interpretation of the specification with regard to L, S,
>     and to a lesser extent Z.  Can the authors comment on what the
>     intent of the specification was and then perhaps we can reach some
>     conclusion?
> 
>     Here is a partial list of odd digitmaps that seem to defy
>     interpretation:
>             "123Z"                          - "Z" ignored or error?
>     [KJBII] Z here has nothing to modify.  Error.
> 
>             "123S"                  - "S" (or "L") ignored or error?
>     [KJBII] In this instance, the digitmap switches to short interdigit
>     timing after detecting "123".  So, neither.
> 
>             "1ZZ23"                 - First "Z" ignored or error?
>     [KJBII] Because Z is defined as modifying the following digit, and Z
>     cannot modify Z, this should be an error.
> 
>             "1ZSSSSSSSSS23"         - "Z" applied to the "2" or ignored
>     or error?
>     [KJBII] See above.  Error as Z cannot modify S (or L).
> 
>             "135[2Z46]"                     - "Z" applied to "4" or to
>     all in the range (246) or ignored or error?
>     [KJBII] Z applies solely to the 4 here.
> 
>             "135[246Z]79"           - "Z" applied to "7" or ignored or
>     error?
>     [KJBII] Nothing for Z to modify.  Error.
> 
>             "135[2S46]"                     - "S" (or "L") applied to
>     all in range (246) or ignored or error?
>     [KJBII] This is the root of our earlier discussion.  L and S do not
>     modify digits -- they modify timing strategy for the digitmap at the
>     time they are encountered.  [246] means "match 2, 4 or 6".  So
>     [2S46] means... What exactly? "Match 2, short timeout, 4 or 6"?  Or
>     "match 2, 4 or 6 while running the short timer for this digit
>     only"?  Or "run the short timer S after detecting 2, but not if 4 or
>     6 is detected"?  If the string were "135S[246]" then we would start
>     using the short timer before looking for 2, 4 or 6.  If it were
>     "135[246]S", we would start using the short timer AFTER matching 2,
>     4 or 6.  But, with the S timer INSIDE the range, that would indicate
>     that the timer would have to fire to continue.  For instance, if the
>     string were "135[2S46]79", that would seem to indicate that if NO
>     digit was detected for the duration of the short timer, then we
>     should continue with the string to find 7.  This is a contrary usage
>     to S and L at any other point in a digitmap.  I think S and L should
>     be ignored within ranges.  If the MGC wants to use the S or L timer,
>     then put them outside the range.
> 
>             "135[2L4S6]"            - "L" or "S" applied or both
>     (somehow?) or ignored or error?
>     [KJBII] See above -- the same arguments apply here.  I would note
>     that L would never get "detected" here, since S would match first.
> 
>     Thanks,
>     --Stephen
> 
>            
> 
>      > -----Original Message-----
>      > From: Steve Cipolli [mailto:SCipolli@radvision.com]
>      > Sent: Monday, December 01, 2003 8:01 PM
>      > To: 'Troy Cauble'; Kevin Boyle
>      > Cc: megaco@ietf.org
>      > Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>      > Timers ( L), & Short T imers (S)
>      >
>      >
>      > Part of the problem is the term "alternatives" is not clear. 
>      > The text in
>      > 7.1.14.3 says of "alternatives":
>      > A DigitMap, according to this syntax, is defined either by a
>     string or
>      > by a list of strings.  Each string in the list is an alternative
>     event
>      > sequence, specified either as a sequence of digit map symbols or
>     as a
>      > regular expression of digit map symbols.
>      >
>      > My reading of this is that "alternatives" are each string and not
>     the
>      > possible sequences through a range, but admittedly this is not
>     clear.
>      >
>      > The section doesn't seem to explain other odd sequences like
"123Z".
>      > Presumably the "Z" is simply ignored although an error could also
be
>      > considered the proper outcome.
>      >
>      > I must say I prefer an interpretation in which the number of
>     possible
>      > ways to perform the same action is as close to 1 and possible.
>      > Therefore, I'd
>      > prefer to ban (or at least ignore) "L" and "S" within ranges.
>      >
>      > --Stephen
>      >
>      > > -----Original Message-----
>      > > From: Troy Cauble [mailto:troy@bell-labs.com]
>      > > Sent: Monday, December 01, 2003 6:33 PM
>      > > To: Kevin Boyle
>      > > Cc: megaco@ietf.org
>      > > Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
>      > > Timers ( L), & Short T imers (S)
>      > >
>      > >
>      > >
>      > >
>      > > I disagree that "L" and "S" are meaningless within a range.
>      > >
>      > > "L" and "S" are used to specify the timer used for "subsequent
>      > > events".
>      > >
>      > > I would argue that the "5" is a subsequent event in "[34L]5",
just
>      > > as it is in "[34]L5".
>      > >
>      > > I would also argue that the "4" in "[3L4]5" is NOT a "subsequent
>      > > event", although one might debate the definition of "subsequent".
>      > >
>      > > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and
>      > "[34]L5" are all
>      > > the same. (And the "L" is not meaningless.)
>      > >
>      > >
>      > > Note that section 7.1.14.3 does bother to specify what happens
>     when
>      > > explicit timing specifiers are only active in some
"alternatives",
>      > or when they
>      > > differ in among alternatives -- the same timer value is used
>     for all
>      > > alternatives.
>      > >
>      > >
>      > > 7.1.14.3:
>      > >
>      > >  > In addition to these event symbols, the string may contain "S"
>      > > and "L"
>      > >  > inter-event timing specifiers and the "Z" duration modifier.
>     "S"
>      > > and "L"
>      > >  > respectively indicate that the MG should use the short (S)
>     timer
>      > > or the  > long (L) timer for subsequent events, overriding the
>      > > timing rules  > described above. If an explicit timing
>     specifier is
>      > > in effect in one  > alternative event sequence, but none is
>     given in
>      > > any other candidate  > alternative, the timer value set by the
>      > > explicit timing specifier must be  > used. If all sequences with
>      > > explicit timing controls are dropped from the  > candidate set,
>      > > timing reverts to the default rules given above. Finally,  > if
>      > > conflicting timing specifiers are in effect in different
>     alternative 
>      > > > sequences, the long timer shall be used.
>      > >
>      > >
>      > > -troy
>      > >
>      > >
>      > >
>      > > Kevin Boyle wrote:
>      > >
>      > > > Since a range means "match one of these", I would agree
>      > > with the assessment
>      > > > that L and S are meaningless within a range.
>      > > > 
>      > > > Kevin
>      > > >
>      > > >
>      > > >   _____
>      > > >
>      > > > From: Steve Cipolli [mailto:SCipolli@radvision.com]
>      > > > Sent: Monday, December 01, 2003 5:22 PM
>      > > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
>      > > > Subject: RE: [Megaco] Digit Maps: Long Duration
>      > > Modifier(Z), Long Timers (
>      > > > L), & Short T imers (S)
>      > > >
>      > > >
>      > > > Thanks for the feedback. 
>      > > > 
>      > > > Just to make sure I understand the L and S cases:
>      > > > They are syntactically legal in a range specification, but
>      > > semantically they
>      > > > have no effect.  Correct?
>      > > > 
>      > > > --Stephen
>      > > >
>      > > > -----Original Message-----
>      > > > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>      > > > Sent: Monday, December 01, 2003 5:15 PM
>      > > > To: Steve Cipolli; megaco@ietf.org
>      > > > Subject: RE: [Megaco] Digit Maps: Long Duration
>      > > Modifier(Z), Long Timers (
>      > > > L), & Short T imers (S)
>      > > >
>      > > >
>      > > > Your interpretation is correct.  Because Z changes how a
>      > > digit is matched,
>      > > > it makes sense within a range.  Think of Z as part of the
>      > > digit it modifies,
>      > > > rather than a separate symbol.
>      > > > 
>      > > > The L and S timers within a digitmap give specific
>      > > instruction as to which
>      > > > timer to run at that point in the digitmap.  While allowed
>      > > in a range, I
>      > > > don't think they provide much value within a range since
>      > they do not
>      > > > actually match anything.  For effective use, they should be
>      > > outside the
>      > > > range.
>      > > > 
>      > > > Kevin
>      > > >
>      > > >
>      > > >   _____
>      > > >
>      > > > From: Steve Cipolli [mailto:SCipolli@radvision.com]
>      > > > Sent: Monday, December 01, 2003 3:26 PM
>      > > > To: megaco@ietf.org
>      > > > Subject: [Megaco] Digit Maps: Long Duration Modifier(Z),
>      > > Long Timers (L), &
>      > > > Short T imers (S)
>      > > >
>      > > >
>      > > > 
>      > > > According to the syntax in RFCs 3015 & 3525 the long
>      > > duration modifier (Z),
>      > > > Long Timers (L), & Short Timers (S) in digit maps can
>      > > appear in a digit
>      > > > range.  For example (where Z is 1000ms):
>      > > >     "135[2Z46]"
>      > > > 
>      > > > Is this valid?  If it is valid, does this mean that the
>      > > fourth digit event
>      > > > must be either 2, 6 (held for any duration) or 4 held for
>     1000 ms?
>      > > > 
>      > > > How does long timer (L) and short timer (S) in a digit
>      > range apply?
>      > > > 
>      > > > --Stephen
>      > > > 
>      > > > 
>      > > >
>      > > >
>      > > > _______________________________________________
>      > > > 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
>      >
> 


------_=_NextPart_001_01C3BEA9.CBA61CBC
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers =
( L), &amp; Short T imers (S)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Do we need an IG item to outline all this?&nbsp; I =
haven't drafted any text, but I can if we think it would be =
best.</FONT>
</P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Christian Groves [<A =
HREF=3D"mailto:Christian.Groves@ericsson.com">mailto:Christian.Groves@er=
icsson.com</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, December 07, 2003 11:34 PM</FONT>
<BR><FONT SIZE=3D2>To: Steve Cipolli</FONT>
<BR><FONT SIZE=3D2>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Troy Cauble'; =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Megaco] Digit Maps: Long Duration =
Modifier(Z), Long Timers ( L), &amp; Short T imers (S)</FONT>
</P>

<P><FONT SIZE=3D2>Hello Steve,</FONT>
</P>

<P><FONT SIZE=3D2>Nortel were instrumental in coming up with this digit =
map section so you've probably got the original intention from Kevin =
:).</FONT></P>

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

<P><FONT SIZE=3D2>Steve Cipolli wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; While I tend to agree with most of the answers =
below, I don't see any </FONT>
<BR><FONT SIZE=3D2>&gt; of this specified in the specification.&nbsp; =
If we can agree that the </FONT>
<BR><FONT SIZE=3D2>&gt; answers below are the correct interpretation, =
then we still need </FONT>
<BR><FONT SIZE=3D2>&gt; clarification in the spec or implementors =
guide.&nbsp; I'm still hoping the </FONT>
<BR><FONT SIZE=3D2>&gt; original author of this section of the spec =
will clarify the original intention.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; --Stephen</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; From: Kevin Boyle [<A =
HREF=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Sent: Tuesday, December =
02, 2003 3:18 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; To: Steve Cipolli; =
'Troy Cauble'</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Cc: =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Subject: RE: [Megaco] =
Digit Maps: Long Duration Modifier(Z), Long</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Timers ( L), &amp; =
Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Comments inline. =
[KJBII]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Kevin</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; From: Steve Cipolli [<A =
HREF=3D"mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Sent: Tuesday, December =
02, 2003 2:40 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; To: 'Troy Cauble'; =
Boyle, Kevin [NCRTP:3Z40:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Cc: =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Subject: RE: [Megaco] =
Digit Maps: Long Duration Modifier(Z), Long</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Timers ( L), &amp; =
Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Perhaps I moved us off =
track a bit.&nbsp; It is clear that there is more</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; than one interpretation =
of the specification with regard to L, S,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; and to a lesser extent =
Z.&nbsp; Can the authors comment on what the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; intent of the =
specification was and then perhaps we can reach some</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; conclusion?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Here is a partial list =
of odd digitmaps that seem to defy</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; interpretation:</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;123Z&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; - &quot;Z&quot; ignored or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] Z here has =
nothing to modify.&nbsp; Error.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;123S&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - &quot;S&quot; (or =
&quot;L&quot;) ignored or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] In this =
instance, the digitmap switches to short interdigit</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; timing after detecting =
&quot;123&quot;.&nbsp; So, neither.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;1ZZ23&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - First &quot;Z&quot; ignored =
or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] Because Z is =
defined as modifying the following digit, and Z</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; cannot modify Z, this =
should be an error.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;1ZSSSSSSSSS23&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; - &quot;Z&quot; applied to the &quot;2&quot; or ignored</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] See =
above.&nbsp; Error as Z cannot modify S (or L).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;135[2Z46]&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
&quot;Z&quot; applied to &quot;4&quot; or to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; all in the range (246) =
or ignored or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] Z applies =
solely to the 4 here.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;135[246Z]79&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; - &quot;Z&quot; applied to &quot;7&quot; or ignored =
or</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] Nothing for Z =
to modify.&nbsp; Error.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;135[2S46]&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
&quot;S&quot; (or &quot;L&quot;) applied to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; all in range (246) or =
ignored or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] This is the =
root of our earlier discussion.&nbsp; L and S do not</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; modify digits -- they =
modify timing strategy for the digitmap at the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; time they are =
encountered.&nbsp; [246] means &quot;match 2, 4 or 6&quot;.&nbsp; =
So</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [2S46] means... What =
exactly? &quot;Match 2, short timeout, 4 or 6&quot;?&nbsp; Or</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &quot;match 2, 4 or 6 =
while running the short timer for this digit</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; only&quot;?&nbsp; Or =
&quot;run the short timer S after detecting 2, but not if 4 or</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 6 is =
detected&quot;?&nbsp; If the string were &quot;135S[246]&quot; then we =
would start</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; using the short timer =
before looking for 2, 4 or 6.&nbsp; If it were</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &quot;135[246]S&quot;, =
we would start using the short timer AFTER matching 2,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 4 or 6.&nbsp; But, with =
the S timer INSIDE the range, that would indicate</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; that the timer would =
have to fire to continue.&nbsp; For instance, if the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; string were =
&quot;135[2S46]79&quot;, that would seem to indicate that if NO</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; digit was detected for =
the duration of the short timer, then we</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; should continue with =
the string to find 7.&nbsp; This is a contrary usage</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; to S and L at any other =
point in a digitmap.&nbsp; I think S and L should</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; be ignored within =
ranges.&nbsp; If the MGC wants to use the S or L timer,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; then put them outside =
the range.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
&quot;135[2L4S6]&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; - &quot;L&quot; or &quot;S&quot; applied or =
both</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; (somehow?) or ignored =
or error?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [KJBII] See above -- =
the same arguments apply here.&nbsp; I would note</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; that L would never get =
&quot;detected&quot; here, since S would match first.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; --Stephen</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; =
-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; From: Steve =
Cipolli [<A =
HREF=3D"mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Sent: =
Monday, December 01, 2003 8:01 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; To: 'Troy =
Cauble'; Kevin Boyle</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Cc: =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Subject: RE: =
[Megaco] Digit Maps: Long Duration Modifier(Z), Long</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Timers ( L), =
&amp; Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Part of the =
problem is the term &quot;alternatives&quot; is not clear. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; The text =
in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; 7.1.14.3 =
says of &quot;alternatives&quot;:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; A DigitMap, =
according to this syntax, is defined either by a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; string or</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; by a list of =
strings.&nbsp; Each string in the list is an alternative</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; event</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; sequence, =
specified either as a sequence of digit map symbols or</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; as a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; regular =
expression of digit map symbols.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; My reading =
of this is that &quot;alternatives&quot; are each string and not</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; possible =
sequences through a range, but admittedly this is not</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; clear.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; The section =
doesn't seem to explain other odd sequences like =
&quot;123Z&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Presumably =
the &quot;Z&quot; is simply ignored although an error could also =
be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; considered =
the proper outcome.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; I must say I =
prefer an interpretation in which the number of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; possible</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; ways to =
perform the same action is as close to 1 and possible.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Therefore, =
I'd</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; prefer to =
ban (or at least ignore) &quot;L&quot; and &quot;S&quot; within =
ranges.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; =
--Stephen</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; From: =
Troy Cauble [<A =
HREF=3D"mailto:troy@bell-labs.com">mailto:troy@bell-labs.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Sent: =
Monday, December 01, 2003 6:33 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; To: =
Kevin Boyle</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Cc: =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
Subject: Re: [Megaco] Digit Maps: Long Duration Modifier(Z), =
Long</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Timers =
( L), &amp; Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; I =
disagree that &quot;L&quot; and &quot;S&quot; are meaningless within a =
range.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&quot;L&quot; and &quot;S&quot; are used to specify the timer used for =
&quot;subsequent</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
events&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; I would =
argue that the &quot;5&quot; is a subsequent event in =
&quot;[34L]5&quot;, just</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; as it =
is in &quot;[34]L5&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; I would =
also argue that the &quot;4&quot; in &quot;[3L4]5&quot; is NOT a =
&quot;subsequent</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
event&quot;, although one might debate the definition of =
&quot;subsequent&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; In =
summary, I think &quot;[L34]5&quot;, &quot;[3L4]5&quot;, =
&quot;[34L]5&quot;, and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; =
&quot;[34]L5&quot; are all</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; the =
same. (And the &quot;L&quot; is not meaningless.)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Note =
that section 7.1.14.3 does bother to specify what happens</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; when</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
explicit timing specifiers are only active in some =
&quot;alternatives&quot;,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; or when =
they</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; differ =
in among alternatives -- the same timer value is used</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; for all</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
alternatives.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
7.1.14.3:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;&nbsp; =
&gt; In addition to these event symbols, the string may contain =
&quot;S&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; and =
&quot;L&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;&nbsp; =
&gt; inter-event timing specifiers and the &quot;Z&quot; duration =
modifier.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &quot;S&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; and =
&quot;L&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;&nbsp; =
&gt; respectively indicate that the MG should use the short (S)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; timer</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; or =
the&nbsp; &gt; long (L) timer for subsequent events, overriding =
the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; timing =
rules&nbsp; &gt; described above. If an explicit timing</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; specifier is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; in =
effect in one&nbsp; &gt; alternative event sequence, but none is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; given in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; any =
other candidate&nbsp; &gt; alternative, the timer value set by =
the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
explicit timing specifier must be&nbsp; &gt; used. If all sequences =
with</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
explicit timing controls are dropped from the&nbsp; &gt; candidate =
set,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; timing =
reverts to the default rules given above. Finally,&nbsp; &gt; if</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
conflicting timing specifiers are in effect in different</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; alternative </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
sequences, the long timer shall be used.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
-troy</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Kevin =
Boyle wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Since a range means &quot;match one of these&quot;, I would =
agree</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; with =
the assessment</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
that L and S are meaningless within a range.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Kevin</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;&nbsp;&nbsp; _____</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
From: Steve Cipolli [<A =
HREF=3D"mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Sent: Monday, December 01, 2003 5:22 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Subject: RE: [Megaco] Digit Maps: Long Duration</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
Modifier(Z), Long Timers (</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
L), &amp; Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Thanks for the feedback. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Just to make sure I understand the L and S cases:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
They are syntactically legal in a range specification, but</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
semantically they</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
have no effect.&nbsp; Correct?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
--Stephen</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
From: Kevin Boyle [<A =
HREF=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Sent: Monday, December 01, 2003 5:15 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
To: Steve Cipolli; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Subject: RE: [Megaco] Digit Maps: Long Duration</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
Modifier(Z), Long Timers (</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
L), &amp; Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Your interpretation is correct.&nbsp; Because Z changes how a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; digit =
is matched,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; it =
makes sense within a range.&nbsp; Think of Z as part of the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; digit =
it modifies,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
rather than a separate symbol.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
The L and S timers within a digitmap give specific</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
instruction as to which</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
timer to run at that point in the digitmap.&nbsp; While allowed</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; in a =
range, I</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
don't think they provide much value within a range since</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; they do =
not</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
actually match anything.&nbsp; For effective use, they should be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; outside =
the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
range.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Kevin</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;&nbsp;&nbsp; _____</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
From: Steve Cipolli [<A =
HREF=3D"mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Sent: Monday, December 01, 2003 3:26 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
To: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Subject: [Megaco] Digit Maps: Long Duration Modifier(Z),</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Long =
Timers (L), &amp;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Short T imers (S)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
According to the syntax in RFCs 3015 &amp; 3525 the long</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
duration modifier (Z),</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Long Timers (L), &amp; Short Timers (S) in digit maps can</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; appear =
in a digit</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
range.&nbsp; For example (where Z is 1000ms):</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp; &quot;135[2Z46]&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; Is =
this valid?&nbsp; If it is valid, does this mean that the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; fourth =
digit event</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
must be either 2, 6 (held for any duration) or 4 held for</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 1000 ms?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
How does long timer (L) and short timer (S) in a digit</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; range =
apply?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
--Stephen</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; =
Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; &gt; <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>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; Megaco =
mailing list</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; =
Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt; <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>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Megaco =
mailing list</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; =
Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; <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>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3BEA9.CBA61CBC--

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



From megaco-admin@ietf.org  Wed Dec 10 17:58:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23422
	for <megaco-archive@lists.ietf.org>; Wed, 10 Dec 2003 17:58:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUDHN-0004jY-4N; Wed, 10 Dec 2003 17:58:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUDGw-0004io-G4
	for megaco@optimus.ietf.org; Wed, 10 Dec 2003 17:57:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23388
	for <Megaco@ietf.org>; Wed, 10 Dec 2003 17:57:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUDGt-0004J3-00
	for Megaco@ietf.org; Wed, 10 Dec 2003 17:57:31 -0500
Received: from elpis.telenet-ops.be ([195.130.132.40])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUDGr-0004Iz-00
	for Megaco@ietf.org; Wed, 10 Dec 2003 17:57:29 -0500
Received: from localhost (poros.telenet-ops.be [195.130.132.44])
	by elpis.telenet-ops.be (Postfix) with SMTP
	id F113D37F1B; Wed, 10 Dec 2003 23:57:21 +0100 (MET)
Received: from pas (d515297C2.kabel.telenet.be [81.82.151.194])
	by poros.telenet-ops.be (Postfix) with SMTP
	id 714A72E68E3; Wed, 10 Dec 2003 23:57:20 +0100 (MET)
Message-ID: <002701c3bf71$97280d60$b400a8c0@pandora.be>
Reply-To: "Pascal Lambers" <pascal.lambers@pandora.be>
From: "Pascal Lambers" <pascal.lambers@pandora.be>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>, <Megaco@ietf.org>
References: <ABA227A15B80D511BD1A00508BF93A1C0D1CAADF@zrtpd0jq.us.nortel.com>
Subject: Re: [Megaco] SDP mode and Megaco mode question
Date: Thu, 11 Dec 2003 00:01:48 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0024_01C3BF79.F8BA1AC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0024_01C3BF79.F8BA1AC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [Megaco] SDP mode and Megaco mode questionI do think it's =
unavoidable for a MGC to parse the SDP...

For example, you can have MGC1 (controlling a Megaco GW + a black phone) =
talking to MGC2 (controlling a Sip GW + Sip Phone). Now, If the Sip =
phone starts doing some more complex operations it might want the Megaco =
side, controlled by MGC1, to change Mode. And that's exactly where the =
MGC2 has to parse the SDP block to make sure that it can send a =
LocalControlDescriptor to its Megaco gateway. Because the a=3D... =
parameter in the SDP block from the sip-side will be of no use to the =
Megaco GW.

Moreover, the SDP parameters o,s and t, optional according to the Megaco =
RFC but mandatory according to the SDP RFC, cause the same problem...

Pascal


  ----- Original Message -----=20
  From: Kevin Boyle=20
  To: Pascal Lambers ; Megaco@ietf.org=20
  Sent: Wednesday, December 10, 2003 12:11 AM
  Subject: RE: [Megaco] SDP mode and Megaco mode question


  I don't see that the MGC has to parse SDP.  I think the mode in the =
SDP could be used as a suggestion, but the MGC will certainly know =
whether or not it wants the media stream flowing.  That is to say, what =
the MGC wants trumps what the far-end wants.

  Kevin=20

  -----Original Message-----=20
  From: Pascal Lambers [mailto:pascal.lambers@pandora.be]=20
  Sent: Monday, December 08, 2003 5:39 PM=20
  To: Megaco@ietf.org=20
  Subject: Re: [Megaco] SDP mode and Megaco mode question=20

  It would of course be interesting to know what most gateways currently =
do with the "a=3D..." SDP mode parameter: will they deny it, even if no =
other mode has been set? Are there some gateway experts reading this =
discussion?

  I do see Christian's point here: the context prevails. You could look =
at the context as as a shell around the RTP(s) it contains.

  The annoying consequence is that a MGC which must talk to a Megaco MG =
has to start parsing the SDP block. If  a MGC receives a message for its =
MG from, say, another MGC, it has to translate the SDP mode to a local =
control mode...

  Kind regards,=20
  Pascal=20



  ----- Original Message -----=20
  From: "Christian Groves" <Christian.Groves@ericsson.com>=20
  To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>=20
  Cc: "Pascal Lambers" <pascal.lambers@pandora.be>; "Tom Taylor"=20
  <taylor@nortelnetworks.com>; <Megaco@ietf.org>=20
  Sent: Monday, December 08, 2003 10:45 PM=20
  Subject: Re: [Megaco] SDP mode and Megaco mode question=20



  > Hello Madhubabu,=20
  >=20
  > The text I proposed below was:=20
  > "The local control mode property takes precedence over the local and =

  remote=20
  > descriptors."=20
  >=20
  > The local control mode property will always be set as it defaults to =

  "inactive".=20
  > So as the local control mode property is set it always takes =
precedence.=20
  >=20
  > Christian=20
  >=20
  > Madhubabu Brahmanapally wrote:=20
  >=20
  > > Hi Christian,=20
  > > Does the Local control mode property takes precedence or as Tom =
pointed=20
  > > out, does the MG always disregard the mode in local/remote =
descriptors??=20
  > >=20
  > > Regards=20
  > > Madhubabu=20
  > >=20
  > > -----Original Message-----=20
  > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]=20
  > > Sent: Sunday, December 07, 2003 8:56 PM=20
  > > To: Pascal Lambers=20
  > > Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org=20
  > > Subject: Re: [Megaco] SDP mode and Megaco mode question=20
  > >=20
  > >=20
  > > Hello Pascal,=20
  > >=20
  > > I think you have pointed out an issue for the Implementors' Guide. =
This=20
  > > fact=20
  > > that the Local Control Mode overrides the SDP is common practise =
the=20
  only=20
  > > problem is that it is not clearly stated.=20
  > >=20
  > > I would propose that :=20
  > > 7.1.7   LocalControl descriptor=20
  > > ...=20
  > > The allowed values for the mode property are send-only, =
receive-only,=20
  > > send/receive, inactive and loop-back. "Send" and "receive" are =
with=20
  > > respect to=20
  > > the exterior of the Context, so that, for example, a stream set to =
mode=20
  =3D=20
  > > sendOnly does not pass received media into the Context. The =
default=20
  > > value for=20
  > > the mode property is "Inactive". Signals and Events are not =
affected by=20
  > > mode.=20
  > >  >>> The local control mode property takes precedence over the =
local and=20
  > > remote=20
  > > descriptors.<<<=20
  > > ...=20
  > >=20
  > > Regards, Christian=20
  > >=20
  > > Pascal Lambers wrote:=20
  > >=20
  > >  > So would I, but isn't there any RFC statement to enforce this=20
  opinion?=20
  > >  >=20
  > >  > Pascal=20
  > >  >=20
  > >  >=20
  > >  > ----- Original Message -----=20
  > >  > From: "Tom Taylor" <taylor@nortelnetworks.com>=20
  > >  > To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>=20
  > >  > Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; =
<Megaco@ietf.org>=20
  > >  > Sent: Friday, December 05, 2003 12:31 AM=20
  > >  > Subject: Re: [Megaco] SDP mode and Megaco mode question=20
  > >  >=20
  > >  >=20
  > >  >=20
  > >  >>I would put it bluntly that the MG must ignore mode in the SDP. =

  > >  >>=20
  > >  >>Madhubabu Brahmanapally wrote:=20
  > >  >>=20
  > >  >>=20
  > >  >>>The Local Control Descriptor has high precedence over the SDP=20
  > >  >>>information....=20
  > >  >>>=20
  > >  >>>    -----Original Message-----=20
  > >  >>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]=20
  > >  >>>    *Sent:* Thursday, December 04, 2003 3:05 PM=20
  > >  >>>    *To:* Megaco@ietf.org=20
  > >  >>>    *Subject:* [Megaco] SDP mode and Megaco mode question=20
  > >  >>>=20
  > >  >>>    Hello,=20
  > >  >>>=20
  > >  >>>    Don't know precisely how to forumulate this question =
clearly, so=20
  > > let=20
  > >  >>>    me put in in two different ways...=20
  > >  >>>=20
  > >  >>>    What does a MG have to do if an MGC sends a Modify with:=20
  > >  >>>    - the Mode property of the LocalControl descriptor set to, =
for=20
  > >  >>>    instance, receive-only;=20
  > >  >>>    - a Local/Remote Descriptor with an SDP-block containing =
an=20
  > >  >>>    "a=3Dsendrecv" parameter?=20
  > >  >>>=20
  > >  >>>    In other words, what is the relation beween the =
a=3Dsendrecv,=20
  > >  >>>    a=3Dsendonly, a=3Dinactive, a=3Drecvonly parameters of the =
SDP=20
  protocol=20
  > >  >>>    and the Mode property of the LocalControl descriptor in =
the=20
  Megaco=20
  > >  >>>    protocol?=20
  > >  >>>=20
  > >  >>>=20
  > >  >>>    Can sb give some advise? Thanks!=20
  > >  >>>    Pascal=20
  > >  >>>=20
  > >  >>>=20
  > >  >>=20
  > >  >>=20
  > >  >>_______________________________________________=20
  > >  >>Megaco mailing list=20
  > >  >>Megaco@ietf.org=20
  > >  >>https://www1.ietf.org/mailman/listinfo/megaco=20
  > >  >>=20
  > >  >>=20
  > >  >>=20
  > >  >=20
  > >  >=20
  > >  >=20
  > >  >=20
  > >  > _______________________________________________=20
  > >  > Megaco mailing list=20
  > >  > Megaco@ietf.org=20
  > >  > https://www1.ietf.org/mailman/listinfo/megaco=20
  > >  >=20
  > >=20
  >=20
  >=20
  >=20
  >=20




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

------=_NextPart_000_0024_01C3BF79.F8BA1AC0
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><TITLE>RE: [Megaco] SDP mode and Megaco mode =
question</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I do think it's unavoidable for a MGC =
to parse the=20
SDP...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>For example, you can have MGC1 =
(controlling a=20
Megaco GW + a black phone) talking to&nbsp;MGC2 (controlling a Sip GW + =
Sip=20
Phone). Now, If&nbsp;the&nbsp;Sip phone starts doing some more complex=20
operations&nbsp;it might want the Megaco side, controlled by MGC1, to =
change=20
Mode. And that's exactly where the MGC2 has to parse the SDP block to =
make sure=20
that it can send a LocalControlDescriptor to its Megaco gateway. Because =
the=20
a=3D... parameter in the SDP block from the sip-side will be of no use =
to the=20
Megaco GW.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Moreover, the SDP parameters o,s and t, =
optional=20
according to the Megaco RFC but mandatory according to the SDP RFC, =
cause the=20
same problem...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>Pascal</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dkboyle@nortelnetworks.com=20
  href=3D"mailto:kboyle@nortelnetworks.com">Kevin Boyle</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dpascal.lambers@pandora.be=20
  href=3D"mailto:pascal.lambers@pandora.be">Pascal Lambers</A> ; <A=20
  title=3DMegaco@ietf.org =
href=3D"mailto:Megaco@ietf.org">Megaco@ietf.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, December 10, =
2003 12:11=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [Megaco] SDP mode =
and Megaco=20
  mode question</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>I don't see that the MGC has to parse SDP.&nbsp; I =
think the=20
  mode in the SDP could be used as a suggestion, but the MGC will =
certainly know=20
  whether or not it wants the media stream flowing.&nbsp; That is to =
say, what=20
  the MGC wants trumps what the far-end wants.</FONT></P>
  <P><FONT size=3D2>Kevin </FONT></P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Pascal Lambers [<A=20
  =
href=3D"mailto:pascal.lambers@pandora.be">mailto:pascal.lambers@pandora.b=
e</A>]=20
  </FONT><BR><FONT size=3D2>Sent: Monday, December 08, 2003 5:39 =
PM</FONT>=20
  <BR><FONT size=3D2>To: <A=20
  href=3D"mailto:Megaco@ietf.org">Megaco@ietf.org</A></FONT> <BR><FONT=20
  size=3D2>Subject: Re: [Megaco] SDP mode and Megaco mode =
question</FONT> </P>
  <P><FONT size=3D2>It would of course be interesting to know what most =
gateways=20
  currently do with the "a=3D..." SDP mode parameter: will they deny it, =
even if=20
  no other mode has been set? Are there some gateway experts reading =
this=20
  discussion?</FONT></P>
  <P><FONT size=3D2>I do see Christian's point here: the context =
prevails. You=20
  could look at the context as as a shell around the RTP(s) it=20
  contains.</FONT></P>
  <P><FONT size=3D2>The annoying consequence is that a MGC which must =
talk to a=20
  Megaco MG has to start parsing the SDP block. If&nbsp; a MGC receives =
a=20
  message for its MG from, say, another MGC, it has to translate the SDP =
mode to=20
  a local control mode...</FONT></P>
  <P><FONT size=3D2>Kind regards,</FONT> <BR><FONT =
size=3D2>Pascal</FONT> </P><BR>
  <P><FONT size=3D2>----- Original Message -----</FONT> <BR><FONT =
size=3D2>From:=20
  "Christian Groves" &lt;Christian.Groves@ericsson.com&gt;</FONT> =
<BR><FONT=20
  size=3D2>To: "Madhubabu Brahmanapally" =
&lt;Madhubabu@veraznet.com&gt;</FONT>=20
  <BR><FONT size=3D2>Cc: "Pascal Lambers" =
&lt;pascal.lambers@pandora.be&gt;; "Tom=20
  Taylor"</FONT> <BR><FONT size=3D2>&lt;taylor@nortelnetworks.com&gt;;=20
  &lt;Megaco@ietf.org&gt;</FONT> <BR><FONT size=3D2>Sent: Monday, =
December 08,=20
  2003 10:45 PM</FONT> <BR><FONT size=3D2>Subject: Re: [Megaco] SDP mode =
and=20
  Megaco mode question</FONT> </P><BR>
  <P><FONT size=3D2>&gt; Hello Madhubabu,</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; The text I proposed below was:</FONT> =
<BR><FONT=20
  size=3D2>&gt; "The local control mode property takes precedence over =
the local=20
  and</FONT> <BR><FONT size=3D2>remote</FONT> <BR><FONT size=3D2>&gt;=20
  descriptors."</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt; The=20
  local control mode property will always be set as it defaults =
to</FONT>=20
  <BR><FONT size=3D2>"inactive".</FONT> <BR><FONT size=3D2>&gt; So as =
the local=20
  control mode property is set it always takes precedence.</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; Christian</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; Madhubabu Brahmanapally =
wrote:</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; Hi =
Christian,</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; Does the Local control mode property =
takes=20
  precedence or as Tom pointed</FONT> <BR><FONT size=3D2>&gt; &gt; out, =
does the=20
  MG always disregard the mode in local/remote descriptors??</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; Regards</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; Madhubabu</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  From: Christian Groves [<A=20
  =
href=3D"mailto:Christian.Groves@ericsson.com">mailto:Christian.Groves@eri=
csson.com</A>]</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; Sent: Sunday, December 07, 2003 8:56 =
PM</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; To: Pascal Lambers</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; Subject: Re: [Megaco] SDP mode and Megaco mode=20
  question</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; Hello Pascal,</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; I think you =
have pointed=20
  out an issue for the Implementors' Guide. This</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; fact</FONT> <BR><FONT size=3D2>&gt; &gt; that the Local Control =
Mode=20
  overrides the SDP is common practise the</FONT> <BR><FONT =
size=3D2>only</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; problem is that it is not clearly =
stated.</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; I =
would propose=20
  that :</FONT> <BR><FONT size=3D2>&gt; &gt; 7.1.7&nbsp;&nbsp; =
LocalControl=20
  descriptor</FONT> <BR><FONT size=3D2>&gt; &gt; ...</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; The allowed values for the mode property are send-only,=20
  receive-only,</FONT> <BR><FONT size=3D2>&gt; &gt; send/receive, =
inactive and=20
  loop-back. "Send" and "receive" are with</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  respect to</FONT> <BR><FONT size=3D2>&gt; &gt; the exterior of the =
Context, so=20
  that, for example, a stream set to mode</FONT> <BR><FONT =
size=3D2>=3D</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; sendOnly does not pass received media =
into the=20
  Context. The default</FONT> <BR><FONT size=3D2>&gt; &gt; value =
for</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; the mode property is "Inactive". Signals =
and Events=20
  are not affected by</FONT> <BR><FONT size=3D2>&gt; &gt; mode.</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt; The local control mode property =
takes=20
  precedence over the local and</FONT> <BR><FONT size=3D2>&gt; &gt; =
remote</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; descriptors.&lt;&lt;&lt;</FONT> <BR><FONT =

  size=3D2>&gt; &gt; ...</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; Regards, Christian</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; Pascal Lambers wrote:</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; So would I, but =
isn't there=20
  any RFC statement to enforce this</FONT> <BR><FONT =
size=3D2>opinion?</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt; Pascal</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp; &gt; -----=20
  Original Message -----</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; =
From: "Tom=20
  Taylor" &lt;taylor@nortelnetworks.com&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt; To: "Madhubabu Brahmanapally"=20
  &lt;Madhubabu@veraznet.com&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp; &gt;=20
  Cc: "'Pascal Lambers'" &lt;pascal.lambers@pandora.be&gt;;=20
  &lt;Megaco@ietf.org&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; =
Sent:=20
  Friday, December 05, 2003 12:31 AM</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt; Subject: Re: [Megaco] SDP mode and Megaco mode question</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;I would put it bluntly that the MG must ignore mode =
in the=20
  SDP.</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;Madhubabu Brahmanapally wrote:</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;The =
Local Control=20
  Descriptor has high precedence over the SDP</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;information....</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; -----Original Message-----</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *From:* Pascal =
Lambers=20
  [<A=20
  =
href=3D"mailto:pascal.lambers@pandora.be">mailto:pascal.lambers@pandora.b=
e</A>]</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; =
*Sent:*=20
  Thursday, December 04, 2003 3:05 PM</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *To:* Megaco@ietf.org</FONT> <BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *Subject:* =
[Megaco] SDP=20
  mode and Megaco mode question</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Hello,</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Don't know precisely how to forumulate =
this=20
  question clearly, so</FONT> <BR><FONT size=3D2>&gt; &gt; let</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; me put in in =
two=20
  different ways...</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; =
&gt;&gt;&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; What =
does a MG=20
  have to do if an MGC sends a Modify with:</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; - the Mode property of the=20
  LocalControl descriptor set to, for</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; instance, receive-only;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; - a =
Local/Remote=20
  Descriptor with an SDP-block containing an</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; "a=3Dsendrecv" =
parameter?</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; In other words, what is the =
relation=20
  beween the a=3Dsendrecv,</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; a=3Dsendonly, a=3Dinactive, =
a=3Drecvonly parameters=20
  of the SDP</FONT> <BR><FONT size=3D2>protocol</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; and the Mode property of the =

  LocalControl descriptor in the</FONT> <BR><FONT size=3D2>Megaco</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; =
protocol?</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Can sb give some advise? Thanks!</FONT> =

  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; =
Pascal</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;_______________________________________________</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;Megaco mailing list</FONT> <BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;Megaco@ietf.org</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;<A =
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>&gt; &gt;&nbsp; &gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; =
&gt;&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;=20
  _______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt; Megaco mailing list</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt; Megaco@ietf.org</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; <A =

  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>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> </P><BR><BR>
  <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></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0024_01C3BF79.F8BA1AC0--



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


From megaco-admin@ietf.org  Wed Dec 10 18:10:28 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24497
	for <megaco-archive@lists.ietf.org>; Wed, 10 Dec 2003 18:10:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUDSy-0005Sc-WD; Wed, 10 Dec 2003 18:10:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUDSN-0005Rj-Jm
	for megaco@optimus.ietf.org; Wed, 10 Dec 2003 18:09:23 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24333
	for <Megaco@ietf.org>; Wed, 10 Dec 2003 18:09:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUDSK-0004X9-00
	for Megaco@ietf.org; Wed, 10 Dec 2003 18:09:20 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUDSJ-0004WA-00
	for Megaco@ietf.org; Wed, 10 Dec 2003 18:09:19 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBAN8j015744
	for <Megaco@ietf.org>; Wed, 10 Dec 2003 17:08:46 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id SAA06294; Wed, 10 Dec 2003 18:08:44 -0500 (EST)
Cc: Kevin Boyle <kboyle@nortelnetworks.com>, Megaco@ietf.org
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id SAA06280; Wed, 10 Dec 2003 18:08:43 -0500 (EST)
Message-ID: <3FD7A7A2.7020602@bell-labs.com>
Date: Wed, 10 Dec 2003 18:09:22 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pascal Lambers <pascal.lambers@pandora.be>
Original-CC: Kevin Boyle <kboyle@nortelnetworks.com>, Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question
References: <ABA227A15B80D511BD1A00508BF93A1C0D1CAADF@zrtpd0jq.us.nortel.com> <002701c3bf71$97280d60$b400a8c0@pandora.be>
In-Reply-To: <002701c3bf71$97280d60$b400a8c0@pandora.be>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Pascal Lambers wrote:

> 
> I do think it's unavoidable for a MGC to parse the SDP...
>  
> For example, you can have MGC1 (controlling a Megaco GW + a black phone) 
> talking to MGC2 (controlling a Sip GW + Sip Phone). Now, If the Sip 
> phone starts doing some more complex operations it might want the Megaco 
> side, controlled by MGC1, to change Mode. And that's exactly where the 
> MGC2 has to parse the SDP block to make sure that it can send a 
> LocalControlDescriptor to its Megaco gateway. Because the a=... 
> parameter in the SDP block from the sip-side will be of no use to the 
> Megaco GW.
>  
> Moreover, the SDP parameters o,s and t, optional according to the Megaco 
> RFC but mandatory according to the SDP RFC, cause the same problem...
>  
> Pascal

Well that's not just a MGC is it?  It's interworking.
The SIP proxy portion is the reason for parsing the SDP.

A logical (pure) H.248 MGC should not have to parse the SDP.

-troy




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


From exim@www1.ietf.org  Wed Dec 10 18:10:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24517
	for <megaco-archive@odin.ietf.org>; Wed, 10 Dec 2003 18:10:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUDT2-0005UH-90
	for megaco-archive@odin.ietf.org; Wed, 10 Dec 2003 18:10:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBANA4nk021086
	for megaco-archive@odin.ietf.org; Wed, 10 Dec 2003 18:10:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUDT2-0005U1-0W
	for megaco-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 18:10:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24431
	for <megaco-web-archive@ietf.org>; Wed, 10 Dec 2003 18:09:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUDSy-0004YX-00
	for megaco-web-archive@ietf.org; Wed, 10 Dec 2003 18:10:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUDSx-0004YR-00
	for megaco-web-archive@ietf.org; Wed, 10 Dec 2003 18:09:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUDSy-0005Sc-WD; Wed, 10 Dec 2003 18:10:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUDSN-0005Rj-Jm
	for megaco@optimus.ietf.org; Wed, 10 Dec 2003 18:09:23 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24333
	for <Megaco@ietf.org>; Wed, 10 Dec 2003 18:09:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUDSK-0004X9-00
	for Megaco@ietf.org; Wed, 10 Dec 2003 18:09:20 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUDSJ-0004WA-00
	for Megaco@ietf.org; Wed, 10 Dec 2003 18:09:19 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBAN8j015744
	for <Megaco@ietf.org>; Wed, 10 Dec 2003 17:08:46 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id SAA06294; Wed, 10 Dec 2003 18:08:44 -0500 (EST)
Cc: Kevin Boyle <kboyle@nortelnetworks.com>, Megaco@ietf.org
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id SAA06280; Wed, 10 Dec 2003 18:08:43 -0500 (EST)
Message-ID: <3FD7A7A2.7020602@bell-labs.com>
Date: Wed, 10 Dec 2003 18:09:22 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pascal Lambers <pascal.lambers@pandora.be>
Original-CC: Kevin Boyle <kboyle@nortelnetworks.com>, Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question
References: <ABA227A15B80D511BD1A00508BF93A1C0D1CAADF@zrtpd0jq.us.nortel.com> <002701c3bf71$97280d60$b400a8c0@pandora.be>
In-Reply-To: <002701c3bf71$97280d60$b400a8c0@pandora.be>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Pascal Lambers wrote:

> 
> I do think it's unavoidable for a MGC to parse the SDP...
>  
> For example, you can have MGC1 (controlling a Megaco GW + a black phone) 
> talking to MGC2 (controlling a Sip GW + Sip Phone). Now, If the Sip 
> phone starts doing some more complex operations it might want the Megaco 
> side, controlled by MGC1, to change Mode. And that's exactly where the 
> MGC2 has to parse the SDP block to make sure that it can send a 
> LocalControlDescriptor to its Megaco gateway. Because the a=... 
> parameter in the SDP block from the sip-side will be of no use to the 
> Megaco GW.
>  
> Moreover, the SDP parameters o,s and t, optional according to the Megaco 
> RFC but mandatory according to the SDP RFC, cause the same problem...
>  
> Pascal

Well that's not just a MGC is it?  It's interworking.
The SIP proxy portion is the reason for parsing the SDP.

A logical (pure) H.248 MGC should not have to parse the SDP.

-troy




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



From exim@www1.ietf.org  Wed Dec 10 18:21:50 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25555
	for <megaco-archive@odin.ietf.org>; Wed, 10 Dec 2003 18:21:50 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUDe0-0005yZ-Kc
	for megaco-archive@odin.ietf.org; Wed, 10 Dec 2003 18:21:24 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBANLOI9022968
	for megaco-archive@odin.ietf.org; Wed, 10 Dec 2003 18:21:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUDe0-0005yN-1z
	for megaco-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 18:21:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25515
	for <megaco-web-archive@ietf.org>; Wed, 10 Dec 2003 18:21:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUDdw-0004pR-00
	for megaco-web-archive@ietf.org; Wed, 10 Dec 2003 18:21:20 -0500
Received: from [65.246.255.50] (helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUDSU-0004Wn-01
	for megaco-web-archive@ietf.org; Wed, 10 Dec 2003 18:09:30 -0500
Received: from [132.151.6.22] (helo=optimus.ietf.org)
	by manatick with esmtp (Exim 4.24)
	id 1AUDHW-0001eb-6i
	for megaco-web-archive@ietf.org; Wed, 10 Dec 2003 17:58:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUDHN-0004jY-4N; Wed, 10 Dec 2003 17:58:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUDGw-0004io-G4
	for megaco@optimus.ietf.org; Wed, 10 Dec 2003 17:57:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23388
	for <Megaco@ietf.org>; Wed, 10 Dec 2003 17:57:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUDGt-0004J3-00
	for Megaco@ietf.org; Wed, 10 Dec 2003 17:57:31 -0500
Received: from elpis.telenet-ops.be ([195.130.132.40])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUDGr-0004Iz-00
	for Megaco@ietf.org; Wed, 10 Dec 2003 17:57:29 -0500
Received: from localhost (poros.telenet-ops.be [195.130.132.44])
	by elpis.telenet-ops.be (Postfix) with SMTP
	id F113D37F1B; Wed, 10 Dec 2003 23:57:21 +0100 (MET)
Received: from pas (d515297C2.kabel.telenet.be [81.82.151.194])
	by poros.telenet-ops.be (Postfix) with SMTP
	id 714A72E68E3; Wed, 10 Dec 2003 23:57:20 +0100 (MET)
Message-ID: <002701c3bf71$97280d60$b400a8c0@pandora.be>
Reply-To: "Pascal Lambers" <pascal.lambers@pandora.be>
From: "Pascal Lambers" <pascal.lambers@pandora.be>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>, <Megaco@ietf.org>
References: <ABA227A15B80D511BD1A00508BF93A1C0D1CAADF@zrtpd0jq.us.nortel.com>
Subject: Re: [Megaco] SDP mode and Megaco mode question
Date: Thu, 11 Dec 2003 00:01:48 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0024_01C3BF79.F8BA1AC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0024_01C3BF79.F8BA1AC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [Megaco] SDP mode and Megaco mode questionI do think it's =
unavoidable for a MGC to parse the SDP...

For example, you can have MGC1 (controlling a Megaco GW + a black phone) =
talking to MGC2 (controlling a Sip GW + Sip Phone). Now, If the Sip =
phone starts doing some more complex operations it might want the Megaco =
side, controlled by MGC1, to change Mode. And that's exactly where the =
MGC2 has to parse the SDP block to make sure that it can send a =
LocalControlDescriptor to its Megaco gateway. Because the a=3D... =
parameter in the SDP block from the sip-side will be of no use to the =
Megaco GW.

Moreover, the SDP parameters o,s and t, optional according to the Megaco =
RFC but mandatory according to the SDP RFC, cause the same problem...

Pascal


  ----- Original Message -----=20
  From: Kevin Boyle=20
  To: Pascal Lambers ; Megaco@ietf.org=20
  Sent: Wednesday, December 10, 2003 12:11 AM
  Subject: RE: [Megaco] SDP mode and Megaco mode question


  I don't see that the MGC has to parse SDP.  I think the mode in the =
SDP could be used as a suggestion, but the MGC will certainly know =
whether or not it wants the media stream flowing.  That is to say, what =
the MGC wants trumps what the far-end wants.

  Kevin=20

  -----Original Message-----=20
  From: Pascal Lambers [mailto:pascal.lambers@pandora.be]=20
  Sent: Monday, December 08, 2003 5:39 PM=20
  To: Megaco@ietf.org=20
  Subject: Re: [Megaco] SDP mode and Megaco mode question=20

  It would of course be interesting to know what most gateways currently =
do with the "a=3D..." SDP mode parameter: will they deny it, even if no =
other mode has been set? Are there some gateway experts reading this =
discussion?

  I do see Christian's point here: the context prevails. You could look =
at the context as as a shell around the RTP(s) it contains.

  The annoying consequence is that a MGC which must talk to a Megaco MG =
has to start parsing the SDP block. If  a MGC receives a message for its =
MG from, say, another MGC, it has to translate the SDP mode to a local =
control mode...

  Kind regards,=20
  Pascal=20



  ----- Original Message -----=20
  From: "Christian Groves" <Christian.Groves@ericsson.com>=20
  To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>=20
  Cc: "Pascal Lambers" <pascal.lambers@pandora.be>; "Tom Taylor"=20
  <taylor@nortelnetworks.com>; <Megaco@ietf.org>=20
  Sent: Monday, December 08, 2003 10:45 PM=20
  Subject: Re: [Megaco] SDP mode and Megaco mode question=20



  > Hello Madhubabu,=20
  >=20
  > The text I proposed below was:=20
  > "The local control mode property takes precedence over the local and =

  remote=20
  > descriptors."=20
  >=20
  > The local control mode property will always be set as it defaults to =

  "inactive".=20
  > So as the local control mode property is set it always takes =
precedence.=20
  >=20
  > Christian=20
  >=20
  > Madhubabu Brahmanapally wrote:=20
  >=20
  > > Hi Christian,=20
  > > Does the Local control mode property takes precedence or as Tom =
pointed=20
  > > out, does the MG always disregard the mode in local/remote =
descriptors??=20
  > >=20
  > > Regards=20
  > > Madhubabu=20
  > >=20
  > > -----Original Message-----=20
  > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]=20
  > > Sent: Sunday, December 07, 2003 8:56 PM=20
  > > To: Pascal Lambers=20
  > > Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org=20
  > > Subject: Re: [Megaco] SDP mode and Megaco mode question=20
  > >=20
  > >=20
  > > Hello Pascal,=20
  > >=20
  > > I think you have pointed out an issue for the Implementors' Guide. =
This=20
  > > fact=20
  > > that the Local Control Mode overrides the SDP is common practise =
the=20
  only=20
  > > problem is that it is not clearly stated.=20
  > >=20
  > > I would propose that :=20
  > > 7.1.7   LocalControl descriptor=20
  > > ...=20
  > > The allowed values for the mode property are send-only, =
receive-only,=20
  > > send/receive, inactive and loop-back. "Send" and "receive" are =
with=20
  > > respect to=20
  > > the exterior of the Context, so that, for example, a stream set to =
mode=20
  =3D=20
  > > sendOnly does not pass received media into the Context. The =
default=20
  > > value for=20
  > > the mode property is "Inactive". Signals and Events are not =
affected by=20
  > > mode.=20
  > >  >>> The local control mode property takes precedence over the =
local and=20
  > > remote=20
  > > descriptors.<<<=20
  > > ...=20
  > >=20
  > > Regards, Christian=20
  > >=20
  > > Pascal Lambers wrote:=20
  > >=20
  > >  > So would I, but isn't there any RFC statement to enforce this=20
  opinion?=20
  > >  >=20
  > >  > Pascal=20
  > >  >=20
  > >  >=20
  > >  > ----- Original Message -----=20
  > >  > From: "Tom Taylor" <taylor@nortelnetworks.com>=20
  > >  > To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com>=20
  > >  > Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; =
<Megaco@ietf.org>=20
  > >  > Sent: Friday, December 05, 2003 12:31 AM=20
  > >  > Subject: Re: [Megaco] SDP mode and Megaco mode question=20
  > >  >=20
  > >  >=20
  > >  >=20
  > >  >>I would put it bluntly that the MG must ignore mode in the SDP. =

  > >  >>=20
  > >  >>Madhubabu Brahmanapally wrote:=20
  > >  >>=20
  > >  >>=20
  > >  >>>The Local Control Descriptor has high precedence over the SDP=20
  > >  >>>information....=20
  > >  >>>=20
  > >  >>>    -----Original Message-----=20
  > >  >>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be]=20
  > >  >>>    *Sent:* Thursday, December 04, 2003 3:05 PM=20
  > >  >>>    *To:* Megaco@ietf.org=20
  > >  >>>    *Subject:* [Megaco] SDP mode and Megaco mode question=20
  > >  >>>=20
  > >  >>>    Hello,=20
  > >  >>>=20
  > >  >>>    Don't know precisely how to forumulate this question =
clearly, so=20
  > > let=20
  > >  >>>    me put in in two different ways...=20
  > >  >>>=20
  > >  >>>    What does a MG have to do if an MGC sends a Modify with:=20
  > >  >>>    - the Mode property of the LocalControl descriptor set to, =
for=20
  > >  >>>    instance, receive-only;=20
  > >  >>>    - a Local/Remote Descriptor with an SDP-block containing =
an=20
  > >  >>>    "a=3Dsendrecv" parameter?=20
  > >  >>>=20
  > >  >>>    In other words, what is the relation beween the =
a=3Dsendrecv,=20
  > >  >>>    a=3Dsendonly, a=3Dinactive, a=3Drecvonly parameters of the =
SDP=20
  protocol=20
  > >  >>>    and the Mode property of the LocalControl descriptor in =
the=20
  Megaco=20
  > >  >>>    protocol?=20
  > >  >>>=20
  > >  >>>=20
  > >  >>>    Can sb give some advise? Thanks!=20
  > >  >>>    Pascal=20
  > >  >>>=20
  > >  >>>=20
  > >  >>=20
  > >  >>=20
  > >  >>_______________________________________________=20
  > >  >>Megaco mailing list=20
  > >  >>Megaco@ietf.org=20
  > >  >>https://www1.ietf.org/mailman/listinfo/megaco=20
  > >  >>=20
  > >  >>=20
  > >  >>=20
  > >  >=20
  > >  >=20
  > >  >=20
  > >  >=20
  > >  > _______________________________________________=20
  > >  > Megaco mailing list=20
  > >  > Megaco@ietf.org=20
  > >  > https://www1.ietf.org/mailman/listinfo/megaco=20
  > >  >=20
  > >=20
  >=20
  >=20
  >=20
  >=20




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

------=_NextPart_000_0024_01C3BF79.F8BA1AC0
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><TITLE>RE: [Megaco] SDP mode and Megaco mode =
question</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I do think it's unavoidable for a MGC =
to parse the=20
SDP...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>For example, you can have MGC1 =
(controlling a=20
Megaco GW + a black phone) talking to&nbsp;MGC2 (controlling a Sip GW + =
Sip=20
Phone). Now, If&nbsp;the&nbsp;Sip phone starts doing some more complex=20
operations&nbsp;it might want the Megaco side, controlled by MGC1, to =
change=20
Mode. And that's exactly where the MGC2 has to parse the SDP block to =
make sure=20
that it can send a LocalControlDescriptor to its Megaco gateway. Because =
the=20
a=3D... parameter in the SDP block from the sip-side will be of no use =
to the=20
Megaco GW.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Moreover, the SDP parameters o,s and t, =
optional=20
according to the Megaco RFC but mandatory according to the SDP RFC, =
cause the=20
same problem...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>Pascal</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dkboyle@nortelnetworks.com=20
  href=3D"mailto:kboyle@nortelnetworks.com">Kevin Boyle</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dpascal.lambers@pandora.be=20
  href=3D"mailto:pascal.lambers@pandora.be">Pascal Lambers</A> ; <A=20
  title=3DMegaco@ietf.org =
href=3D"mailto:Megaco@ietf.org">Megaco@ietf.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, December 10, =
2003 12:11=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [Megaco] SDP mode =
and Megaco=20
  mode question</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>I don't see that the MGC has to parse SDP.&nbsp; I =
think the=20
  mode in the SDP could be used as a suggestion, but the MGC will =
certainly know=20
  whether or not it wants the media stream flowing.&nbsp; That is to =
say, what=20
  the MGC wants trumps what the far-end wants.</FONT></P>
  <P><FONT size=3D2>Kevin </FONT></P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Pascal Lambers [<A=20
  =
href=3D"mailto:pascal.lambers@pandora.be">mailto:pascal.lambers@pandora.b=
e</A>]=20
  </FONT><BR><FONT size=3D2>Sent: Monday, December 08, 2003 5:39 =
PM</FONT>=20
  <BR><FONT size=3D2>To: <A=20
  href=3D"mailto:Megaco@ietf.org">Megaco@ietf.org</A></FONT> <BR><FONT=20
  size=3D2>Subject: Re: [Megaco] SDP mode and Megaco mode =
question</FONT> </P>
  <P><FONT size=3D2>It would of course be interesting to know what most =
gateways=20
  currently do with the "a=3D..." SDP mode parameter: will they deny it, =
even if=20
  no other mode has been set? Are there some gateway experts reading =
this=20
  discussion?</FONT></P>
  <P><FONT size=3D2>I do see Christian's point here: the context =
prevails. You=20
  could look at the context as as a shell around the RTP(s) it=20
  contains.</FONT></P>
  <P><FONT size=3D2>The annoying consequence is that a MGC which must =
talk to a=20
  Megaco MG has to start parsing the SDP block. If&nbsp; a MGC receives =
a=20
  message for its MG from, say, another MGC, it has to translate the SDP =
mode to=20
  a local control mode...</FONT></P>
  <P><FONT size=3D2>Kind regards,</FONT> <BR><FONT =
size=3D2>Pascal</FONT> </P><BR>
  <P><FONT size=3D2>----- Original Message -----</FONT> <BR><FONT =
size=3D2>From:=20
  "Christian Groves" &lt;Christian.Groves@ericsson.com&gt;</FONT> =
<BR><FONT=20
  size=3D2>To: "Madhubabu Brahmanapally" =
&lt;Madhubabu@veraznet.com&gt;</FONT>=20
  <BR><FONT size=3D2>Cc: "Pascal Lambers" =
&lt;pascal.lambers@pandora.be&gt;; "Tom=20
  Taylor"</FONT> <BR><FONT size=3D2>&lt;taylor@nortelnetworks.com&gt;;=20
  &lt;Megaco@ietf.org&gt;</FONT> <BR><FONT size=3D2>Sent: Monday, =
December 08,=20
  2003 10:45 PM</FONT> <BR><FONT size=3D2>Subject: Re: [Megaco] SDP mode =
and=20
  Megaco mode question</FONT> </P><BR>
  <P><FONT size=3D2>&gt; Hello Madhubabu,</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; The text I proposed below was:</FONT> =
<BR><FONT=20
  size=3D2>&gt; "The local control mode property takes precedence over =
the local=20
  and</FONT> <BR><FONT size=3D2>remote</FONT> <BR><FONT size=3D2>&gt;=20
  descriptors."</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt; The=20
  local control mode property will always be set as it defaults =
to</FONT>=20
  <BR><FONT size=3D2>"inactive".</FONT> <BR><FONT size=3D2>&gt; So as =
the local=20
  control mode property is set it always takes precedence.</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; Christian</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; Madhubabu Brahmanapally =
wrote:</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; Hi =
Christian,</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; Does the Local control mode property =
takes=20
  precedence or as Tom pointed</FONT> <BR><FONT size=3D2>&gt; &gt; out, =
does the=20
  MG always disregard the mode in local/remote descriptors??</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; Regards</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; Madhubabu</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  From: Christian Groves [<A=20
  =
href=3D"mailto:Christian.Groves@ericsson.com">mailto:Christian.Groves@eri=
csson.com</A>]</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; Sent: Sunday, December 07, 2003 8:56 =
PM</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; To: Pascal Lambers</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; Subject: Re: [Megaco] SDP mode and Megaco mode=20
  question</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; Hello Pascal,</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; I think you =
have pointed=20
  out an issue for the Implementors' Guide. This</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; fact</FONT> <BR><FONT size=3D2>&gt; &gt; that the Local Control =
Mode=20
  overrides the SDP is common practise the</FONT> <BR><FONT =
size=3D2>only</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; problem is that it is not clearly =
stated.</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; I =
would propose=20
  that :</FONT> <BR><FONT size=3D2>&gt; &gt; 7.1.7&nbsp;&nbsp; =
LocalControl=20
  descriptor</FONT> <BR><FONT size=3D2>&gt; &gt; ...</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; The allowed values for the mode property are send-only,=20
  receive-only,</FONT> <BR><FONT size=3D2>&gt; &gt; send/receive, =
inactive and=20
  loop-back. "Send" and "receive" are with</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  respect to</FONT> <BR><FONT size=3D2>&gt; &gt; the exterior of the =
Context, so=20
  that, for example, a stream set to mode</FONT> <BR><FONT =
size=3D2>=3D</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; sendOnly does not pass received media =
into the=20
  Context. The default</FONT> <BR><FONT size=3D2>&gt; &gt; value =
for</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; the mode property is "Inactive". Signals =
and Events=20
  are not affected by</FONT> <BR><FONT size=3D2>&gt; &gt; mode.</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt; The local control mode property =
takes=20
  precedence over the local and</FONT> <BR><FONT size=3D2>&gt; &gt; =
remote</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; descriptors.&lt;&lt;&lt;</FONT> <BR><FONT =

  size=3D2>&gt; &gt; ...</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; Regards, Christian</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; Pascal Lambers wrote:</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; So would I, but =
isn't there=20
  any RFC statement to enforce this</FONT> <BR><FONT =
size=3D2>opinion?</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt; Pascal</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp; &gt; -----=20
  Original Message -----</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; =
From: "Tom=20
  Taylor" &lt;taylor@nortelnetworks.com&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt; To: "Madhubabu Brahmanapally"=20
  &lt;Madhubabu@veraznet.com&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp; &gt;=20
  Cc: "'Pascal Lambers'" &lt;pascal.lambers@pandora.be&gt;;=20
  &lt;Megaco@ietf.org&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; =
Sent:=20
  Friday, December 05, 2003 12:31 AM</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt; Subject: Re: [Megaco] SDP mode and Megaco mode question</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;I would put it bluntly that the MG must ignore mode =
in the=20
  SDP.</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;Madhubabu Brahmanapally wrote:</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;The =
Local Control=20
  Descriptor has high precedence over the SDP</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;information....</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; -----Original Message-----</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *From:* Pascal =
Lambers=20
  [<A=20
  =
href=3D"mailto:pascal.lambers@pandora.be">mailto:pascal.lambers@pandora.b=
e</A>]</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; =
*Sent:*=20
  Thursday, December 04, 2003 3:05 PM</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *To:* Megaco@ietf.org</FONT> <BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; *Subject:* =
[Megaco] SDP=20
  mode and Megaco mode question</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Hello,</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Don't know precisely how to forumulate =
this=20
  question clearly, so</FONT> <BR><FONT size=3D2>&gt; &gt; let</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; me put in in =
two=20
  different ways...</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; =
&gt;&gt;&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; What =
does a MG=20
  have to do if an MGC sends a Modify with:</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; - the Mode property of the=20
  LocalControl descriptor set to, for</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; instance, receive-only;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; - a =
Local/Remote=20
  Descriptor with an SDP-block containing an</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; "a=3Dsendrecv" =
parameter?</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; In other words, what is the =
relation=20
  beween the a=3Dsendrecv,</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; a=3Dsendonly, a=3Dinactive, =
a=3Drecvonly parameters=20
  of the SDP</FONT> <BR><FONT size=3D2>protocol</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; and the Mode property of the =

  LocalControl descriptor in the</FONT> <BR><FONT size=3D2>Megaco</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; =
protocol?</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Can sb give some advise? Thanks!</FONT> =

  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; =
Pascal</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp;=20
  &gt;&gt;_______________________________________________</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;Megaco mailing list</FONT> <BR><FONT=20
  size=3D2>&gt; &gt;&nbsp; &gt;&gt;Megaco@ietf.org</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;<A =
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>&gt; &gt;&nbsp; &gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; =
&gt;&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt;=20
  _______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; &gt; Megaco mailing list</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
  &gt; Megaco@ietf.org</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; <A =

  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>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> </P><BR><BR>
  <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></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0024_01C3BF79.F8BA1AC0--



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



From megaco-admin@ietf.org  Wed Dec 10 19:36:32 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27849
	for <megaco-archive@lists.ietf.org>; Wed, 10 Dec 2003 19:36:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUEoE-0008KV-80; Wed, 10 Dec 2003 19:36:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUEno-0008K2-1w
	for megaco@optimus.ietf.org; Wed, 10 Dec 2003 19:35:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27765
	for <megaco@ietf.org>; Wed, 10 Dec 2003 19:35:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUEnl-0005z7-00
	for megaco@ietf.org; Wed, 10 Dec 2003 19:35:33 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUEnk-0005yc-00
	for megaco@ietf.org; Wed, 10 Dec 2003 19:35:32 -0500
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 hBB0YvX00169
	for <megaco@ietf.org>; Wed, 10 Dec 2003 19:34:57 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1YF3N>; Wed, 10 Dec 2003 19:34:58 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D21F907@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Steve Cipolli <SCipolli@radvision.com>,
        "'Troy Cauble'"
	 <troy@bell-labs.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 L), & Short T imers (S)
Date: Wed, 10 Dec 2003 19:34:56 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

All,

Here is some proposed text for this.  I will include this in the IG.  Please
let me know any changes that would be better.  New text is demarcated by
>><<.

7.1.14.3	DigitMap Syntax
...
In addition to these event symbols, the string may contain "S" and "L"
inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
respectively indicate that the MG should use the short (S) timer or the long
(L) timer for subsequent events, overriding the timing rules described
above. If an explicit timing specifier is in effect in one alternative event
sequence, but none is given in any other candidate alternative, the timer
value set by the explicit timing specifier must be used. If all sequences
with explicit timing controls are dropped from the candidate set, timing
reverts to the default rules given above. >>If used inside a range notation,
the S and L specifiers shall be ignored.<<  Finally, if conflicting timing
specifiers are in effect in different alternative sequences, the long timer
shall be used.

A "Z" designates a long duration event: placed in front of the symbol(s)
designating the event(s) which satisfy a given digit position, it indicates
that that position is satisfied only if the duration of the event exceeds
the long-duration threshold. The value of this threshold is assumed to be
provisioned in the MG.  >>If the Z specifier is not followed by a digit (0-9
or A-K), then the MG shall reject the digitmap as invalid protocol.  When
used in a range notation, the Z specifier applies solely to the immediately
following digit.<<

Kevin
________________________________

	From: Steve Cipolli [mailto:SCipolli@radvision.com] 
	Sent: Friday, December 05, 2003 1:09 PM
	To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Troy Cauble'
	Cc: megaco@ietf.org
	Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
Timers ( L), & Short T imers (S)
	
	
	While I tend to agree with most of the answers below, I don't see
any of this specified in the specification.  If we can agree that the
answers below are the correct interpretation, then we still need
clarification in the spec or implementors guide.  I'm still hoping the
original author of this section of the spec will clarify the original
intention.
	 
	--Stephen

		-----Original Message-----
		From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
		Sent: Tuesday, December 02, 2003 3:18 PM
		To: Steve Cipolli; 'Troy Cauble'
		Cc: megaco@ietf.org
		Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S)
		
		

		Comments inline. [KJBII] 

		Kevin 

		-----Original Message----- 
		From: Steve Cipolli [mailto:SCipolli@radvision.com] 
		Sent: Tuesday, December 02, 2003 2:40 PM 
		To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH] 
		Cc: megaco@ietf.org 
		Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 

		Perhaps I moved us off track a bit.  It is clear that there
is more than one interpretation of the specification with regard to L, S,
and to a lesser extent Z.  Can the authors comment on what the intent of the
specification was and then perhaps we can reach some conclusion?

		Here is a partial list of odd digitmaps that seem to defy
interpretation: 
		        "123Z"                          - "Z" ignored or
error? 
		[KJBII] Z here has nothing to modify.  Error. 

		        "123S"                  - "S" (or "L") ignored or
error? 
		[KJBII] In this instance, the digitmap switches to short
interdigit timing after detecting "123".  So, neither. 

		        "1ZZ23"                 - First "Z" ignored or
error? 
		[KJBII] Because Z is defined as modifying the following
digit, and Z cannot modify Z, this should be an error. 

		        "1ZSSSSSSSSS23"         - "Z" applied to the "2" or
ignored or error? 
		[KJBII] See above.  Error as Z cannot modify S (or L). 

		        "135[2Z46]"                     - "Z" applied to "4"
or to all in the range (246) or ignored or error? 
		[KJBII] Z applies solely to the 4 here. 

		        "135[246Z]79"           - "Z" applied to "7" or
ignored or error? 
		[KJBII] Nothing for Z to modify.  Error. 

		        "135[2S46]"                     - "S" (or "L")
applied to all in range (246) or ignored or error? 
		[KJBII] This is the root of our earlier discussion.  L and S
do not modify digits -- they modify timing strategy for the digitmap at the
time they are encountered.  [246] means "match 2, 4 or 6".  So [2S46]
means... What exactly? "Match 2, short timeout, 4 or 6"?  Or "match 2, 4 or
6 while running the short timer for this digit only"?  Or "run the short
timer S after detecting 2, but not if 4 or 6 is detected"?  If the string
were "135S[246]" then we would start using the short timer before looking
for 2, 4 or 6.  If it were "135[246]S", we would start using the short timer
AFTER matching 2, 4 or 6.  But, with the S timer INSIDE the range, that
would indicate that the timer would have to fire to continue.  For instance,
if the string were "135[2S46]79", that would seem to indicate that if NO
digit was detected for the duration of the short timer, then we should
continue with the string to find 7.  This is a contrary usage to S and L at
any other point in a digitmap.  I think S and L should be ignored within
ranges.  If the MGC wants to use the S or L timer, then put them outside the
range.

		        "135[2L4S6]"            - "L" or "S" applied or both
(somehow?) or ignored or error? 
		[KJBII] See above -- the same arguments apply here.  I would
note that L would never get "detected" here, since S would match first.

		Thanks, 
		--Stephen 

		        

		> -----Original Message----- 
		> From: Steve Cipolli [mailto:SCipolli@radvision.com] 
		> Sent: Monday, December 01, 2003 8:01 PM 
		> To: 'Troy Cauble'; Kevin Boyle 
		> Cc: megaco@ietf.org 
		> Subject: RE: [Megaco] Digit Maps: Long Duration
Modifier(Z), Long 
		> Timers ( L), & Short T imers (S) 
		> 
		> 
		> Part of the problem is the term "alternatives" is not
clear.  
		> The text in 
		> 7.1.14.3 says of "alternatives": 
		> A DigitMap, according to this syntax, is defined either by
a string or 
		> by a list of strings.  Each string in the list is an
alternative event 
		> sequence, specified either as a sequence of digit map
symbols or as a 
		> regular expression of digit map symbols. 
		> 
		> My reading of this is that "alternatives" are each string
and not the 
		> possible sequences through a range, but admittedly this is
not clear. 
		> 
		> The section doesn't seem to explain other odd sequences
like "123Z". 
		> Presumably the "Z" is simply ignored although an error
could also be 
		> considered the proper outcome. 
		> 
		> I must say I prefer an interpretation in which the number
of possible 
		> ways to perform the same action is as close to 1 and
possible. 
		> Therefore, I'd 
		> prefer to ban (or at least ignore) "L" and "S" within
ranges. 
		> 
		> --Stephen 
		> 
		> > -----Original Message----- 
		> > From: Troy Cauble [mailto:troy@bell-labs.com] 
		> > Sent: Monday, December 01, 2003 6:33 PM 
		> > To: Kevin Boyle 
		> > Cc: megaco@ietf.org 
		> > Subject: Re: [Megaco] Digit Maps: Long Duration
Modifier(Z), Long 
		> > Timers ( L), & Short T imers (S) 
		> > 
		> > 
		> > 
		> > 
		> > I disagree that "L" and "S" are meaningless within a
range. 
		> > 
		> > "L" and "S" are used to specify the timer used for
"subsequent 
		> > events". 
		> > 
		> > I would argue that the "5" is a subsequent event in
"[34L]5", just 
		> > as it is in "[34]L5". 
		> > 
		> > I would also argue that the "4" in "[3L4]5" is NOT a
"subsequent 
		> > event", although one might debate the definition of
"subsequent". 
		> > 
		> > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and 
		> "[34]L5" are all 
		> > the same. (And the "L" is not meaningless.) 
		> > 
		> > 
		> > Note that section 7.1.14.3 does bother to specify what
happens when 
		> > explicit timing specifiers are only active in some
"alternatives", 
		> or when they 
		> > differ in among alternatives -- the same timer value is
used for all 
		> > alternatives. 
		> > 
		> > 
		> > 7.1.14.3: 
		> > 
		> >  > In addition to these event symbols, the string may
contain "S" 
		> > and "L" 
		> >  > inter-event timing specifiers and the "Z" duration
modifier. "S" 
		> > and "L" 
		> >  > respectively indicate that the MG should use the
short (S) timer 
		> > or the  > long (L) timer for subsequent events,
overriding the 
		> > timing rules  > described above. If an explicit timing
specifier is 
		> > in effect in one  > alternative event sequence, but none
is given in 
		> > any other candidate  > alternative, the timer value set
by the 
		> > explicit timing specifier must be  > used. If all
sequences with 
		> > explicit timing controls are dropped from the  >
candidate set, 
		> > timing reverts to the default rules given above.
Finally,  > if 
		> > conflicting timing specifiers are in effect in different
alternative  
		> > > sequences, the long timer shall be used. 
		> > 
		> > 
		> > -troy 
		> > 
		> > 
		> > 
		> > Kevin Boyle wrote: 
		> > 
		> > > Since a range means "match one of these", I would
agree 
		> > with the assessment 
		> > > that L and S are meaningless within a range. 
		> > >  
		> > > Kevin 
		> > > 
		> > > 
		> > >   _____ 
		> > > 
		> > > From: Steve Cipolli [mailto:SCipolli@radvision.com] 
		> > > Sent: Monday, December 01, 2003 5:22 PM 
		> > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org 
		> > > Subject: RE: [Megaco] Digit Maps: Long Duration 
		> > Modifier(Z), Long Timers ( 
		> > > L), & Short T imers (S) 
		> > > 
		> > > 
		> > > Thanks for the feedback.  
		> > >  
		> > > Just to make sure I understand the L and S cases: 
		> > > They are syntactically legal in a range specification,
but 
		> > semantically they 
		> > > have no effect.  Correct? 
		> > >  
		> > > --Stephen 
		> > > 
		> > > -----Original Message----- 
		> > > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
		> > > Sent: Monday, December 01, 2003 5:15 PM 
		> > > To: Steve Cipolli; megaco@ietf.org 
		> > > Subject: RE: [Megaco] Digit Maps: Long Duration 
		> > Modifier(Z), Long Timers ( 
		> > > L), & Short T imers (S) 
		> > > 
		> > > 
		> > > Your interpretation is correct.  Because Z changes how
a 
		> > digit is matched, 
		> > > it makes sense within a range.  Think of Z as part of
the 
		> > digit it modifies, 
		> > > rather than a separate symbol. 
		> > >  
		> > > The L and S timers within a digitmap give specific 
		> > instruction as to which 
		> > > timer to run at that point in the digitmap.  While
allowed 
		> > in a range, I 
		> > > don't think they provide much value within a range
since 
		> they do not 
		> > > actually match anything.  For effective use, they
should be 
		> > outside the 
		> > > range. 
		> > >  
		> > > Kevin 
		> > > 
		> > > 
		> > >   _____ 
		> > > 
		> > > From: Steve Cipolli [mailto:SCipolli@radvision.com] 
		> > > Sent: Monday, December 01, 2003 3:26 PM 
		> > > To: megaco@ietf.org 
		> > > Subject: [Megaco] Digit Maps: Long Duration
Modifier(Z), 
		> > Long Timers (L), & 
		> > > Short T imers (S) 
		> > > 
		> > > 
		> > >  
		> > > According to the syntax in RFCs 3015 & 3525 the long 
		> > duration modifier (Z), 
		> > > Long Timers (L), & Short Timers (S) in digit maps can 
		> > appear in a digit 
		> > > range.  For example (where Z is 1000ms): 
		> > >     "135[2Z46]" 
		> > >  
		> > > Is this valid?  If it is valid, does this mean that
the 
		> > fourth digit event 
		> > > must be either 2, 6 (held for any duration) or 4 held
for 1000 ms? 
		> > >  
		> > > How does long timer (L) and short timer (S) in a digit

		> range apply? 
		> > >  
		> > > --Stephen 
		> > >  
		> > >  
		> > > 
		> > > 
		> > > _______________________________________________ 
		> > > 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 exim@www1.ietf.org  Wed Dec 10 19:36:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27876
	for <megaco-archive@odin.ietf.org>; Wed, 10 Dec 2003 19:36:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUEoH-0008MI-Mu
	for megaco-archive@odin.ietf.org; Wed, 10 Dec 2003 19:36:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB0a5X2032118
	for megaco-archive@odin.ietf.org; Wed, 10 Dec 2003 19:36:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUEoH-0008Lw-F8
	for megaco-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 19:36:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27776
	for <megaco-web-archive@ietf.org>; Wed, 10 Dec 2003 19:36:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUEoE-0005zX-00
	for megaco-web-archive@ietf.org; Wed, 10 Dec 2003 19:36:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUEoE-0005zQ-00
	for megaco-web-archive@ietf.org; Wed, 10 Dec 2003 19:36:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUEoF-0008L0-DL; Wed, 10 Dec 2003 19:36:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUEno-0008K1-1u
	for megaco@optimus.ietf.org; Wed, 10 Dec 2003 19:35:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27764
	for <megaco@ietf.org>; Wed, 10 Dec 2003 19:35:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUEnl-0005zA-00
	for megaco@ietf.org; Wed, 10 Dec 2003 19:35:33 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUEnk-0005yd-00
	for megaco@ietf.org; Wed, 10 Dec 2003 19:35:32 -0500
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 hBB0Z0X00174
	for <megaco@ietf.org>; Wed, 10 Dec 2003 19:35:00 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1YF3P>; Wed, 10 Dec 2003 19:35:01 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D21F90A@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Zhao Bo <zbo@huawei.com>, megaco@ietf.org
Subject: RE: [Megaco] A question about the ITU-T H.248 R2 draft
Date: Wed, 10 Dec 2003 19:34:58 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

The tradeoff will always be number of messages versus transmission delay.
If you specify larger digitmaps, then your transmission delay will be
related to the number of digits that have to be detected.  If you collect
digits one at a time in order to minimize delay, then you will have large
numbers of messages.  The MGC will have to pick the appropriate balance for
its implementation.

If you want to collect digits quickly, either use the digit package (dd or
mfd) or use a digitmap with the timer set very short.  Remember that you can
override the timer definition per digitmap.

Kevin 

-----Original Message-----
From: Zhao Bo [mailto:zbo@huawei.com] 
Sent: Thursday, December 04, 2003 9:50 PM
To: megaco@ietf.org
Subject: Re: [Megaco] A question about the ITU-T H.248 R2 draft

Guess I didn't describe my question clearly :-(. Try again:

1. MG depends the digitmap to decide if the called numbers receiving  is
complete (in most practice, I-15 is not availiabe); 2. When numbers match a
digitmap, everything is OK; But in many cases digitmap is not specific
enough (something like x.L),  MG will have to wait for a time out; This
timeout add significant time delay to call setup procedure.

How to solve this problem? 
I think MG can send each received number to MGC, MGC can send it to next hop
immediately. If some switch in the calling path decide called number is
complete, it sends back a Alerting or something, MGC can then clear R2
address event, avoiding MG timeout. 

Actually, I don't like this solution, because MG will have to report many
events to MGC. Can anyone give me a better solution? Or any advice?

Thanks very much!

----- Original Message -----
From: "Zhao Bo" <zbo@huawei.com>
To: <megaco@ietf.org>
Sent: Wednesday, December 03, 2003 5:23 PM
Subject: [Megaco] A question about the ITU-T H.248 R2 draft


> Hello List:
>     When applying the R2 draft(H.248.25, H.248.icasc) to a network like
this:
>                             MGC
>                               /    \
>                             /       \
>     R2 PBX--->MG1----MG2-->PSTN R2 switch
>     
>    We find the MGC can't give MG1 a complete digitmap to collect
destination number from the R2 PBX
> (because the complexity of PSTN, a call may be routes to any regions and
contries),  and there isn't I-15 
> signalling in R2 PBX. So in most case MG1 will report  the r2 address
event due to time out, not digitmap 
> match.  This add a significant time delay to call setup procedure and
cause quite a lot of compliant.
> 
>     Can't we add a extend mechanism to H.248 R2 package, so MGC send multi
R2 address event to MG?
> MG can then report the destionation number part by part, and once
receiving a part, MGC can send them 
> to next hop.     
> 
>     H.248.icasc allows calling number to  be reported part by part, but it
still require MGC have the complete
> knowledge of calling number. It only tells MG the sequence to collect a
know number pattern, in my case, we
> don't know that.
> 
>     Best regards
> Zhao Bo
> 
> *****************************************************************
> This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient(s) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
> *****************************************************************
> 
> _______________________________________________
> 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 exim@www1.ietf.org  Wed Dec 10 19:36:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27879
	for <megaco-archive@odin.ietf.org>; Wed, 10 Dec 2003 19:36:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUEoH-0008MR-Nb
	for megaco-archive@odin.ietf.org; Wed, 10 Dec 2003 19:36:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB0a5bh032132
	for megaco-archive@odin.ietf.org; Wed, 10 Dec 2003 19:36:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUEoH-0008M1-IK
	for megaco-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 19:36:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27774
	for <megaco-web-archive@ietf.org>; Wed, 10 Dec 2003 19:36:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUEoE-0005zU-00
	for megaco-web-archive@ietf.org; Wed, 10 Dec 2003 19:36:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUEoE-0005zP-00
	for megaco-web-archive@ietf.org; Wed, 10 Dec 2003 19:36:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUEoE-0008KV-80; Wed, 10 Dec 2003 19:36:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUEno-0008K2-1w
	for megaco@optimus.ietf.org; Wed, 10 Dec 2003 19:35:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27765
	for <megaco@ietf.org>; Wed, 10 Dec 2003 19:35:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUEnl-0005z7-00
	for megaco@ietf.org; Wed, 10 Dec 2003 19:35:33 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUEnk-0005yc-00
	for megaco@ietf.org; Wed, 10 Dec 2003 19:35:32 -0500
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 hBB0YvX00169
	for <megaco@ietf.org>; Wed, 10 Dec 2003 19:34:57 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1YF3N>; Wed, 10 Dec 2003 19:34:58 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D21F907@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Steve Cipolli <SCipolli@radvision.com>,
        "'Troy Cauble'"
	 <troy@bell-labs.com>
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 L), & Short T imers (S)
Date: Wed, 10 Dec 2003 19:34:56 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

All,

Here is some proposed text for this.  I will include this in the IG.  Please
let me know any changes that would be better.  New text is demarcated by
>><<.

7.1.14.3	DigitMap Syntax
...
In addition to these event symbols, the string may contain "S" and "L"
inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
respectively indicate that the MG should use the short (S) timer or the long
(L) timer for subsequent events, overriding the timing rules described
above. If an explicit timing specifier is in effect in one alternative event
sequence, but none is given in any other candidate alternative, the timer
value set by the explicit timing specifier must be used. If all sequences
with explicit timing controls are dropped from the candidate set, timing
reverts to the default rules given above. >>If used inside a range notation,
the S and L specifiers shall be ignored.<<  Finally, if conflicting timing
specifiers are in effect in different alternative sequences, the long timer
shall be used.

A "Z" designates a long duration event: placed in front of the symbol(s)
designating the event(s) which satisfy a given digit position, it indicates
that that position is satisfied only if the duration of the event exceeds
the long-duration threshold. The value of this threshold is assumed to be
provisioned in the MG.  >>If the Z specifier is not followed by a digit (0-9
or A-K), then the MG shall reject the digitmap as invalid protocol.  When
used in a range notation, the Z specifier applies solely to the immediately
following digit.<<

Kevin
________________________________

	From: Steve Cipolli [mailto:SCipolli@radvision.com] 
	Sent: Friday, December 05, 2003 1:09 PM
	To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Troy Cauble'
	Cc: megaco@ietf.org
	Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
Timers ( L), & Short T imers (S)
	
	
	While I tend to agree with most of the answers below, I don't see
any of this specified in the specification.  If we can agree that the
answers below are the correct interpretation, then we still need
clarification in the spec or implementors guide.  I'm still hoping the
original author of this section of the spec will clarify the original
intention.
	 
	--Stephen

		-----Original Message-----
		From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
		Sent: Tuesday, December 02, 2003 3:18 PM
		To: Steve Cipolli; 'Troy Cauble'
		Cc: megaco@ietf.org
		Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S)
		
		

		Comments inline. [KJBII] 

		Kevin 

		-----Original Message----- 
		From: Steve Cipolli [mailto:SCipolli@radvision.com] 
		Sent: Tuesday, December 02, 2003 2:40 PM 
		To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH] 
		Cc: megaco@ietf.org 
		Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 

		Perhaps I moved us off track a bit.  It is clear that there
is more than one interpretation of the specification with regard to L, S,
and to a lesser extent Z.  Can the authors comment on what the intent of the
specification was and then perhaps we can reach some conclusion?

		Here is a partial list of odd digitmaps that seem to defy
interpretation: 
		        "123Z"                          - "Z" ignored or
error? 
		[KJBII] Z here has nothing to modify.  Error. 

		        "123S"                  - "S" (or "L") ignored or
error? 
		[KJBII] In this instance, the digitmap switches to short
interdigit timing after detecting "123".  So, neither. 

		        "1ZZ23"                 - First "Z" ignored or
error? 
		[KJBII] Because Z is defined as modifying the following
digit, and Z cannot modify Z, this should be an error. 

		        "1ZSSSSSSSSS23"         - "Z" applied to the "2" or
ignored or error? 
		[KJBII] See above.  Error as Z cannot modify S (or L). 

		        "135[2Z46]"                     - "Z" applied to "4"
or to all in the range (246) or ignored or error? 
		[KJBII] Z applies solely to the 4 here. 

		        "135[246Z]79"           - "Z" applied to "7" or
ignored or error? 
		[KJBII] Nothing for Z to modify.  Error. 

		        "135[2S46]"                     - "S" (or "L")
applied to all in range (246) or ignored or error? 
		[KJBII] This is the root of our earlier discussion.  L and S
do not modify digits -- they modify timing strategy for the digitmap at the
time they are encountered.  [246] means "match 2, 4 or 6".  So [2S46]
means... What exactly? "Match 2, short timeout, 4 or 6"?  Or "match 2, 4 or
6 while running the short timer for this digit only"?  Or "run the short
timer S after detecting 2, but not if 4 or 6 is detected"?  If the string
were "135S[246]" then we would start using the short timer before looking
for 2, 4 or 6.  If it were "135[246]S", we would start using the short timer
AFTER matching 2, 4 or 6.  But, with the S timer INSIDE the range, that
would indicate that the timer would have to fire to continue.  For instance,
if the string were "135[2S46]79", that would seem to indicate that if NO
digit was detected for the duration of the short timer, then we should
continue with the string to find 7.  This is a contrary usage to S and L at
any other point in a digitmap.  I think S and L should be ignored within
ranges.  If the MGC wants to use the S or L timer, then put them outside the
range.

		        "135[2L4S6]"            - "L" or "S" applied or both
(somehow?) or ignored or error? 
		[KJBII] See above -- the same arguments apply here.  I would
note that L would never get "detected" here, since S would match first.

		Thanks, 
		--Stephen 

		        

		> -----Original Message----- 
		> From: Steve Cipolli [mailto:SCipolli@radvision.com] 
		> Sent: Monday, December 01, 2003 8:01 PM 
		> To: 'Troy Cauble'; Kevin Boyle 
		> Cc: megaco@ietf.org 
		> Subject: RE: [Megaco] Digit Maps: Long Duration
Modifier(Z), Long 
		> Timers ( L), & Short T imers (S) 
		> 
		> 
		> Part of the problem is the term "alternatives" is not
clear.  
		> The text in 
		> 7.1.14.3 says of "alternatives": 
		> A DigitMap, according to this syntax, is defined either by
a string or 
		> by a list of strings.  Each string in the list is an
alternative event 
		> sequence, specified either as a sequence of digit map
symbols or as a 
		> regular expression of digit map symbols. 
		> 
		> My reading of this is that "alternatives" are each string
and not the 
		> possible sequences through a range, but admittedly this is
not clear. 
		> 
		> The section doesn't seem to explain other odd sequences
like "123Z". 
		> Presumably the "Z" is simply ignored although an error
could also be 
		> considered the proper outcome. 
		> 
		> I must say I prefer an interpretation in which the number
of possible 
		> ways to perform the same action is as close to 1 and
possible. 
		> Therefore, I'd 
		> prefer to ban (or at least ignore) "L" and "S" within
ranges. 
		> 
		> --Stephen 
		> 
		> > -----Original Message----- 
		> > From: Troy Cauble [mailto:troy@bell-labs.com] 
		> > Sent: Monday, December 01, 2003 6:33 PM 
		> > To: Kevin Boyle 
		> > Cc: megaco@ietf.org 
		> > Subject: Re: [Megaco] Digit Maps: Long Duration
Modifier(Z), Long 
		> > Timers ( L), & Short T imers (S) 
		> > 
		> > 
		> > 
		> > 
		> > I disagree that "L" and "S" are meaningless within a
range. 
		> > 
		> > "L" and "S" are used to specify the timer used for
"subsequent 
		> > events". 
		> > 
		> > I would argue that the "5" is a subsequent event in
"[34L]5", just 
		> > as it is in "[34]L5". 
		> > 
		> > I would also argue that the "4" in "[3L4]5" is NOT a
"subsequent 
		> > event", although one might debate the definition of
"subsequent". 
		> > 
		> > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and 
		> "[34]L5" are all 
		> > the same. (And the "L" is not meaningless.) 
		> > 
		> > 
		> > Note that section 7.1.14.3 does bother to specify what
happens when 
		> > explicit timing specifiers are only active in some
"alternatives", 
		> or when they 
		> > differ in among alternatives -- the same timer value is
used for all 
		> > alternatives. 
		> > 
		> > 
		> > 7.1.14.3: 
		> > 
		> >  > In addition to these event symbols, the string may
contain "S" 
		> > and "L" 
		> >  > inter-event timing specifiers and the "Z" duration
modifier. "S" 
		> > and "L" 
		> >  > respectively indicate that the MG should use the
short (S) timer 
		> > or the  > long (L) timer for subsequent events,
overriding the 
		> > timing rules  > described above. If an explicit timing
specifier is 
		> > in effect in one  > alternative event sequence, but none
is given in 
		> > any other candidate  > alternative, the timer value set
by the 
		> > explicit timing specifier must be  > used. If all
sequences with 
		> > explicit timing controls are dropped from the  >
candidate set, 
		> > timing reverts to the default rules given above.
Finally,  > if 
		> > conflicting timing specifiers are in effect in different
alternative  
		> > > sequences, the long timer shall be used. 
		> > 
		> > 
		> > -troy 
		> > 
		> > 
		> > 
		> > Kevin Boyle wrote: 
		> > 
		> > > Since a range means "match one of these", I would
agree 
		> > with the assessment 
		> > > that L and S are meaningless within a range. 
		> > >  
		> > > Kevin 
		> > > 
		> > > 
		> > >   _____ 
		> > > 
		> > > From: Steve Cipolli [mailto:SCipolli@radvision.com] 
		> > > Sent: Monday, December 01, 2003 5:22 PM 
		> > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org 
		> > > Subject: RE: [Megaco] Digit Maps: Long Duration 
		> > Modifier(Z), Long Timers ( 
		> > > L), & Short T imers (S) 
		> > > 
		> > > 
		> > > Thanks for the feedback.  
		> > >  
		> > > Just to make sure I understand the L and S cases: 
		> > > They are syntactically legal in a range specification,
but 
		> > semantically they 
		> > > have no effect.  Correct? 
		> > >  
		> > > --Stephen 
		> > > 
		> > > -----Original Message----- 
		> > > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
		> > > Sent: Monday, December 01, 2003 5:15 PM 
		> > > To: Steve Cipolli; megaco@ietf.org 
		> > > Subject: RE: [Megaco] Digit Maps: Long Duration 
		> > Modifier(Z), Long Timers ( 
		> > > L), & Short T imers (S) 
		> > > 
		> > > 
		> > > Your interpretation is correct.  Because Z changes how
a 
		> > digit is matched, 
		> > > it makes sense within a range.  Think of Z as part of
the 
		> > digit it modifies, 
		> > > rather than a separate symbol. 
		> > >  
		> > > The L and S timers within a digitmap give specific 
		> > instruction as to which 
		> > > timer to run at that point in the digitmap.  While
allowed 
		> > in a range, I 
		> > > don't think they provide much value within a range
since 
		> they do not 
		> > > actually match anything.  For effective use, they
should be 
		> > outside the 
		> > > range. 
		> > >  
		> > > Kevin 
		> > > 
		> > > 
		> > >   _____ 
		> > > 
		> > > From: Steve Cipolli [mailto:SCipolli@radvision.com] 
		> > > Sent: Monday, December 01, 2003 3:26 PM 
		> > > To: megaco@ietf.org 
		> > > Subject: [Megaco] Digit Maps: Long Duration
Modifier(Z), 
		> > Long Timers (L), & 
		> > > Short T imers (S) 
		> > > 
		> > > 
		> > >  
		> > > According to the syntax in RFCs 3015 & 3525 the long 
		> > duration modifier (Z), 
		> > > Long Timers (L), & Short Timers (S) in digit maps can 
		> > appear in a digit 
		> > > range.  For example (where Z is 1000ms): 
		> > >     "135[2Z46]" 
		> > >  
		> > > Is this valid?  If it is valid, does this mean that
the 
		> > fourth digit event 
		> > > must be either 2, 6 (held for any duration) or 4 held
for 1000 ms? 
		> > >  
		> > > How does long timer (L) and short timer (S) in a digit

		> range apply? 
		> > >  
		> > > --Stephen 
		> > >  
		> > >  
		> > > 
		> > > 
		> > > _______________________________________________ 
		> > > 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-admin@ietf.org  Wed Dec 10 20:22:08 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27850
	for <megaco-archive@lists.ietf.org>; Wed, 10 Dec 2003 19:36:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUEoF-0008L0-DL; Wed, 10 Dec 2003 19:36:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUEno-0008K1-1u
	for megaco@optimus.ietf.org; Wed, 10 Dec 2003 19:35:36 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27764
	for <megaco@ietf.org>; Wed, 10 Dec 2003 19:35:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUEnl-0005zA-00
	for megaco@ietf.org; Wed, 10 Dec 2003 19:35:33 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUEnk-0005yd-00
	for megaco@ietf.org; Wed, 10 Dec 2003 19:35:32 -0500
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 hBB0Z0X00174
	for <megaco@ietf.org>; Wed, 10 Dec 2003 19:35:00 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1YF3P>; Wed, 10 Dec 2003 19:35:01 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D21F90A@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Zhao Bo <zbo@huawei.com>, megaco@ietf.org
Subject: RE: [Megaco] A question about the ITU-T H.248 R2 draft
Date: Wed, 10 Dec 2003 19:34:58 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

The tradeoff will always be number of messages versus transmission delay.
If you specify larger digitmaps, then your transmission delay will be
related to the number of digits that have to be detected.  If you collect
digits one at a time in order to minimize delay, then you will have large
numbers of messages.  The MGC will have to pick the appropriate balance for
its implementation.

If you want to collect digits quickly, either use the digit package (dd or
mfd) or use a digitmap with the timer set very short.  Remember that you can
override the timer definition per digitmap.

Kevin 

-----Original Message-----
From: Zhao Bo [mailto:zbo@huawei.com] 
Sent: Thursday, December 04, 2003 9:50 PM
To: megaco@ietf.org
Subject: Re: [Megaco] A question about the ITU-T H.248 R2 draft

Guess I didn't describe my question clearly :-(. Try again:

1. MG depends the digitmap to decide if the called numbers receiving  is
complete (in most practice, I-15 is not availiabe); 2. When numbers match a
digitmap, everything is OK; But in many cases digitmap is not specific
enough (something like x.L),  MG will have to wait for a time out; This
timeout add significant time delay to call setup procedure.

How to solve this problem? 
I think MG can send each received number to MGC, MGC can send it to next hop
immediately. If some switch in the calling path decide called number is
complete, it sends back a Alerting or something, MGC can then clear R2
address event, avoiding MG timeout. 

Actually, I don't like this solution, because MG will have to report many
events to MGC. Can anyone give me a better solution? Or any advice?

Thanks very much!

----- Original Message -----
From: "Zhao Bo" <zbo@huawei.com>
To: <megaco@ietf.org>
Sent: Wednesday, December 03, 2003 5:23 PM
Subject: [Megaco] A question about the ITU-T H.248 R2 draft


> Hello List:
>     When applying the R2 draft(H.248.25, H.248.icasc) to a network like
this:
>                             MGC
>                               /    \
>                             /       \
>     R2 PBX--->MG1----MG2-->PSTN R2 switch
>     
>    We find the MGC can't give MG1 a complete digitmap to collect
destination number from the R2 PBX
> (because the complexity of PSTN, a call may be routes to any regions and
contries),  and there isn't I-15 
> signalling in R2 PBX. So in most case MG1 will report  the r2 address
event due to time out, not digitmap 
> match.  This add a significant time delay to call setup procedure and
cause quite a lot of compliant.
> 
>     Can't we add a extend mechanism to H.248 R2 package, so MGC send multi
R2 address event to MG?
> MG can then report the destionation number part by part, and once
receiving a part, MGC can send them 
> to next hop.     
> 
>     H.248.icasc allows calling number to  be reported part by part, but it
still require MGC have the complete
> knowledge of calling number. It only tells MG the sequence to collect a
know number pattern, in my case, we
> don't know that.
> 
>     Best regards
> Zhao Bo
> 
> *****************************************************************
> This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient(s) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
> *****************************************************************
> 
> _______________________________________________
> 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-admin@ietf.org  Wed Dec 10 22:14:29 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02375
	for <megaco-archive@lists.ietf.org>; Wed, 10 Dec 2003 22:14:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUHH7-0005ey-UT; Wed, 10 Dec 2003 22:14:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUHGB-0005dJ-Ab
	for megaco@optimus.ietf.org; Wed, 10 Dec 2003 22:13:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02347
	for <Megaco@ietf.org>; Wed, 10 Dec 2003 22:12:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUHG7-00012K-00
	for Megaco@ietf.org; Wed, 10 Dec 2003 22:12:59 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUHG6-000122-00
	for Megaco@ietf.org; Wed, 10 Dec 2003 22:12:58 -0500
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 hBB3CTX10358
	for <Megaco@ietf.org>; Wed, 10 Dec 2003 22:12:29 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1YGB7>; Wed, 10 Dec 2003 22:12:29 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D21F99C@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Pascal Lambers <pascal.lambers@pandora.be>, Megaco@ietf.org
Subject: RE: [Megaco] SDP mode and Megaco mode question
Date: Wed, 10 Dec 2003 22:12:28 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

The "optional" parts of SDP are only from the MGC->MG.  MGs MUST return
compliant SDP.  Therefore, anything sent from the MGC to the SIP client will
be compliant SDP.
 
As for your other example, it seems to me that is an implementation detail,
and that MGCs are not obligated to parse SDP.  Should they do so to be
effective implementations?  Well, that is another question altogether.
 
Kevin


  _____  

From: Pascal Lambers [mailto:pascal.lambers@pandora.be] 
Sent: Wednesday, December 10, 2003 6:02 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question


I do think it's unavoidable for a MGC to parse the SDP...
 
For example, you can have MGC1 (controlling a Megaco GW + a black phone)
talking to MGC2 (controlling a Sip GW + Sip Phone). Now, If the Sip phone
starts doing some more complex operations it might want the Megaco side,
controlled by MGC1, to change Mode. And that's exactly where the MGC2 has to
parse the SDP block to make sure that it can send a LocalControlDescriptor
to its Megaco gateway. Because the a=... parameter in the SDP block from the
sip-side will be of no use to the Megaco GW.
 
Moreover, the SDP parameters o,s and t, optional according to the Megaco RFC
but mandatory according to the SDP RFC, cause the same problem...
 
Pascal
 
 

----- Original Message ----- 
From: Kevin Boyle <mailto:kboyle@nortelnetworks.com>  
To: Pascal Lambers <mailto:pascal.lambers@pandora.be>  ; Megaco@ietf.org
<mailto:Megaco@ietf.org>  
Sent: Wednesday, December 10, 2003 12:11 AM
Subject: RE: [Megaco] SDP mode and Megaco mode question


I don't see that the MGC has to parse SDP.  I think the mode in the SDP
could be used as a suggestion, but the MGC will certainly know whether or
not it wants the media stream flowing.  That is to say, what the MGC wants
trumps what the far-end wants.

Kevin 

-----Original Message----- 
From: Pascal Lambers [mailto:pascal.lambers@pandora.be
<mailto:pascal.lambers@pandora.be> ] 
Sent: Monday, December 08, 2003 5:39 PM 
To: Megaco@ietf.org <mailto:Megaco@ietf.org>  
Subject: Re: [Megaco] SDP mode and Megaco mode question 

It would of course be interesting to know what most gateways currently do
with the "a=..." SDP mode parameter: will they deny it, even if no other
mode has been set? Are there some gateway experts reading this discussion?

I do see Christian's point here: the context prevails. You could look at the
context as as a shell around the RTP(s) it contains.

The annoying consequence is that a MGC which must talk to a Megaco MG has to
start parsing the SDP block. If  a MGC receives a message for its MG from,
say, another MGC, it has to translate the SDP mode to a local control
mode...

Kind regards, 
Pascal 


----- Original Message ----- 
From: "Christian Groves" <Christian.Groves@ericsson.com> 
To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com> 
Cc: "Pascal Lambers" <pascal.lambers@pandora.be>; "Tom Taylor" 
<taylor@nortelnetworks.com>; <Megaco@ietf.org> 
Sent: Monday, December 08, 2003 10:45 PM 
Subject: Re: [Megaco] SDP mode and Megaco mode question 


> Hello Madhubabu, 
> 
> The text I proposed below was: 
> "The local control mode property takes precedence over the local and 
remote 
> descriptors." 
> 
> The local control mode property will always be set as it defaults to 
"inactive". 
> So as the local control mode property is set it always takes precedence. 
> 
> Christian 
> 
> Madhubabu Brahmanapally wrote: 
> 
> > Hi Christian, 
> > Does the Local control mode property takes precedence or as Tom pointed 
> > out, does the MG always disregard the mode in local/remote descriptors??

> > 
> > Regards 
> > Madhubabu 
> > 
> > -----Original Message----- 
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com
<mailto:Christian.Groves@ericsson.com> ] 
> > Sent: Sunday, December 07, 2003 8:56 PM 
> > To: Pascal Lambers 
> > Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org 
> > Subject: Re: [Megaco] SDP mode and Megaco mode question 
> > 
> > 
> > Hello Pascal, 
> > 
> > I think you have pointed out an issue for the Implementors' Guide. This 
> > fact 
> > that the Local Control Mode overrides the SDP is common practise the 
only 
> > problem is that it is not clearly stated. 
> > 
> > I would propose that : 
> > 7.1.7   LocalControl descriptor 
> > ... 
> > The allowed values for the mode property are send-only, receive-only, 
> > send/receive, inactive and loop-back. "Send" and "receive" are with 
> > respect to 
> > the exterior of the Context, so that, for example, a stream set to mode 
= 
> > sendOnly does not pass received media into the Context. The default 
> > value for 
> > the mode property is "Inactive". Signals and Events are not affected by 
> > mode. 
> >  >>> The local control mode property takes precedence over the local and

> > remote 
> > descriptors.<<< 
> > ... 
> > 
> > Regards, Christian 
> > 
> > Pascal Lambers wrote: 
> > 
> >  > So would I, but isn't there any RFC statement to enforce this 
opinion? 
> >  > 
> >  > Pascal 
> >  > 
> >  > 
> >  > ----- Original Message ----- 
> >  > From: "Tom Taylor" <taylor@nortelnetworks.com> 
> >  > To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com> 
> >  > Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>

> >  > Sent: Friday, December 05, 2003 12:31 AM 
> >  > Subject: Re: [Megaco] SDP mode and Megaco mode question 
> >  > 
> >  > 
> >  > 
> >  >>I would put it bluntly that the MG must ignore mode in the SDP. 
> >  >> 
> >  >>Madhubabu Brahmanapally wrote: 
> >  >> 
> >  >> 
> >  >>>The Local Control Descriptor has high precedence over the SDP 
> >  >>>information.... 
> >  >>> 
> >  >>>    -----Original Message----- 
> >  >>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be
<mailto:pascal.lambers@pandora.be> ] 
> >  >>>    *Sent:* Thursday, December 04, 2003 3:05 PM 
> >  >>>    *To:* Megaco@ietf.org 
> >  >>>    *Subject:* [Megaco] SDP mode and Megaco mode question 
> >  >>> 
> >  >>>    Hello, 
> >  >>> 
> >  >>>    Don't know precisely how to forumulate this question clearly, so

> > let 
> >  >>>    me put in in two different ways... 
> >  >>> 
> >  >>>    What does a MG have to do if an MGC sends a Modify with: 
> >  >>>    - the Mode property of the LocalControl descriptor set to, for 
> >  >>>    instance, receive-only; 
> >  >>>    - a Local/Remote Descriptor with an SDP-block containing an 
> >  >>>    "a=sendrecv" parameter? 
> >  >>> 
> >  >>>    In other words, what is the relation beween the a=sendrecv, 
> >  >>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP 
protocol 
> >  >>>    and the Mode property of the LocalControl descriptor in the 
Megaco 
> >  >>>    protocol? 
> >  >>> 
> >  >>> 
> >  >>>    Can sb give some advise? Thanks! 
> >  >>>    Pascal 
> >  >>> 
> >  >>> 
> >  >> 
> >  >> 
> >  >>_______________________________________________ 
> >  >>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
<https://www1.ietf.org/mailman/listinfo/megaco>  
> >  > 
> > 
> 
> 
> 
> 



_______________________________________________ 
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 exim@www1.ietf.org  Wed Dec 10 22:14:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02393
	for <megaco-archive@odin.ietf.org>; Wed, 10 Dec 2003 22:14:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUHHA-0005fl-Up
	for megaco-archive@odin.ietf.org; Wed, 10 Dec 2003 22:14:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB3E42x021801
	for megaco-archive@odin.ietf.org; Wed, 10 Dec 2003 22:14:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUHH9-0005fY-El
	for megaco-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 22:14:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02366
	for <megaco-web-archive@ietf.org>; Wed, 10 Dec 2003 22:13:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUHH5-00013O-00
	for megaco-web-archive@ietf.org; Wed, 10 Dec 2003 22:13:59 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUHH5-00013L-00
	for megaco-web-archive@ietf.org; Wed, 10 Dec 2003 22:13:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUHH7-0005ey-UT; Wed, 10 Dec 2003 22:14:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUHGB-0005dJ-Ab
	for megaco@optimus.ietf.org; Wed, 10 Dec 2003 22:13:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02347
	for <Megaco@ietf.org>; Wed, 10 Dec 2003 22:12:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUHG7-00012K-00
	for Megaco@ietf.org; Wed, 10 Dec 2003 22:12:59 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUHG6-000122-00
	for Megaco@ietf.org; Wed, 10 Dec 2003 22:12:58 -0500
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 hBB3CTX10358
	for <Megaco@ietf.org>; Wed, 10 Dec 2003 22:12:29 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1YGB7>; Wed, 10 Dec 2003 22:12:29 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D21F99C@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Pascal Lambers <pascal.lambers@pandora.be>, Megaco@ietf.org
Subject: RE: [Megaco] SDP mode and Megaco mode question
Date: Wed, 10 Dec 2003 22:12:28 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

The "optional" parts of SDP are only from the MGC->MG.  MGs MUST return
compliant SDP.  Therefore, anything sent from the MGC to the SIP client will
be compliant SDP.
 
As for your other example, it seems to me that is an implementation detail,
and that MGCs are not obligated to parse SDP.  Should they do so to be
effective implementations?  Well, that is another question altogether.
 
Kevin


  _____  

From: Pascal Lambers [mailto:pascal.lambers@pandora.be] 
Sent: Wednesday, December 10, 2003 6:02 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Megaco@ietf.org
Subject: Re: [Megaco] SDP mode and Megaco mode question


I do think it's unavoidable for a MGC to parse the SDP...
 
For example, you can have MGC1 (controlling a Megaco GW + a black phone)
talking to MGC2 (controlling a Sip GW + Sip Phone). Now, If the Sip phone
starts doing some more complex operations it might want the Megaco side,
controlled by MGC1, to change Mode. And that's exactly where the MGC2 has to
parse the SDP block to make sure that it can send a LocalControlDescriptor
to its Megaco gateway. Because the a=... parameter in the SDP block from the
sip-side will be of no use to the Megaco GW.
 
Moreover, the SDP parameters o,s and t, optional according to the Megaco RFC
but mandatory according to the SDP RFC, cause the same problem...
 
Pascal
 
 

----- Original Message ----- 
From: Kevin Boyle <mailto:kboyle@nortelnetworks.com>  
To: Pascal Lambers <mailto:pascal.lambers@pandora.be>  ; Megaco@ietf.org
<mailto:Megaco@ietf.org>  
Sent: Wednesday, December 10, 2003 12:11 AM
Subject: RE: [Megaco] SDP mode and Megaco mode question


I don't see that the MGC has to parse SDP.  I think the mode in the SDP
could be used as a suggestion, but the MGC will certainly know whether or
not it wants the media stream flowing.  That is to say, what the MGC wants
trumps what the far-end wants.

Kevin 

-----Original Message----- 
From: Pascal Lambers [mailto:pascal.lambers@pandora.be
<mailto:pascal.lambers@pandora.be> ] 
Sent: Monday, December 08, 2003 5:39 PM 
To: Megaco@ietf.org <mailto:Megaco@ietf.org>  
Subject: Re: [Megaco] SDP mode and Megaco mode question 

It would of course be interesting to know what most gateways currently do
with the "a=..." SDP mode parameter: will they deny it, even if no other
mode has been set? Are there some gateway experts reading this discussion?

I do see Christian's point here: the context prevails. You could look at the
context as as a shell around the RTP(s) it contains.

The annoying consequence is that a MGC which must talk to a Megaco MG has to
start parsing the SDP block. If  a MGC receives a message for its MG from,
say, another MGC, it has to translate the SDP mode to a local control
mode...

Kind regards, 
Pascal 


----- Original Message ----- 
From: "Christian Groves" <Christian.Groves@ericsson.com> 
To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com> 
Cc: "Pascal Lambers" <pascal.lambers@pandora.be>; "Tom Taylor" 
<taylor@nortelnetworks.com>; <Megaco@ietf.org> 
Sent: Monday, December 08, 2003 10:45 PM 
Subject: Re: [Megaco] SDP mode and Megaco mode question 


> Hello Madhubabu, 
> 
> The text I proposed below was: 
> "The local control mode property takes precedence over the local and 
remote 
> descriptors." 
> 
> The local control mode property will always be set as it defaults to 
"inactive". 
> So as the local control mode property is set it always takes precedence. 
> 
> Christian 
> 
> Madhubabu Brahmanapally wrote: 
> 
> > Hi Christian, 
> > Does the Local control mode property takes precedence or as Tom pointed 
> > out, does the MG always disregard the mode in local/remote descriptors??

> > 
> > Regards 
> > Madhubabu 
> > 
> > -----Original Message----- 
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com
<mailto:Christian.Groves@ericsson.com> ] 
> > Sent: Sunday, December 07, 2003 8:56 PM 
> > To: Pascal Lambers 
> > Cc: Tom Taylor; Madhubabu Brahmanapally; Megaco@ietf.org 
> > Subject: Re: [Megaco] SDP mode and Megaco mode question 
> > 
> > 
> > Hello Pascal, 
> > 
> > I think you have pointed out an issue for the Implementors' Guide. This 
> > fact 
> > that the Local Control Mode overrides the SDP is common practise the 
only 
> > problem is that it is not clearly stated. 
> > 
> > I would propose that : 
> > 7.1.7   LocalControl descriptor 
> > ... 
> > The allowed values for the mode property are send-only, receive-only, 
> > send/receive, inactive and loop-back. "Send" and "receive" are with 
> > respect to 
> > the exterior of the Context, so that, for example, a stream set to mode 
= 
> > sendOnly does not pass received media into the Context. The default 
> > value for 
> > the mode property is "Inactive". Signals and Events are not affected by 
> > mode. 
> >  >>> The local control mode property takes precedence over the local and

> > remote 
> > descriptors.<<< 
> > ... 
> > 
> > Regards, Christian 
> > 
> > Pascal Lambers wrote: 
> > 
> >  > So would I, but isn't there any RFC statement to enforce this 
opinion? 
> >  > 
> >  > Pascal 
> >  > 
> >  > 
> >  > ----- Original Message ----- 
> >  > From: "Tom Taylor" <taylor@nortelnetworks.com> 
> >  > To: "Madhubabu Brahmanapally" <Madhubabu@veraznet.com> 
> >  > Cc: "'Pascal Lambers'" <pascal.lambers@pandora.be>; <Megaco@ietf.org>

> >  > Sent: Friday, December 05, 2003 12:31 AM 
> >  > Subject: Re: [Megaco] SDP mode and Megaco mode question 
> >  > 
> >  > 
> >  > 
> >  >>I would put it bluntly that the MG must ignore mode in the SDP. 
> >  >> 
> >  >>Madhubabu Brahmanapally wrote: 
> >  >> 
> >  >> 
> >  >>>The Local Control Descriptor has high precedence over the SDP 
> >  >>>information.... 
> >  >>> 
> >  >>>    -----Original Message----- 
> >  >>>    *From:* Pascal Lambers [mailto:pascal.lambers@pandora.be
<mailto:pascal.lambers@pandora.be> ] 
> >  >>>    *Sent:* Thursday, December 04, 2003 3:05 PM 
> >  >>>    *To:* Megaco@ietf.org 
> >  >>>    *Subject:* [Megaco] SDP mode and Megaco mode question 
> >  >>> 
> >  >>>    Hello, 
> >  >>> 
> >  >>>    Don't know precisely how to forumulate this question clearly, so

> > let 
> >  >>>    me put in in two different ways... 
> >  >>> 
> >  >>>    What does a MG have to do if an MGC sends a Modify with: 
> >  >>>    - the Mode property of the LocalControl descriptor set to, for 
> >  >>>    instance, receive-only; 
> >  >>>    - a Local/Remote Descriptor with an SDP-block containing an 
> >  >>>    "a=sendrecv" parameter? 
> >  >>> 
> >  >>>    In other words, what is the relation beween the a=sendrecv, 
> >  >>>    a=sendonly, a=inactive, a=recvonly parameters of the SDP 
protocol 
> >  >>>    and the Mode property of the LocalControl descriptor in the 
Megaco 
> >  >>>    protocol? 
> >  >>> 
> >  >>> 
> >  >>>    Can sb give some advise? Thanks! 
> >  >>>    Pascal 
> >  >>> 
> >  >>> 
> >  >> 
> >  >> 
> >  >>_______________________________________________ 
> >  >>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
<https://www1.ietf.org/mailman/listinfo/megaco>  
> >  > 
> > 
> 
> 
> 
> 



_______________________________________________ 
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-admin@ietf.org  Thu Dec 11 09:02:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01006
	for <megaco-archive@lists.ietf.org>; Thu, 11 Dec 2003 09:02:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUROD-00058v-L5; Thu, 11 Dec 2003 09:02:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUMm1-0002O4-HS
	for megaco@optimus.ietf.org; Thu, 11 Dec 2003 04:06:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22879
	for <megaco@ietf.org>; Thu, 11 Dec 2003 04:06:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUMly-0006Ih-00
	for megaco@ietf.org; Thu, 11 Dec 2003 04:06:14 -0500
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUMlx-0006Ie-00
	for megaco@ietf.org; Thu, 11 Dec 2003 04:06:13 -0500
Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 11 Dec 2003 10:06:07 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3BFC6.00E63A30"
Subject: RE : [Megaco] Service Change and Testing
Date: Thu, 11 Dec 2003 10:06:03 +0100
Message-ID: <869954804BD53B41AF69F225F15FC331AA9534@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: [Megaco] Service Change and Testing
Thread-Index: AcOIQ5WYUupgZzNnSNG7h4pm3GwFng3frB9Q
From: "CHATRAS Bruno FTRD/DAC/ISS" <bruno.chatras@francetelecom.com>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>, <megaco@ietf.org>
X-OriginalArrivalTime: 11 Dec 2003 09:06:07.0140 (UTC) FILETIME=[03020640:01C3BFC6]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3BFC6.00E63A30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
=20
As we are getting close to the next Q3 meeting, I'd like to come kack on =
this discussion about Sevrice Change and Testing.
=20
Actually, there seems to be two issues :
=20
1) Need to modify the description of the Service Change procedure to =
allow the MG to report state transitions when a termination is brought =
in test and when it is returned to service. Whether the state transation =
is triggerred by the MGC (i.e. using a modify command) or by the MG =
(i.e. test activated via a local management interface) is irrelevant to =
this issue. As this modification does not require any new method, I =
believe that it could be included in the IG as a clarification to H.248 =
V2. A new service change reason might need to be registered (e.g. 918 =
"Term in Test").
=20
2) Need to remove the ability to change the Service State in two =
different competing ways. Beyond making the Service State read-only, =
this indeed requires a new Method and might be differred to V3, =
although, I think that there is value in removing competing options as =
soon as possible.
=20
Bruno
=20
=20
=20

-----Message d'origine-----
De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]=20
Envoy=E9 : mercredi 1 octobre 2003 19:44
=C0 : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
Objet : RE: [Megaco] Service Change and Testing


I have noticed this same discrepancy.  The problem is that the MGC is =
allowed to set the ServiceStates parm utilizing a Modify command, while =
the MG has no such capability (it must utilize ServiceChange).  =
Therefore, there is no way for the MG to set the term into the Test =
state.
=20
In the Annex F work at the most recent Q3 meeting, I raised the idea of =
restricting the SI parm to being Read-only, and mandating that state =
changes must utilize ServiceChange (in both directions).  This would =
also require a new Method to set the term to Test.  The big problem is =
that this is a change from the current function, and may have to wait =
until V3 due to the parsing change with the Method parm (unless there is =
wide acceptance to push this into earlier versions...)
=20
This simplifies the termination state model by removing the ability to =
change the parm in two different, competing ways.  It also provides the =
MG the capability of setting the term into Test (which I think has value =
and utility).
=20
Comments?
=20
Kevin

-----Original Message-----
From: CHATRAS Bruno FTRD/DAC/ISS =
[mailto:bruno.chatras@francetelecom.com]=20
Sent: Wednesday, October 01, 2003 1:06 PM
To: megaco@ietf.org
Subject: [Megaco] Service Change and Testing


Hi,
=20
H.248 defines three values for the Termination State descriptor ("in =
service", "out of service" and "test"). The ServiceChange procedures =
allows the MG to notify the MGC when a termination is about to be taken =
out of service (or is being returned to service). It seems that there is =
not equivalent procedure when a termination is about to be tested (i.e. =
termination state =3D test) and is therefore not available for normal =
traffic. Is there a specific reason for treating these two states =
differently or is just that the wording "out of service" in the =
ServiceChange description encompasses both the "test" and "out of =
service" termination states. If this is the case, I think a =
clarification in the IG guide might be useful.
=20
Regards,
BC


------_=_NextPart_001_01C3BFC6.00E63A30
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4728.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Hello,</FONT></SPAN></DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =
size=3D2>As we=20
are getting close to the next Q3 meeting, I'd like to come kack on this=20
discussion about Sevrice Change and Testing.</FONT></SPAN></DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Actually, there seems to be two issues :</FONT></SPAN></DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =
size=3D2>1)=20
Need to modify the description of the Service Change procedure to allow =
the MG=20
to report state transitions when a termination is brought in test and =
when it is=20
returned to service. Whether the state transation is triggerred by the =
MGC (i.e.=20
using a modify command) or by&nbsp;the MG (i.e. test activated via a =
local=20
management interface) is irrelevant to this issue. As =
t</FONT></SPAN><SPAN=20
class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =
size=3D2>his modification=20
does not require any new method, I believe that it could be included in =
the IG=20
as&nbsp;a clarification to H.248 V2.&nbsp;A new service change reason =
might need=20
to be registered (e.g. 918 "Term in Test").</FONT></SPAN></DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =
size=3D2>2)=20
Need to remove the ability to change the Service State in two different=20
competing ways.&nbsp;Beyond making the Service State read-only, this =
indeed=20
requires a new Method and might be differred to V3, although, I think =
that there=20
is value in removing competing options as soon as =
possible.</FONT></SPAN></DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Bruno</FONT></SPAN></DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Dfr dir=3Dltr =
align=3Dleft><FONT face=3DTahoma=20
  size=3D2>-----Message d'origine-----<BR><B>De&nbsp;:</B> Kevin Boyle=20
  [mailto:kboyle@nortelnetworks.com] <BR><B>Envoy=E9&nbsp;:</B> mercredi =
1 octobre=20
  2003 19:44<BR><B>=C0&nbsp;:</B> CHATRAS Bruno FTRD/DAC/ISS;=20
  megaco@ietf.org<BR><B>Objet&nbsp;:</B> RE: [Megaco] Service Change and =

  Testing<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
  have noticed this same discrepancy.&nbsp; The problem is that the MGC =
is=20
  allowed to set the ServiceStates parm utilizing a Modify command, =
while the MG=20
  has no such capability (it must utilize ServiceChange).&nbsp; =
Therefore, there=20
  is no way for the MG to set the term into the Test =
state.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff size=3D2>In=20
  the Annex F work at the most recent Q3 meeting, I raised the idea of=20
  restricting the SI parm to being Read-only, and mandating that state =
changes=20
  must utilize ServiceChange (in both directions).&nbsp; This would also =
require=20
  a new Method to set the term to Test.&nbsp; The big problem is that =
this is a=20
  change from the current function, and may have to wait until V3 due to =
the=20
  parsing change with the Method parm&nbsp;(unless there is wide =
acceptance to=20
  push this into earlier versions...)</FONT></SPAN></DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff size=3D2>This=20
  simplifies the termination state model by removing the ability to =
change the=20
  parm in two different, competing ways.&nbsp; It also provides the MG =
the=20
  capability of setting the term into Test (which I think has value and=20
  utility).</FONT></SPAN></DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Comments?</FONT></SPAN></DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Kevin</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
CHATRAS Bruno=20
    FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] =
<BR><B>Sent:</B>=20
    Wednesday, October 01, 2003 1:06 PM<BR><B>To:</B>=20
    megaco@ietf.org<BR><B>Subject:</B> [Megaco] Service Change and=20
    Testing<BR><BR></FONT></DIV>
    <DIV><SPAN class=3D944335516-01102003><FONT face=3DArial=20
    size=3D2>Hi,</FONT></SPAN></DIV>
    <DIV><SPAN class=3D944335516-01102003><FONT face=3DArial=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D944335516-01102003><FONT face=3DArial =
size=3D2>H.248 defines=20
    three values for the Termination State descriptor ("in service", =
"out of=20
    service" and "test"). </FONT></SPAN><SPAN =
class=3D944335516-01102003><FONT=20
    face=3DArial size=3D2>The ServiceChange procedures allows the MG to =
notify the=20
    MGC when a termination is about to be taken out of service (or is =
being=20
    returned to service). It seems that there is not equivalent =
procedure when a=20
    termination is about to be tested (i.e. termination state =3D test) =
and is=20
    therefore not available for normal traffic. Is there a specific =
reason for=20
    treating these two states differently or is just that the wording =
"out of=20
    service" in the ServiceChange&nbsp;description encompasses both the =
"test"=20
    and "out of service" termination states. If this is the case, I =
think a=20
    clarification in the IG guide might be useful.</FONT></SPAN></DIV>
    <DIV><SPAN class=3D944335516-01102003><FONT face=3DArial=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D944335516-01102003><FONT face=3DArial=20
    size=3D2>Regards,</FONT></SPAN></DIV>
    <DIV><SPAN class=3D944335516-01102003><FONT face=3DArial=20
    =
size=3D2>BC</FONT></SPAN></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3BFC6.00E63A30--

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


From exim@www1.ietf.org  Thu Dec 11 09:02:32 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01021
	for <megaco-archive@odin.ietf.org>; Thu, 11 Dec 2003 09:02:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUROG-00059u-Ew
	for megaco-archive@odin.ietf.org; Thu, 11 Dec 2003 09:02:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBE24GR019824
	for megaco-archive@odin.ietf.org; Thu, 11 Dec 2003 09:02:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUROG-00059f-A1
	for megaco-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 09:02:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00969
	for <megaco-web-archive@ietf.org>; Thu, 11 Dec 2003 09:02:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUROE-0004GU-00
	for megaco-web-archive@ietf.org; Thu, 11 Dec 2003 09:02:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUROE-0004GR-00
	for megaco-web-archive@ietf.org; Thu, 11 Dec 2003 09:02:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUROD-00058v-L5; Thu, 11 Dec 2003 09:02:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUMm1-0002O4-HS
	for megaco@optimus.ietf.org; Thu, 11 Dec 2003 04:06:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22879
	for <megaco@ietf.org>; Thu, 11 Dec 2003 04:06:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUMly-0006Ih-00
	for megaco@ietf.org; Thu, 11 Dec 2003 04:06:14 -0500
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUMlx-0006Ie-00
	for megaco@ietf.org; Thu, 11 Dec 2003 04:06:13 -0500
Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 11 Dec 2003 10:06:07 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3BFC6.00E63A30"
Subject: RE : [Megaco] Service Change and Testing
Date: Thu, 11 Dec 2003 10:06:03 +0100
Message-ID: <869954804BD53B41AF69F225F15FC331AA9534@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: [Megaco] Service Change and Testing
Thread-Index: AcOIQ5WYUupgZzNnSNG7h4pm3GwFng3frB9Q
From: "CHATRAS Bruno FTRD/DAC/ISS" <bruno.chatras@francetelecom.com>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>, <megaco@ietf.org>
X-OriginalArrivalTime: 11 Dec 2003 09:06:07.0140 (UTC) FILETIME=[03020640:01C3BFC6]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3BFC6.00E63A30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
=20
As we are getting close to the next Q3 meeting, I'd like to come kack on =
this discussion about Sevrice Change and Testing.
=20
Actually, there seems to be two issues :
=20
1) Need to modify the description of the Service Change procedure to =
allow the MG to report state transitions when a termination is brought =
in test and when it is returned to service. Whether the state transation =
is triggerred by the MGC (i.e. using a modify command) or by the MG =
(i.e. test activated via a local management interface) is irrelevant to =
this issue. As this modification does not require any new method, I =
believe that it could be included in the IG as a clarification to H.248 =
V2. A new service change reason might need to be registered (e.g. 918 =
"Term in Test").
=20
2) Need to remove the ability to change the Service State in two =
different competing ways. Beyond making the Service State read-only, =
this indeed requires a new Method and might be differred to V3, =
although, I think that there is value in removing competing options as =
soon as possible.
=20
Bruno
=20
=20
=20

-----Message d'origine-----
De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]=20
Envoy=E9 : mercredi 1 octobre 2003 19:44
=C0 : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
Objet : RE: [Megaco] Service Change and Testing


I have noticed this same discrepancy.  The problem is that the MGC is =
allowed to set the ServiceStates parm utilizing a Modify command, while =
the MG has no such capability (it must utilize ServiceChange).  =
Therefore, there is no way for the MG to set the term into the Test =
state.
=20
In the Annex F work at the most recent Q3 meeting, I raised the idea of =
restricting the SI parm to being Read-only, and mandating that state =
changes must utilize ServiceChange (in both directions).  This would =
also require a new Method to set the term to Test.  The big problem is =
that this is a change from the current function, and may have to wait =
until V3 due to the parsing change with the Method parm (unless there is =
wide acceptance to push this into earlier versions...)
=20
This simplifies the termination state model by removing the ability to =
change the parm in two different, competing ways.  It also provides the =
MG the capability of setting the term into Test (which I think has value =
and utility).
=20
Comments?
=20
Kevin

-----Original Message-----
From: CHATRAS Bruno FTRD/DAC/ISS =
[mailto:bruno.chatras@francetelecom.com]=20
Sent: Wednesday, October 01, 2003 1:06 PM
To: megaco@ietf.org
Subject: [Megaco] Service Change and Testing


Hi,
=20
H.248 defines three values for the Termination State descriptor ("in =
service", "out of service" and "test"). The ServiceChange procedures =
allows the MG to notify the MGC when a termination is about to be taken =
out of service (or is being returned to service). It seems that there is =
not equivalent procedure when a termination is about to be tested (i.e. =
termination state =3D test) and is therefore not available for normal =
traffic. Is there a specific reason for treating these two states =
differently or is just that the wording "out of service" in the =
ServiceChange description encompasses both the "test" and "out of =
service" termination states. If this is the case, I think a =
clarification in the IG guide might be useful.
=20
Regards,
BC


------_=_NextPart_001_01C3BFC6.00E63A30
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4728.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Hello,</FONT></SPAN></DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =
size=3D2>As we=20
are getting close to the next Q3 meeting, I'd like to come kack on this=20
discussion about Sevrice Change and Testing.</FONT></SPAN></DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Actually, there seems to be two issues :</FONT></SPAN></DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =
size=3D2>1)=20
Need to modify the description of the Service Change procedure to allow =
the MG=20
to report state transitions when a termination is brought in test and =
when it is=20
returned to service. Whether the state transation is triggerred by the =
MGC (i.e.=20
using a modify command) or by&nbsp;the MG (i.e. test activated via a =
local=20
management interface) is irrelevant to this issue. As =
t</FONT></SPAN><SPAN=20
class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =
size=3D2>his modification=20
does not require any new method, I believe that it could be included in =
the IG=20
as&nbsp;a clarification to H.248 V2.&nbsp;A new service change reason =
might need=20
to be registered (e.g. 918 "Term in Test").</FONT></SPAN></DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =
size=3D2>2)=20
Need to remove the ability to change the Service State in two different=20
competing ways.&nbsp;Beyond making the Service State read-only, this =
indeed=20
requires a new Method and might be differred to V3, although, I think =
that there=20
is value in removing competing options as soon as =
possible.</FONT></SPAN></DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Bruno</FONT></SPAN></DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D706213908-11122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Dfr dir=3Dltr =
align=3Dleft><FONT face=3DTahoma=20
  size=3D2>-----Message d'origine-----<BR><B>De&nbsp;:</B> Kevin Boyle=20
  [mailto:kboyle@nortelnetworks.com] <BR><B>Envoy=E9&nbsp;:</B> mercredi =
1 octobre=20
  2003 19:44<BR><B>=C0&nbsp;:</B> CHATRAS Bruno FTRD/DAC/ISS;=20
  megaco@ietf.org<BR><B>Objet&nbsp;:</B> RE: [Megaco] Service Change and =

  Testing<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
  have noticed this same discrepancy.&nbsp; The problem is that the MGC =
is=20
  allowed to set the ServiceStates parm utilizing a Modify command, =
while the MG=20
  has no such capability (it must utilize ServiceChange).&nbsp; =
Therefore, there=20
  is no way for the MG to set the term into the Test =
state.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff size=3D2>In=20
  the Annex F work at the most recent Q3 meeting, I raised the idea of=20
  restricting the SI parm to being Read-only, and mandating that state =
changes=20
  must utilize ServiceChange (in both directions).&nbsp; This would also =
require=20
  a new Method to set the term to Test.&nbsp; The big problem is that =
this is a=20
  change from the current function, and may have to wait until V3 due to =
the=20
  parsing change with the Method parm&nbsp;(unless there is wide =
acceptance to=20
  push this into earlier versions...)</FONT></SPAN></DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff size=3D2>This=20
  simplifies the termination state model by removing the ability to =
change the=20
  parm in two different, competing ways.&nbsp; It also provides the MG =
the=20
  capability of setting the term into Test (which I think has value and=20
  utility).</FONT></SPAN></DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Comments?</FONT></SPAN></DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D535463017-01102003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Kevin</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
CHATRAS Bruno=20
    FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] =
<BR><B>Sent:</B>=20
    Wednesday, October 01, 2003 1:06 PM<BR><B>To:</B>=20
    megaco@ietf.org<BR><B>Subject:</B> [Megaco] Service Change and=20
    Testing<BR><BR></FONT></DIV>
    <DIV><SPAN class=3D944335516-01102003><FONT face=3DArial=20
    size=3D2>Hi,</FONT></SPAN></DIV>
    <DIV><SPAN class=3D944335516-01102003><FONT face=3DArial=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D944335516-01102003><FONT face=3DArial =
size=3D2>H.248 defines=20
    three values for the Termination State descriptor ("in service", =
"out of=20
    service" and "test"). </FONT></SPAN><SPAN =
class=3D944335516-01102003><FONT=20
    face=3DArial size=3D2>The ServiceChange procedures allows the MG to =
notify the=20
    MGC when a termination is about to be taken out of service (or is =
being=20
    returned to service). It seems that there is not equivalent =
procedure when a=20
    termination is about to be tested (i.e. termination state =3D test) =
and is=20
    therefore not available for normal traffic. Is there a specific =
reason for=20
    treating these two states differently or is just that the wording =
"out of=20
    service" in the ServiceChange&nbsp;description encompasses both the =
"test"=20
    and "out of service" termination states. If this is the case, I =
think a=20
    clarification in the IG guide might be useful.</FONT></SPAN></DIV>
    <DIV><SPAN class=3D944335516-01102003><FONT face=3DArial=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D944335516-01102003><FONT face=3DArial=20
    size=3D2>Regards,</FONT></SPAN></DIV>
    <DIV><SPAN class=3D944335516-01102003><FONT face=3DArial=20
    =
size=3D2>BC</FONT></SPAN></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3BFC6.00E63A30--

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



From megaco-admin@ietf.org  Thu Dec 11 19:10:42 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04081
	for <megaco-archive@lists.ietf.org>; Thu, 11 Dec 2003 19:10:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUash-00010j-8z; Thu, 11 Dec 2003 19:10:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUaro-0000jW-By
	for megaco@optimus.ietf.org; Thu, 11 Dec 2003 19:09:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03930
	for <megaco@ietf.org>; Thu, 11 Dec 2003 19:09:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUarl-000666-00
	for megaco@ietf.org; Thu, 11 Dec 2003 19:09:09 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUark-000650-00
	for megaco@ietf.org; Thu, 11 Dec 2003 19:09:08 -0500
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 hBC08WL19977
	for <megaco@ietf.org>; Thu, 11 Dec 2003 19:08:32 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1Y7NP>; Thu, 11 Dec 2003 19:08:33 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D26A81D@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: CHATRAS Bruno FTRD/DAC/ISS <bruno.chatras@francetelecom.com>,
        megaco@ietf.org
Subject: RE: RE : [Megaco] Service Change and Testing
Date: Thu, 11 Dec 2003 19:08:31 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

The first portion is easily done -- if we don't get any objections, I will
add it as an IG item for H.248.8.  This means that it would become part of
the H.248.8 amendment that we are planning to consent at the meeting in
January.
 
I introduced the second portion as part of the Annex F work in Paris in
September.  I happen to think that it is a good idea, as it simplifies the
overall state model for H.248 and allows the MG the capability of putting
the termination in Test -- a capability that is notably lacking in the
current protocol.
 
Now, because it would involve a new Method, this would make today's parsers
out of date.  While I don't have any objection to including these changes in
V2, I do understand that problems that a syntax change would cause for some
implementations.  If anyone has objections to including this in V2, then we
can add it to V3.  Otherwise, I think it is of benefit now, and so I would
seek to get these changes incorporated in V2.
 
Kevin


  _____  

From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] 
Sent: Thursday, December 11, 2003 4:06 AM 
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: RE : [Megaco] Service Change and Testing


Hello,
 
As we are getting close to the next Q3 meeting, I'd like to come kack on
this discussion about Sevrice Change and Testing.
 
Actually, there seems to be two issues :
 
1) Need to modify the description of the Service Change procedure to allow
the MG to report state transitions when a termination is brought in test and
when it is returned to service. Whether the state transation is triggerred
by the MGC (i.e. using a modify command) or by the MG (i.e. test activated
via a local management interface) is irrelevant to this issue. As this
modification does not require any new method, I believe that it could be
included in the IG as a clarification to H.248 V2. A new service change
reason might need to be registered (e.g. 918 "Term in Test").
 
2) Need to remove the ability to change the Service State in two different
competing ways. Beyond making the Service State read-only, this indeed
requires a new Method and might be differred to V3, although, I think that
there is value in removing competing options as soon as possible.
 
Bruno
 
 
 

-----Message d'origine-----
De : Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
Envoyé : mercredi 1 octobre 2003 19:44
À : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
Objet : RE: [Megaco] Service Change and Testing


I have noticed this same discrepancy.  The problem is that the MGC is
allowed to set the ServiceStates parm utilizing a Modify command, while the
MG has no such capability (it must utilize ServiceChange).  Therefore, there
is no way for the MG to set the term into the Test state.
 
In the Annex F work at the most recent Q3 meeting, I raised the idea of
restricting the SI parm to being Read-only, and mandating that state changes
must utilize ServiceChange (in both directions).  This would also require a
new Method to set the term to Test.  The big problem is that this is a
change from the current function, and may have to wait until V3 due to the
parsing change with the Method parm (unless there is wide acceptance to push
this into earlier versions...)
 
This simplifies the termination state model by removing the ability to
change the parm in two different, competing ways.  It also provides the MG
the capability of setting the term into Test (which I think has value and
utility).
 
Comments?
 
Kevin

-----Original Message-----
From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] 
Sent: Wednesday, October 01, 2003 1:06 PM
To: megaco@ietf.org
Subject: [Megaco] Service Change and Testing


Hi,
 
H.248 defines three values for the Termination State descriptor ("in
service", "out of service" and "test"). The ServiceChange procedures allows
the MG to notify the MGC when a termination is about to be taken out of
service (or is being returned to service). It seems that there is not
equivalent procedure when a termination is about to be tested (i.e.
termination state = test) and is therefore not available for normal traffic.
Is there a specific reason for treating these two states differently or is
just that the wording "out of service" in the ServiceChange description
encompasses both the "test" and "out of service" termination states. If this
is the case, I think a clarification in the IG guide might be useful.
 
Regards,
BC


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


From exim@www1.ietf.org  Thu Dec 11 19:10:43 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04107
	for <megaco-archive@odin.ietf.org>; Thu, 11 Dec 2003 19:10:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUass-0001BH-Jt
	for megaco-archive@odin.ietf.org; Thu, 11 Dec 2003 19:10:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC0AILE004523
	for megaco-archive@odin.ietf.org; Thu, 11 Dec 2003 19:10:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUass-0001Ao-Bo
	for megaco-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 19:10:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04014
	for <megaco-web-archive@ietf.org>; Thu, 11 Dec 2003 19:10:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUaso-00068L-00
	for megaco-web-archive@ietf.org; Thu, 11 Dec 2003 19:10:14 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUaso-00068F-00
	for megaco-web-archive@ietf.org; Thu, 11 Dec 2003 19:10:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUasg-0000z7-7G; Thu, 11 Dec 2003 19:10:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUaro-0000jS-9x
	for megaco@optimus.ietf.org; Thu, 11 Dec 2003 19:09:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03928
	for <megaco@ietf.org>; Thu, 11 Dec 2003 19:09:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUark-000663-00
	for megaco@ietf.org; Thu, 11 Dec 2003 19:09:08 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUark-00064z-00
	for megaco@ietf.org; Thu, 11 Dec 2003 19:09:08 -0500
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 hBC08WL19975
	for <megaco@ietf.org>; Thu, 11 Dec 2003 19:08:32 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1Y7NN>; Thu, 11 Dec 2003 19:08:33 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D26A81E@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: megaco@ietf.org
Date: Thu, 11 Dec 2003 19:08:32 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [Megaco] Planned amendments/corrigenda for January meeting
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

All,

I wanted to let you all know that we are currently undertaking the exercise
of taking all the IG items and working them back into the subseries
specifications themselves.  This will result in a set of Corrigenda (and, in
the case of H.248.2 and H.248.8, Amendments).  These are planned to be
approved at the meeting in January.

The result of this is that the items will be removed from the IG, so that
the IG moving forward from the January meeting will be empty.  The intent of
this is that everyone will have fewer documents to consult.  We last did
this at the February 2002 meeting.

If anyone has serious objections to this, please raise it to the list, or to
Christian or myself.
--
Kevin J. Boyle II
Succession H.248/Megaco Architect
CS2000 Media Control Protocol Standards
ESN 351-2690


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



From exim@www1.ietf.org  Thu Dec 11 19:10:44 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04124
	for <megaco-archive@odin.ietf.org>; Thu, 11 Dec 2003 19:10:44 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUass-0001BI-KY
	for megaco-archive@odin.ietf.org; Thu, 11 Dec 2003 19:10:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC0AIwv004535
	for megaco-archive@odin.ietf.org; Thu, 11 Dec 2003 19:10:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUass-0001Ap-Ck
	for megaco-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 19:10:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04017
	for <megaco-web-archive@ietf.org>; Thu, 11 Dec 2003 19:10:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUaso-00068O-00
	for megaco-web-archive@ietf.org; Thu, 11 Dec 2003 19:10:14 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUaso-00068G-00
	for megaco-web-archive@ietf.org; Thu, 11 Dec 2003 19:10:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUash-00010j-8z; Thu, 11 Dec 2003 19:10:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUaro-0000jW-By
	for megaco@optimus.ietf.org; Thu, 11 Dec 2003 19:09:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03930
	for <megaco@ietf.org>; Thu, 11 Dec 2003 19:09:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUarl-000666-00
	for megaco@ietf.org; Thu, 11 Dec 2003 19:09:09 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUark-000650-00
	for megaco@ietf.org; Thu, 11 Dec 2003 19:09:08 -0500
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 hBC08WL19977
	for <megaco@ietf.org>; Thu, 11 Dec 2003 19:08:32 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1Y7NP>; Thu, 11 Dec 2003 19:08:33 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D26A81D@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: CHATRAS Bruno FTRD/DAC/ISS <bruno.chatras@francetelecom.com>,
        megaco@ietf.org
Subject: RE: RE : [Megaco] Service Change and Testing
Date: Thu, 11 Dec 2003 19:08:31 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

The first portion is easily done -- if we don't get any objections, I will
add it as an IG item for H.248.8.  This means that it would become part of
the H.248.8 amendment that we are planning to consent at the meeting in
January.
 
I introduced the second portion as part of the Annex F work in Paris in
September.  I happen to think that it is a good idea, as it simplifies the
overall state model for H.248 and allows the MG the capability of putting
the termination in Test -- a capability that is notably lacking in the
current protocol.
 
Now, because it would involve a new Method, this would make today's parsers
out of date.  While I don't have any objection to including these changes in
V2, I do understand that problems that a syntax change would cause for some
implementations.  If anyone has objections to including this in V2, then we
can add it to V3.  Otherwise, I think it is of benefit now, and so I would
seek to get these changes incorporated in V2.
 
Kevin


  _____  

From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] 
Sent: Thursday, December 11, 2003 4:06 AM 
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: RE : [Megaco] Service Change and Testing


Hello,
 
As we are getting close to the next Q3 meeting, I'd like to come kack on
this discussion about Sevrice Change and Testing.
 
Actually, there seems to be two issues :
 
1) Need to modify the description of the Service Change procedure to allow
the MG to report state transitions when a termination is brought in test and
when it is returned to service. Whether the state transation is triggerred
by the MGC (i.e. using a modify command) or by the MG (i.e. test activated
via a local management interface) is irrelevant to this issue. As this
modification does not require any new method, I believe that it could be
included in the IG as a clarification to H.248 V2. A new service change
reason might need to be registered (e.g. 918 "Term in Test").
 
2) Need to remove the ability to change the Service State in two different
competing ways. Beyond making the Service State read-only, this indeed
requires a new Method and might be differred to V3, although, I think that
there is value in removing competing options as soon as possible.
 
Bruno
 
 
 

-----Message d'origine-----
De : Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
Envoyé : mercredi 1 octobre 2003 19:44
À : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
Objet : RE: [Megaco] Service Change and Testing


I have noticed this same discrepancy.  The problem is that the MGC is
allowed to set the ServiceStates parm utilizing a Modify command, while the
MG has no such capability (it must utilize ServiceChange).  Therefore, there
is no way for the MG to set the term into the Test state.
 
In the Annex F work at the most recent Q3 meeting, I raised the idea of
restricting the SI parm to being Read-only, and mandating that state changes
must utilize ServiceChange (in both directions).  This would also require a
new Method to set the term to Test.  The big problem is that this is a
change from the current function, and may have to wait until V3 due to the
parsing change with the Method parm (unless there is wide acceptance to push
this into earlier versions...)
 
This simplifies the termination state model by removing the ability to
change the parm in two different, competing ways.  It also provides the MG
the capability of setting the term into Test (which I think has value and
utility).
 
Comments?
 
Kevin

-----Original Message-----
From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] 
Sent: Wednesday, October 01, 2003 1:06 PM
To: megaco@ietf.org
Subject: [Megaco] Service Change and Testing


Hi,
 
H.248 defines three values for the Termination State descriptor ("in
service", "out of service" and "test"). The ServiceChange procedures allows
the MG to notify the MGC when a termination is about to be taken out of
service (or is being returned to service). It seems that there is not
equivalent procedure when a termination is about to be tested (i.e.
termination state = test) and is therefore not available for normal traffic.
Is there a specific reason for treating these two states differently or is
just that the wording "out of service" in the ServiceChange description
encompasses both the "test" and "out of service" termination states. If this
is the case, I think a clarification in the IG guide might be useful.
 
Regards,
BC


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



From megaco-admin@ietf.org  Thu Dec 11 19:57:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04080
	for <megaco-archive@lists.ietf.org>; Thu, 11 Dec 2003 19:10:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUasg-0000z7-7G; Thu, 11 Dec 2003 19:10:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUaro-0000jS-9x
	for megaco@optimus.ietf.org; Thu, 11 Dec 2003 19:09:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03928
	for <megaco@ietf.org>; Thu, 11 Dec 2003 19:09:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUark-000663-00
	for megaco@ietf.org; Thu, 11 Dec 2003 19:09:08 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUark-00064z-00
	for megaco@ietf.org; Thu, 11 Dec 2003 19:09:08 -0500
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 hBC08WL19975
	for <megaco@ietf.org>; Thu, 11 Dec 2003 19:08:32 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1Y7NN>; Thu, 11 Dec 2003 19:08:33 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D26A81E@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: megaco@ietf.org
Date: Thu, 11 Dec 2003 19:08:32 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [Megaco] Planned amendments/corrigenda for January meeting
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

All,

I wanted to let you all know that we are currently undertaking the exercise
of taking all the IG items and working them back into the subseries
specifications themselves.  This will result in a set of Corrigenda (and, in
the case of H.248.2 and H.248.8, Amendments).  These are planned to be
approved at the meeting in January.

The result of this is that the items will be removed from the IG, so that
the IG moving forward from the January meeting will be empty.  The intent of
this is that everyone will have fewer documents to consult.  We last did
this at the February 2002 meeting.

If anyone has serious objections to this, please raise it to the list, or to
Christian or myself.
--
Kevin J. Boyle II
Succession H.248/Megaco Architect
CS2000 Media Control Protocol Standards
ESN 351-2690


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


From megaco-admin@ietf.org  Fri Dec 12 01:45:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14519
	for <megaco-archive@lists.ietf.org>; Fri, 12 Dec 2003 01:45:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUh2r-0001Nd-Uy; Fri, 12 Dec 2003 01:45:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUh1x-0001MO-2i
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 01:44:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14476
	for <megaco@ietf.org>; Fri, 12 Dec 2003 01:44:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUh1t-000570-00
	for megaco@ietf.org; Fri, 12 Dec 2003 01:44:01 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUh1r-00056M-00
	for megaco@ietf.org; Fri, 12 Dec 2003 01:44:01 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBC2vPv27538;
	Fri, 12 Dec 2003 13:57:26 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.161]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5LXGX3; Fri, 12 Dec 2003 13:59:15 +1100
Message-ID: <3FD92EA2.6030708@ericsson.com>
Date: Fri, 12 Dec 2003 13:57:38 +1100
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: Kevin Boyle <kboyle@nortelnetworks.com>
CC: CHATRAS Bruno FTRD/DAC/ISS <bruno.chatras@francetelecom.com>,
        megaco@ietf.org
Subject: Re: RE : [Megaco] Service Change and Testing
References: <ABA227A15B80D511BD1A00508BF93A1C0D26A81D@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0D26A81D@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

G'Day Kevin,

Is there really a need for the MG to signal state "test"? What does this really 
mean? If it means "don't use me" then we already have "out of service". If it 
means "use me for testing" then if the MGC is becoming involved it could have 
ordered state "test" through a MOD.

Regards, Christian

Kevin Boyle wrote:

> The first portion is easily done -- if we don't get any objections, I will
> add it as an IG item for H.248.8.  This means that it would become part of
> the H.248.8 amendment that we are planning to consent at the meeting in
> January.
>  
> I introduced the second portion as part of the Annex F work in Paris in
> September.  I happen to think that it is a good idea, as it simplifies the
> overall state model for H.248 and allows the MG the capability of putting
> the termination in Test -- a capability that is notably lacking in the
> current protocol.
>  
> Now, because it would involve a new Method, this would make today's parsers
> out of date.  While I don't have any objection to including these changes in
> V2, I do understand that problems that a syntax change would cause for some
> implementations.  If anyone has objections to including this in V2, then we
> can add it to V3.  Otherwise, I think it is of benefit now, and so I would
> seek to get these changes incorporated in V2.
>  
> Kevin
> 
> 
>   _____  
> 
> From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] 
> Sent: Thursday, December 11, 2003 4:06 AM 
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
> Subject: RE : [Megaco] Service Change and Testing
> 
> 
> Hello,
>  
> As we are getting close to the next Q3 meeting, I'd like to come kack on
> this discussion about Sevrice Change and Testing.
>  
> Actually, there seems to be two issues :
>  
> 1) Need to modify the description of the Service Change procedure to allow
> the MG to report state transitions when a termination is brought in test and
> when it is returned to service. Whether the state transation is triggerred
> by the MGC (i.e. using a modify command) or by the MG (i.e. test activated
> via a local management interface) is irrelevant to this issue. As this
> modification does not require any new method, I believe that it could be
> included in the IG as a clarification to H.248 V2. A new service change
> reason might need to be registered (e.g. 918 "Term in Test").
>  
> 2) Need to remove the ability to change the Service State in two different
> competing ways. Beyond making the Service State read-only, this indeed
> requires a new Method and might be differred to V3, although, I think that
> there is value in removing competing options as soon as possible.
>  
> Bruno
>  
>  
>  
> 
> -----Message d'origine-----
> De : Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
> Envoye : mercredi 1 octobre 2003 19:44
> A : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
> Objet : RE: [Megaco] Service Change and Testing
> 
> 
> I have noticed this same discrepancy.  The problem is that the MGC is
> allowed to set the ServiceStates parm utilizing a Modify command, while the
> MG has no such capability (it must utilize ServiceChange).  Therefore, there
> is no way for the MG to set the term into the Test state.
>  
> In the Annex F work at the most recent Q3 meeting, I raised the idea of
> restricting the SI parm to being Read-only, and mandating that state changes
> must utilize ServiceChange (in both directions).  This would also require a
> new Method to set the term to Test.  The big problem is that this is a
> change from the current function, and may have to wait until V3 due to the
> parsing change with the Method parm (unless there is wide acceptance to push
> this into earlier versions...)
>  
> This simplifies the termination state model by removing the ability to
> change the parm in two different, competing ways.  It also provides the MG
> the capability of setting the term into Test (which I think has value and
> utility).
>  
> Comments?
>  
> Kevin
> 
> -----Original Message-----
> From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] 
> Sent: Wednesday, October 01, 2003 1:06 PM
> To: megaco@ietf.org
> Subject: [Megaco] Service Change and Testing
> 
> 
> Hi,
>  
> H.248 defines three values for the Termination State descriptor ("in
> service", "out of service" and "test"). The ServiceChange procedures allows
> the MG to notify the MGC when a termination is about to be taken out of
> service (or is being returned to service). It seems that there is not
> equivalent procedure when a termination is about to be tested (i.e.
> termination state = test) and is therefore not available for normal traffic.
> Is there a specific reason for treating these two states differently or is
> just that the wording "out of service" in the ServiceChange description
> encompasses both the "test" and "out of service" termination states. If this
> is the case, I think a clarification in the IG guide might be useful.
>  
> Regards,
> BC
> 
> 
> _______________________________________________
> 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 exim@www1.ietf.org  Fri Dec 12 01:45:37 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14549
	for <megaco-archive@odin.ietf.org>; Fri, 12 Dec 2003 01:45:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUh2y-0001QO-C5
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 01:45:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC6j8h6005466
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 01:45:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUh2x-0001Q0-Lc
	for megaco-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 01:45:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14514
	for <megaco-web-archive@ietf.org>; Fri, 12 Dec 2003 01:45:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUh2u-00058m-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 01:45:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUh2t-00058g-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 01:45:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUh2t-0001Nz-RA; Fri, 12 Dec 2003 01:45:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUh21-0001MT-OW
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 01:44:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14479
	for <megaco@ietf.org>; Fri, 12 Dec 2003 01:44:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUh1y-000575-00
	for megaco@ietf.org; Fri, 12 Dec 2003 01:44:06 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUh1x-00056M-00
	for megaco@ietf.org; Fri, 12 Dec 2003 01:44:05 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBBNBWv14582;
	Fri, 12 Dec 2003 10:11:33 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.161]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5LXCYQ; Fri, 12 Dec 2003 10:13:21 +1100
Message-ID: <3FD8F9B0.3090204@ericsson.com>
Date: Fri, 12 Dec 2003 10:11:44 +1100
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: CHATRAS Bruno FTRD/DAC/ISS <bruno.chatras@francetelecom.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>
CC: megaco@ietf.org
Subject: Re: RE : [Megaco] Service Change and Testing
References: <869954804BD53B41AF69F225F15FC331AA9534@ftrdmel1.rd.francetelecom.fr>
In-Reply-To: <869954804BD53B41AF69F225F15FC331AA9534@ftrdmel1.rd.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id hBBNBWv14582
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hello Bruno and Kevin,

I think there is/was some confusion over what "test state" is. I believe =
when it=20
was added to the protocol it was for the situation of test calls. The MGC=
=20
ordered these test calls thus there was no reason to have the MG indicate=
 this=20
through a Servicechange. In "test state" there is no restriction on what =
the MGC=20
can do with the termination.

It seems that people may be using "test state" for more than the example =
above.=20
If we add a ServiceChange reason for test state then we'll have 2 methods=
 of=20
changing the state.

With respect to having multiple ways of changing state to "out-of-service=
" this=20
is unfortunate and I agree can be looked at but whatever solution is prop=
osed=20
should ensure backwards compatibility. There's not a problem changing=20
"out-of-service" to "in-service" because the MGC can't ADD/MOD those term=
inations.

Bruno: Will you be sending the Tispan: Residential/Access Gateway Profile
Gate Control Profile to Q.3 and Megaco for info/review? People may be int=
erested=20
in these.

Regards, Christian

CHATRAS Bruno FTRD/DAC/ISS wrote:

> Hello,
> =20
> As we are getting close to the next Q3 meeting, I'd like to come kack o=
n=20
> this discussion about Sevrice Change and Testing.
> =20
> Actually, there seems to be two issues :
> =20
> 1) Need to modify the description of the Service Change procedure to=20
> allow the MG to report state transitions when a termination is brought=20
> in test and when it is returned to service. Whether the state transatio=
n=20
> is triggerred by the MGC (i.e. using a modify command) or by the MG=20
> (i.e. test activated via a local management interface) is irrelevant to=
=20
> this issue. As this modification does not require any new method, I=20
> believe that it could be included in the IG as a clarification to H.248=
=20
> V2. A new service change reason might need to be registered (e.g. 918=20
> "Term in Test").
> =20
> 2) Need to remove the ability to change the Service State in two=20
> different competing ways. Beyond making the Service State read-only,=20
> this indeed requires a new Method and might be differred to V3,=20
> although, I think that there is value in removing competing options as=20
> soon as possible.
> =20
> Bruno
> =20
> =20
> =20
>=20
>     -----Message d'origine-----
>     De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>     Envoy=E9 : mercredi 1 octobre 2003 19:44
>     =C0 : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
>     Objet : RE: [Megaco] Service Change and Testing
>=20
>     I have noticed this same discrepancy.  The problem is that the MGC
>     is allowed to set the ServiceStates parm utilizing a Modify command=
,
>     while the MG has no such capability (it must utilize
>     ServiceChange).  Therefore, there is no way for the MG to set the
>     term into the Test state.
>     =20
>     In the Annex F work at the most recent Q3 meeting, I raised the ide=
a
>     of restricting the SI parm to being Read-only, and mandating that
>     state changes must utilize ServiceChange (in both directions).  Thi=
s
>     would also require a new Method to set the term to Test.  The big
>     problem is that this is a change from the current function, and may
>     have to wait until V3 due to the parsing change with the Method
>     parm (unless there is wide acceptance to push this into earlier
>     versions...)
>     =20
>     This simplifies the termination state model by removing the ability
>     to change the parm in two different, competing ways.  It also
>     provides the MG the capability of setting the term into Test (which
>     I think has value and utility).
>     =20
>     Comments?
>     =20
>     Kevin
>=20
>         -----Original Message-----
>         From: CHATRAS Bruno FTRD/DAC/ISS
>         [mailto:bruno.chatras@francetelecom.com]
>         Sent: Wednesday, October 01, 2003 1:06 PM
>         To: megaco@ietf.org
>         Subject: [Megaco] Service Change and Testing
>=20
>         Hi,
>         =20
>         H.248 defines three values for the Termination State descriptor
>         ("in service", "out of service" and "test"). The ServiceChange
>         procedures allows the MG to notify the MGC when a termination i=
s
>         about to be taken out of service (or is being returned to
>         service). It seems that there is not equivalent procedure when =
a
>         termination is about to be tested (i.e. termination state =3D
>         test) and is therefore not available for normal traffic. Is
>         there a specific reason for treating these two states
>         differently or is just that the wording "out of service" in the
>         ServiceChange description encompasses both the "test" and "out
>         of service" termination states. If this is the case, I think a
>         clarification in the IG guide might be useful.
>         =20
>         Regards,
>         BC


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



From megaco-admin@ietf.org  Fri Dec 12 02:32:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14520
	for <megaco-archive@lists.ietf.org>; Fri, 12 Dec 2003 01:45:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUh2t-0001Nz-RA; Fri, 12 Dec 2003 01:45:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUh21-0001MT-OW
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 01:44:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14479
	for <megaco@ietf.org>; Fri, 12 Dec 2003 01:44:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUh1y-000575-00
	for megaco@ietf.org; Fri, 12 Dec 2003 01:44:06 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUh1x-00056M-00
	for megaco@ietf.org; Fri, 12 Dec 2003 01:44:05 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBBNBWv14582;
	Fri, 12 Dec 2003 10:11:33 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.161]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5LXCYQ; Fri, 12 Dec 2003 10:13:21 +1100
Message-ID: <3FD8F9B0.3090204@ericsson.com>
Date: Fri, 12 Dec 2003 10:11:44 +1100
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: CHATRAS Bruno FTRD/DAC/ISS <bruno.chatras@francetelecom.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>
CC: megaco@ietf.org
Subject: Re: RE : [Megaco] Service Change and Testing
References: <869954804BD53B41AF69F225F15FC331AA9534@ftrdmel1.rd.francetelecom.fr>
In-Reply-To: <869954804BD53B41AF69F225F15FC331AA9534@ftrdmel1.rd.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id hBBNBWv14582
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: quoted-printable

Hello Bruno and Kevin,

I think there is/was some confusion over what "test state" is. I believe =
when it=20
was added to the protocol it was for the situation of test calls. The MGC=
=20
ordered these test calls thus there was no reason to have the MG indicate=
 this=20
through a Servicechange. In "test state" there is no restriction on what =
the MGC=20
can do with the termination.

It seems that people may be using "test state" for more than the example =
above.=20
If we add a ServiceChange reason for test state then we'll have 2 methods=
 of=20
changing the state.

With respect to having multiple ways of changing state to "out-of-service=
" this=20
is unfortunate and I agree can be looked at but whatever solution is prop=
osed=20
should ensure backwards compatibility. There's not a problem changing=20
"out-of-service" to "in-service" because the MGC can't ADD/MOD those term=
inations.

Bruno: Will you be sending the Tispan: Residential/Access Gateway Profile
Gate Control Profile to Q.3 and Megaco for info/review? People may be int=
erested=20
in these.

Regards, Christian

CHATRAS Bruno FTRD/DAC/ISS wrote:

> Hello,
> =20
> As we are getting close to the next Q3 meeting, I'd like to come kack o=
n=20
> this discussion about Sevrice Change and Testing.
> =20
> Actually, there seems to be two issues :
> =20
> 1) Need to modify the description of the Service Change procedure to=20
> allow the MG to report state transitions when a termination is brought=20
> in test and when it is returned to service. Whether the state transatio=
n=20
> is triggerred by the MGC (i.e. using a modify command) or by the MG=20
> (i.e. test activated via a local management interface) is irrelevant to=
=20
> this issue. As this modification does not require any new method, I=20
> believe that it could be included in the IG as a clarification to H.248=
=20
> V2. A new service change reason might need to be registered (e.g. 918=20
> "Term in Test").
> =20
> 2) Need to remove the ability to change the Service State in two=20
> different competing ways. Beyond making the Service State read-only,=20
> this indeed requires a new Method and might be differred to V3,=20
> although, I think that there is value in removing competing options as=20
> soon as possible.
> =20
> Bruno
> =20
> =20
> =20
>=20
>     -----Message d'origine-----
>     De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>     Envoy=E9 : mercredi 1 octobre 2003 19:44
>     =C0 : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
>     Objet : RE: [Megaco] Service Change and Testing
>=20
>     I have noticed this same discrepancy.  The problem is that the MGC
>     is allowed to set the ServiceStates parm utilizing a Modify command=
,
>     while the MG has no such capability (it must utilize
>     ServiceChange).  Therefore, there is no way for the MG to set the
>     term into the Test state.
>     =20
>     In the Annex F work at the most recent Q3 meeting, I raised the ide=
a
>     of restricting the SI parm to being Read-only, and mandating that
>     state changes must utilize ServiceChange (in both directions).  Thi=
s
>     would also require a new Method to set the term to Test.  The big
>     problem is that this is a change from the current function, and may
>     have to wait until V3 due to the parsing change with the Method
>     parm (unless there is wide acceptance to push this into earlier
>     versions...)
>     =20
>     This simplifies the termination state model by removing the ability
>     to change the parm in two different, competing ways.  It also
>     provides the MG the capability of setting the term into Test (which
>     I think has value and utility).
>     =20
>     Comments?
>     =20
>     Kevin
>=20
>         -----Original Message-----
>         From: CHATRAS Bruno FTRD/DAC/ISS
>         [mailto:bruno.chatras@francetelecom.com]
>         Sent: Wednesday, October 01, 2003 1:06 PM
>         To: megaco@ietf.org
>         Subject: [Megaco] Service Change and Testing
>=20
>         Hi,
>         =20
>         H.248 defines three values for the Termination State descriptor
>         ("in service", "out of service" and "test"). The ServiceChange
>         procedures allows the MG to notify the MGC when a termination i=
s
>         about to be taken out of service (or is being returned to
>         service). It seems that there is not equivalent procedure when =
a
>         termination is about to be tested (i.e. termination state =3D
>         test) and is therefore not available for normal traffic. Is
>         there a specific reason for treating these two states
>         differently or is just that the wording "out of service" in the
>         ServiceChange description encompasses both the "test" and "out
>         of service" termination states. If this is the case, I think a
>         clarification in the IG guide might be useful.
>         =20
>         Regards,
>         BC


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


From exim@www1.ietf.org  Fri Dec 12 02:32:25 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14550
	for <megaco-archive@odin.ietf.org>; Fri, 12 Dec 2003 01:45:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUh2y-0001QM-Bg
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 01:45:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC6j8ND005465
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 01:45:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUh2x-0001Pz-DX
	for megaco-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 01:45:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14512
	for <megaco-web-archive@ietf.org>; Fri, 12 Dec 2003 01:45:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUh2t-00058j-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 01:45:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUh2t-00058f-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 01:45:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUh2r-0001Nd-Uy; Fri, 12 Dec 2003 01:45:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUh1x-0001MO-2i
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 01:44:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14476
	for <megaco@ietf.org>; Fri, 12 Dec 2003 01:44:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUh1t-000570-00
	for megaco@ietf.org; Fri, 12 Dec 2003 01:44:01 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUh1r-00056M-00
	for megaco@ietf.org; Fri, 12 Dec 2003 01:44:01 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBC2vPv27538;
	Fri, 12 Dec 2003 13:57:26 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.161]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5LXGX3; Fri, 12 Dec 2003 13:59:15 +1100
Message-ID: <3FD92EA2.6030708@ericsson.com>
Date: Fri, 12 Dec 2003 13:57:38 +1100
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: Kevin Boyle <kboyle@nortelnetworks.com>
CC: CHATRAS Bruno FTRD/DAC/ISS <bruno.chatras@francetelecom.com>,
        megaco@ietf.org
Subject: Re: RE : [Megaco] Service Change and Testing
References: <ABA227A15B80D511BD1A00508BF93A1C0D26A81D@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0D26A81D@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

G'Day Kevin,

Is there really a need for the MG to signal state "test"? What does this really 
mean? If it means "don't use me" then we already have "out of service". If it 
means "use me for testing" then if the MGC is becoming involved it could have 
ordered state "test" through a MOD.

Regards, Christian

Kevin Boyle wrote:

> The first portion is easily done -- if we don't get any objections, I will
> add it as an IG item for H.248.8.  This means that it would become part of
> the H.248.8 amendment that we are planning to consent at the meeting in
> January.
>  
> I introduced the second portion as part of the Annex F work in Paris in
> September.  I happen to think that it is a good idea, as it simplifies the
> overall state model for H.248 and allows the MG the capability of putting
> the termination in Test -- a capability that is notably lacking in the
> current protocol.
>  
> Now, because it would involve a new Method, this would make today's parsers
> out of date.  While I don't have any objection to including these changes in
> V2, I do understand that problems that a syntax change would cause for some
> implementations.  If anyone has objections to including this in V2, then we
> can add it to V3.  Otherwise, I think it is of benefit now, and so I would
> seek to get these changes incorporated in V2.
>  
> Kevin
> 
> 
>   _____  
> 
> From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] 
> Sent: Thursday, December 11, 2003 4:06 AM 
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
> Subject: RE : [Megaco] Service Change and Testing
> 
> 
> Hello,
>  
> As we are getting close to the next Q3 meeting, I'd like to come kack on
> this discussion about Sevrice Change and Testing.
>  
> Actually, there seems to be two issues :
>  
> 1) Need to modify the description of the Service Change procedure to allow
> the MG to report state transitions when a termination is brought in test and
> when it is returned to service. Whether the state transation is triggerred
> by the MGC (i.e. using a modify command) or by the MG (i.e. test activated
> via a local management interface) is irrelevant to this issue. As this
> modification does not require any new method, I believe that it could be
> included in the IG as a clarification to H.248 V2. A new service change
> reason might need to be registered (e.g. 918 "Term in Test").
>  
> 2) Need to remove the ability to change the Service State in two different
> competing ways. Beyond making the Service State read-only, this indeed
> requires a new Method and might be differred to V3, although, I think that
> there is value in removing competing options as soon as possible.
>  
> Bruno
>  
>  
>  
> 
> -----Message d'origine-----
> De : Kevin Boyle [mailto:kboyle@nortelnetworks.com] 
> Envoye : mercredi 1 octobre 2003 19:44
> A : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
> Objet : RE: [Megaco] Service Change and Testing
> 
> 
> I have noticed this same discrepancy.  The problem is that the MGC is
> allowed to set the ServiceStates parm utilizing a Modify command, while the
> MG has no such capability (it must utilize ServiceChange).  Therefore, there
> is no way for the MG to set the term into the Test state.
>  
> In the Annex F work at the most recent Q3 meeting, I raised the idea of
> restricting the SI parm to being Read-only, and mandating that state changes
> must utilize ServiceChange (in both directions).  This would also require a
> new Method to set the term to Test.  The big problem is that this is a
> change from the current function, and may have to wait until V3 due to the
> parsing change with the Method parm (unless there is wide acceptance to push
> this into earlier versions...)
>  
> This simplifies the termination state model by removing the ability to
> change the parm in two different, competing ways.  It also provides the MG
> the capability of setting the term into Test (which I think has value and
> utility).
>  
> Comments?
>  
> Kevin
> 
> -----Original Message-----
> From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] 
> Sent: Wednesday, October 01, 2003 1:06 PM
> To: megaco@ietf.org
> Subject: [Megaco] Service Change and Testing
> 
> 
> Hi,
>  
> H.248 defines three values for the Termination State descriptor ("in
> service", "out of service" and "test"). The ServiceChange procedures allows
> the MG to notify the MGC when a termination is about to be taken out of
> service (or is being returned to service). It seems that there is not
> equivalent procedure when a termination is about to be tested (i.e.
> termination state = test) and is therefore not available for normal traffic.
> Is there a specific reason for treating these two states differently or is
> just that the wording "out of service" in the ServiceChange description
> encompasses both the "test" and "out of service" termination states. If this
> is the case, I think a clarification in the IG guide might be useful.
>  
> Regards,
> BC
> 
> 
> _______________________________________________
> 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-admin@ietf.org  Fri Dec 12 04:25:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02280
	for <megaco-archive@lists.ietf.org>; Fri, 12 Dec 2003 04:25:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUjXi-0001W0-Jl; Fri, 12 Dec 2003 04:25:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUjWu-0001V1-TT
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 04:24:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02238
	for <megaco@ietf.org>; Fri, 12 Dec 2003 04:24:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUjWr-0000cT-00
	for megaco@ietf.org; Fri, 12 Dec 2003 04:24:09 -0500
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUjWr-0000cQ-00
	for megaco@ietf.org; Fri, 12 Dec 2003 04:24:09 -0500
Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Fri, 12 Dec 2003 10:24:03 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE : RE : [Megaco] Service Change and Testing
Date: Fri, 12 Dec 2003 10:24:02 +0100
Message-ID: <869954804BD53B41AF69F225F15FC331AA9886@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: RE : [Megaco] Service Change and Testing
Thread-Index: AcPAe6La4cwSUlrESVSp6t5QPBqsMAAESXmQ
From: "CHATRAS Bruno FTRD/DAC/ISS" <bruno.chatras@francetelecom.com>
To: "Christian Groves" <Christian.Groves@ericsson.com>,
        "Kevin Boyle" <kboyle@nortelnetworks.com>
Cc: <megaco@ietf.org>
X-OriginalArrivalTime: 12 Dec 2003 09:24:03.0136 (UTC) FILETIME=[AEC3BC00:01C3C091]
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: quoted-printable

Hello Christian,

Testing : What I'm really looking for is a solution that ensures that if =
a local operator starts testing a termination, the MG notifies the MGC =
that this termination cannot be used for normal traffic. The type of =
test I have in mind is not a test call, but the direct connection of =
specific devices to check the physical properties (e.g.; resistance, =
strand insulation)of the copper line. I agree that in such cases, we may =
use "out of service" instead of "test". However, if this is the =
agreement, I believe that explanatory text would need to be added to the =
IG to limit the scope of the "test" state to the case of test calls.

TISPAN : I did not thought about submitting the TISPAN profiles to Q3 at =
this stage. However, this might be a good opportunity to get comments =
from a wider audience.

Bruno



-----Message d'origine-----
De : Christian Groves [mailto:Christian.Groves@ericsson.com]=20
Envoy=E9 : vendredi 12 d=E9cembre 2003 00:12
=C0 : CHATRAS Bruno FTRD/DAC/ISS; Kevin Boyle
Cc : megaco@ietf.org
Objet : Re: RE : [Megaco] Service Change and Testing


Hello Bruno and Kevin,

I think there is/was some confusion over what "test state" is. I believe =
when it=20
was added to the protocol it was for the situation of test calls. The =
MGC=20
ordered these test calls thus there was no reason to have the MG =
indicate this=20
through a Servicechange. In "test state" there is no restriction on what =
the MGC=20
can do with the termination.

It seems that people may be using "test state" for more than the example =
above.=20
If we add a ServiceChange reason for test state then we'll have 2 =
methods of=20
changing the state.

With respect to having multiple ways of changing state to =
"out-of-service" this=20
is unfortunate and I agree can be looked at but whatever solution is =
proposed=20
should ensure backwards compatibility. There's not a problem changing=20
"out-of-service" to "in-service" because the MGC can't ADD/MOD those =
terminations.

Bruno: Will you be sending the Tispan: Residential/Access Gateway =
Profile Gate Control Profile to Q.3 and Megaco for info/review? People =
may be interested=20
in these.

Regards, Christian

CHATRAS Bruno FTRD/DAC/ISS wrote:

> Hello,
> =20
> As we are getting close to the next Q3 meeting, I'd like to come kack=20
> on
> this discussion about Sevrice Change and Testing.
> =20
> Actually, there seems to be two issues :
> =20
> 1) Need to modify the description of the Service Change procedure to
> allow the MG to report state transitions when a termination is brought =

> in test and when it is returned to service. Whether the state =
transation=20
> is triggerred by the MGC (i.e. using a modify command) or by the MG=20
> (i.e. test activated via a local management interface) is irrelevant =
to=20
> this issue. As this modification does not require any new method, I=20
> believe that it could be included in the IG as a clarification to =
H.248=20
> V2. A new service change reason might need to be registered (e.g. 918=20
> "Term in Test").
> =20
> 2) Need to remove the ability to change the Service State in two
> different competing ways. Beyond making the Service State read-only,=20
> this indeed requires a new Method and might be differred to V3,=20
> although, I think that there is value in removing competing options as =

> soon as possible.
> =20
> Bruno
> =20
> =20
> =20
>=20
>     -----Message d'origine-----
>     De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>     Envoy=E9 : mercredi 1 octobre 2003 19:44
>     =C0 : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
>     Objet : RE: [Megaco] Service Change and Testing
>=20
>     I have noticed this same discrepancy.  The problem is that the MGC
>     is allowed to set the ServiceStates parm utilizing a Modify =
command,
>     while the MG has no such capability (it must utilize
>     ServiceChange).  Therefore, there is no way for the MG to set the
>     term into the Test state.
>     =20
>     In the Annex F work at the most recent Q3 meeting, I raised the =
idea
>     of restricting the SI parm to being Read-only, and mandating that
>     state changes must utilize ServiceChange (in both directions).  =
This
>     would also require a new Method to set the term to Test.  The big
>     problem is that this is a change from the current function, and =
may
>     have to wait until V3 due to the parsing change with the Method
>     parm (unless there is wide acceptance to push this into earlier
>     versions...)
>     =20
>     This simplifies the termination state model by removing the =
ability
>     to change the parm in two different, competing ways.  It also
>     provides the MG the capability of setting the term into Test =
(which
>     I think has value and utility).
>     =20
>     Comments?
>     =20
>     Kevin
>=20
>         -----Original Message-----
>         From: CHATRAS Bruno FTRD/DAC/ISS
>         [mailto:bruno.chatras@francetelecom.com]
>         Sent: Wednesday, October 01, 2003 1:06 PM
>         To: megaco@ietf.org
>         Subject: [Megaco] Service Change and Testing
>=20
>         Hi,
>         =20
>         H.248 defines three values for the Termination State =
descriptor
>         ("in service", "out of service" and "test"). The ServiceChange
>         procedures allows the MG to notify the MGC when a termination =
is
>         about to be taken out of service (or is being returned to
>         service). It seems that there is not equivalent procedure when =
a
>         termination is about to be tested (i.e. termination state =3D
>         test) and is therefore not available for normal traffic. Is
>         there a specific reason for treating these two states
>         differently or is just that the wording "out of service" in =
the
>         ServiceChange description encompasses both the "test" and "out
>         of service" termination states. If this is the case, I think a
>         clarification in the IG guide might be useful.
>         =20
>         Regards,
>         BC


_______________________________________________
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 exim@www1.ietf.org  Fri Dec 12 04:25:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02298
	for <megaco-archive@odin.ietf.org>; Fri, 12 Dec 2003 04:25:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUjXn-0001XR-3z
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 04:25:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC9P6lZ005907
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 04:25:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUjXl-0001XC-FU
	for megaco-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 04:25:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02262
	for <megaco-web-archive@ietf.org>; Fri, 12 Dec 2003 04:25:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUjXi-0000dR-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 04:25:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUjXh-0000dN-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 04:25:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUjXi-0001W0-Jl; Fri, 12 Dec 2003 04:25:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUjWu-0001V1-TT
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 04:24:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02238
	for <megaco@ietf.org>; Fri, 12 Dec 2003 04:24:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUjWr-0000cT-00
	for megaco@ietf.org; Fri, 12 Dec 2003 04:24:09 -0500
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUjWr-0000cQ-00
	for megaco@ietf.org; Fri, 12 Dec 2003 04:24:09 -0500
Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Fri, 12 Dec 2003 10:24:03 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE : RE : [Megaco] Service Change and Testing
Date: Fri, 12 Dec 2003 10:24:02 +0100
Message-ID: <869954804BD53B41AF69F225F15FC331AA9886@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: RE : [Megaco] Service Change and Testing
Thread-Index: AcPAe6La4cwSUlrESVSp6t5QPBqsMAAESXmQ
From: "CHATRAS Bruno FTRD/DAC/ISS" <bruno.chatras@francetelecom.com>
To: "Christian Groves" <Christian.Groves@ericsson.com>,
        "Kevin Boyle" <kboyle@nortelnetworks.com>
Cc: <megaco@ietf.org>
X-OriginalArrivalTime: 12 Dec 2003 09:24:03.0136 (UTC) FILETIME=[AEC3BC00:01C3C091]
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hello Christian,

Testing : What I'm really looking for is a solution that ensures that if =
a local operator starts testing a termination, the MG notifies the MGC =
that this termination cannot be used for normal traffic. The type of =
test I have in mind is not a test call, but the direct connection of =
specific devices to check the physical properties (e.g.; resistance, =
strand insulation)of the copper line. I agree that in such cases, we may =
use "out of service" instead of "test". However, if this is the =
agreement, I believe that explanatory text would need to be added to the =
IG to limit the scope of the "test" state to the case of test calls.

TISPAN : I did not thought about submitting the TISPAN profiles to Q3 at =
this stage. However, this might be a good opportunity to get comments =
from a wider audience.

Bruno



-----Message d'origine-----
De : Christian Groves [mailto:Christian.Groves@ericsson.com]=20
Envoy=E9 : vendredi 12 d=E9cembre 2003 00:12
=C0 : CHATRAS Bruno FTRD/DAC/ISS; Kevin Boyle
Cc : megaco@ietf.org
Objet : Re: RE : [Megaco] Service Change and Testing


Hello Bruno and Kevin,

I think there is/was some confusion over what "test state" is. I believe =
when it=20
was added to the protocol it was for the situation of test calls. The =
MGC=20
ordered these test calls thus there was no reason to have the MG =
indicate this=20
through a Servicechange. In "test state" there is no restriction on what =
the MGC=20
can do with the termination.

It seems that people may be using "test state" for more than the example =
above.=20
If we add a ServiceChange reason for test state then we'll have 2 =
methods of=20
changing the state.

With respect to having multiple ways of changing state to =
"out-of-service" this=20
is unfortunate and I agree can be looked at but whatever solution is =
proposed=20
should ensure backwards compatibility. There's not a problem changing=20
"out-of-service" to "in-service" because the MGC can't ADD/MOD those =
terminations.

Bruno: Will you be sending the Tispan: Residential/Access Gateway =
Profile Gate Control Profile to Q.3 and Megaco for info/review? People =
may be interested=20
in these.

Regards, Christian

CHATRAS Bruno FTRD/DAC/ISS wrote:

> Hello,
> =20
> As we are getting close to the next Q3 meeting, I'd like to come kack=20
> on
> this discussion about Sevrice Change and Testing.
> =20
> Actually, there seems to be two issues :
> =20
> 1) Need to modify the description of the Service Change procedure to
> allow the MG to report state transitions when a termination is brought =

> in test and when it is returned to service. Whether the state =
transation=20
> is triggerred by the MGC (i.e. using a modify command) or by the MG=20
> (i.e. test activated via a local management interface) is irrelevant =
to=20
> this issue. As this modification does not require any new method, I=20
> believe that it could be included in the IG as a clarification to =
H.248=20
> V2. A new service change reason might need to be registered (e.g. 918=20
> "Term in Test").
> =20
> 2) Need to remove the ability to change the Service State in two
> different competing ways. Beyond making the Service State read-only,=20
> this indeed requires a new Method and might be differred to V3,=20
> although, I think that there is value in removing competing options as =

> soon as possible.
> =20
> Bruno
> =20
> =20
> =20
>=20
>     -----Message d'origine-----
>     De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>     Envoy=E9 : mercredi 1 octobre 2003 19:44
>     =C0 : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
>     Objet : RE: [Megaco] Service Change and Testing
>=20
>     I have noticed this same discrepancy.  The problem is that the MGC
>     is allowed to set the ServiceStates parm utilizing a Modify =
command,
>     while the MG has no such capability (it must utilize
>     ServiceChange).  Therefore, there is no way for the MG to set the
>     term into the Test state.
>     =20
>     In the Annex F work at the most recent Q3 meeting, I raised the =
idea
>     of restricting the SI parm to being Read-only, and mandating that
>     state changes must utilize ServiceChange (in both directions).  =
This
>     would also require a new Method to set the term to Test.  The big
>     problem is that this is a change from the current function, and =
may
>     have to wait until V3 due to the parsing change with the Method
>     parm (unless there is wide acceptance to push this into earlier
>     versions...)
>     =20
>     This simplifies the termination state model by removing the =
ability
>     to change the parm in two different, competing ways.  It also
>     provides the MG the capability of setting the term into Test =
(which
>     I think has value and utility).
>     =20
>     Comments?
>     =20
>     Kevin
>=20
>         -----Original Message-----
>         From: CHATRAS Bruno FTRD/DAC/ISS
>         [mailto:bruno.chatras@francetelecom.com]
>         Sent: Wednesday, October 01, 2003 1:06 PM
>         To: megaco@ietf.org
>         Subject: [Megaco] Service Change and Testing
>=20
>         Hi,
>         =20
>         H.248 defines three values for the Termination State =
descriptor
>         ("in service", "out of service" and "test"). The ServiceChange
>         procedures allows the MG to notify the MGC when a termination =
is
>         about to be taken out of service (or is being returned to
>         service). It seems that there is not equivalent procedure when =
a
>         termination is about to be tested (i.e. termination state =3D
>         test) and is therefore not available for normal traffic. Is
>         there a specific reason for treating these two states
>         differently or is just that the wording "out of service" in =
the
>         ServiceChange description encompasses both the "test" and "out
>         of service" termination states. If this is the case, I think a
>         clarification in the IG guide might be useful.
>         =20
>         Regards,
>         BC


_______________________________________________
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-admin@ietf.org  Fri Dec 12 11:04:28 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14103
	for <megaco-archive@lists.ietf.org>; Fri, 12 Dec 2003 11:04:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUplp-0000OD-O7; Fri, 12 Dec 2003 11:04:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUpl4-0000NU-3P
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 11:03:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14009
	for <megaco@ietf.org>; Fri, 12 Dec 2003 11:03:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUpl1-00001D-00
	for megaco@ietf.org; Fri, 12 Dec 2003 11:03:11 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUpl0-0007nh-00
	for megaco@ietf.org; Fri, 12 Dec 2003 11:03:10 -0500
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 hBCG2ct26449
	for <megaco@ietf.org>; Fri, 12 Dec 2003 11:02:38 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1ZFXG>; Fri, 12 Dec 2003 11:02:38 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D2B3BF2@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Christian Groves <Christian.Groves@ericsson.com>,
        CHATRAS Bruno FTRD/DAC/ISS <bruno.chatras@francetelecom.com>
Cc: megaco@ietf.org
Subject: RE: RE : [Megaco] Service Change and Testing
Date: Fri, 12 Dec 2003 11:02:37 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Only Add and Move are prohibited by ServiceState.  Modifies of OOS terms are
allowed -- although some actions undertaken through a modify may not make
sense.

I agree that we should not have two methods to change the state -- hence the
suggestion that the ServiceStates property be made ReadOnly.  That way the
only way to modify the ServiceState of the termination will be via
ServiceChange.

Kevin

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com] 
Sent: Thursday, December 11, 2003 6:12 PM
To: CHATRAS Bruno FTRD/DAC/ISS; Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: Re: RE : [Megaco] Service Change and Testing

Hello Bruno and Kevin,

I think there is/was some confusion over what "test state" is. I believe
when it was added to the protocol it was for the situation of test calls.
The MGC ordered these test calls thus there was no reason to have the MG
indicate this through a Servicechange. In "test state" there is no
restriction on what the MGC can do with the termination.

It seems that people may be using "test state" for more than the example
above. 
If we add a ServiceChange reason for test state then we'll have 2 methods of
changing the state.

With respect to having multiple ways of changing state to "out-of-service"
this is unfortunate and I agree can be looked at but whatever solution is
proposed should ensure backwards compatibility. There's not a problem
changing "out-of-service" to "in-service" because the MGC can't ADD/MOD
those terminations.

Bruno: Will you be sending the Tispan: Residential/Access Gateway Profile
Gate Control Profile to Q.3 and Megaco for info/review? People may be
interested in these.

Regards, Christian

CHATRAS Bruno FTRD/DAC/ISS wrote:

> Hello,
>  
> As we are getting close to the next Q3 meeting, I'd like to come kack 
> on this discussion about Sevrice Change and Testing.
>  
> Actually, there seems to be two issues :
>  
> 1) Need to modify the description of the Service Change procedure to 
> allow the MG to report state transitions when a termination is brought 
> in test and when it is returned to service. Whether the state 
> transation is triggerred by the MGC (i.e. using a modify command) or 
> by the MG (i.e. test activated via a local management interface) is 
> irrelevant to this issue. As this modification does not require any 
> new method, I believe that it could be included in the IG as a 
> clarification to H.248 V2. A new service change reason might need to 
> be registered (e.g. 918 "Term in Test").
>  
> 2) Need to remove the ability to change the Service State in two 
> different competing ways. Beyond making the Service State read-only, 
> this indeed requires a new Method and might be differred to V3, 
> although, I think that there is value in removing competing options as 
> soon as possible.
>  
> Bruno
>  
>  
>  
> 
>     -----Message d'origine-----
>     De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>     Envoyé : mercredi 1 octobre 2003 19:44
>     À : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
>     Objet : RE: [Megaco] Service Change and Testing
> 
>     I have noticed this same discrepancy.  The problem is that the MGC
>     is allowed to set the ServiceStates parm utilizing a Modify command,
>     while the MG has no such capability (it must utilize
>     ServiceChange).  Therefore, there is no way for the MG to set the
>     term into the Test state.
>      
>     In the Annex F work at the most recent Q3 meeting, I raised the idea
>     of restricting the SI parm to being Read-only, and mandating that
>     state changes must utilize ServiceChange (in both directions).  This
>     would also require a new Method to set the term to Test.  The big
>     problem is that this is a change from the current function, and may
>     have to wait until V3 due to the parsing change with the Method
>     parm (unless there is wide acceptance to push this into earlier
>     versions...)
>      
>     This simplifies the termination state model by removing the ability
>     to change the parm in two different, competing ways.  It also
>     provides the MG the capability of setting the term into Test (which
>     I think has value and utility).
>      
>     Comments?
>      
>     Kevin
> 
>         -----Original Message-----
>         From: CHATRAS Bruno FTRD/DAC/ISS
>         [mailto:bruno.chatras@francetelecom.com]
>         Sent: Wednesday, October 01, 2003 1:06 PM
>         To: megaco@ietf.org
>         Subject: [Megaco] Service Change and Testing
> 
>         Hi,
>          
>         H.248 defines three values for the Termination State descriptor
>         ("in service", "out of service" and "test"). The ServiceChange
>         procedures allows the MG to notify the MGC when a termination is
>         about to be taken out of service (or is being returned to
>         service). It seems that there is not equivalent procedure when a
>         termination is about to be tested (i.e. termination state =
>         test) and is therefore not available for normal traffic. Is
>         there a specific reason for treating these two states
>         differently or is just that the wording "out of service" in the
>         ServiceChange description encompasses both the "test" and "out
>         of service" termination states. If this is the case, I think a
>         clarification in the IG guide might be useful.
>          
>         Regards,
>         BC


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


From exim@www1.ietf.org  Fri Dec 12 11:04:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14130
	for <megaco-archive@odin.ietf.org>; Fri, 12 Dec 2003 11:04:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUpls-0000Pg-Bf
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 11:04:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCG447K001583
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 11:04:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUpls-0000PS-7V
	for megaco-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 11:04:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14069
	for <megaco-web-archive@ietf.org>; Fri, 12 Dec 2003 11:03:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUplp-000032-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 11:04:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUplp-00002w-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 11:04:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUplq-0000ON-DJ; Fri, 12 Dec 2003 11:04:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUpl4-0000NV-CP
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 11:03:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14012
	for <megaco@ietf.org>; Fri, 12 Dec 2003 11:03:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUpl1-00001I-00
	for megaco@ietf.org; Fri, 12 Dec 2003 11:03:11 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUpl0-0007nk-00
	for megaco@ietf.org; Fri, 12 Dec 2003 11:03:10 -0500
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 hBCG2c904854
	for <megaco@ietf.org>; Fri, 12 Dec 2003 11:02:38 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1ZFXH>; Fri, 12 Dec 2003 11:02:38 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D2B3BEF@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: CHATRAS Bruno FTRD/DAC/ISS <bruno.chatras@francetelecom.com>,
        Christian Groves <Christian.Groves@ericsson.com>
Cc: megaco@ietf.org
Subject: RE: RE : RE : [Megaco] Service Change and Testing
Date: Fri, 12 Dec 2003 11:02:36 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

I believe that there is benefit to having the MGC aware that the reason that
the term is OOS is because it is undergoing test.  Given that the MGC and MG
may be in very different physical locations, the personnel at the MGC site
may not have immediate knowledge of what is going on at the remote MG
location.  Denoting that a particular termination is OOS tends to cause
concern if the term should otherwise be inservice.  However, having that
term in a test state shows that there isn't necessarily anything wrong at
the MG -- just that the term is being tested.

I believe the test state also applies to things like metallic test access --
not just test calls.

Kevin

-----Original Message-----
From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] 
Sent: Friday, December 12, 2003 4:24 AM
To: Christian Groves; Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: RE : RE : [Megaco] Service Change and Testing

Hello Christian,

Testing : What I'm really looking for is a solution that ensures that if a
local operator starts testing a termination, the MG notifies the MGC that
this termination cannot be used for normal traffic. The type of test I have
in mind is not a test call, but the direct connection of specific devices to
check the physical properties (e.g.; resistance, strand insulation)of the
copper line. I agree that in such cases, we may use "out of service" instead
of "test". However, if this is the agreement, I believe that explanatory
text would need to be added to the IG to limit the scope of the "test" state
to the case of test calls.

TISPAN : I did not thought about submitting the TISPAN profiles to Q3 at
this stage. However, this might be a good opportunity to get comments from a
wider audience.

Bruno



-----Message d'origine-----
De : Christian Groves [mailto:Christian.Groves@ericsson.com]
Envoyé : vendredi 12 décembre 2003 00:12 À : CHATRAS Bruno FTRD/DAC/ISS;
Kevin Boyle Cc : megaco@ietf.org Objet : Re: RE : [Megaco] Service Change
and Testing


Hello Bruno and Kevin,

I think there is/was some confusion over what "test state" is. I believe
when it 
was added to the protocol it was for the situation of test calls. The MGC 
ordered these test calls thus there was no reason to have the MG indicate
this 
through a Servicechange. In "test state" there is no restriction on what the
MGC 
can do with the termination.

It seems that people may be using "test state" for more than the example
above. 
If we add a ServiceChange reason for test state then we'll have 2 methods of

changing the state.

With respect to having multiple ways of changing state to "out-of-service"
this 
is unfortunate and I agree can be looked at but whatever solution is
proposed 
should ensure backwards compatibility. There's not a problem changing 
"out-of-service" to "in-service" because the MGC can't ADD/MOD those
terminations.

Bruno: Will you be sending the Tispan: Residential/Access Gateway Profile
Gate Control Profile to Q.3 and Megaco for info/review? People may be
interested 
in these.

Regards, Christian

CHATRAS Bruno FTRD/DAC/ISS wrote:

> Hello,
>  
> As we are getting close to the next Q3 meeting, I'd like to come kack 
> on
> this discussion about Sevrice Change and Testing.
>  
> Actually, there seems to be two issues :
>  
> 1) Need to modify the description of the Service Change procedure to
> allow the MG to report state transitions when a termination is brought 
> in test and when it is returned to service. Whether the state transation 
> is triggerred by the MGC (i.e. using a modify command) or by the MG 
> (i.e. test activated via a local management interface) is irrelevant to 
> this issue. As this modification does not require any new method, I 
> believe that it could be included in the IG as a clarification to H.248 
> V2. A new service change reason might need to be registered (e.g. 918 
> "Term in Test").
>  
> 2) Need to remove the ability to change the Service State in two
> different competing ways. Beyond making the Service State read-only, 
> this indeed requires a new Method and might be differred to V3, 
> although, I think that there is value in removing competing options as 
> soon as possible.
>  
> Bruno
>  
>  
>  
> 
>     -----Message d'origine-----
>     De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>     Envoyé : mercredi 1 octobre 2003 19:44
>     À : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
>     Objet : RE: [Megaco] Service Change and Testing
> 
>     I have noticed this same discrepancy.  The problem is that the MGC
>     is allowed to set the ServiceStates parm utilizing a Modify command,
>     while the MG has no such capability (it must utilize
>     ServiceChange).  Therefore, there is no way for the MG to set the
>     term into the Test state.
>      
>     In the Annex F work at the most recent Q3 meeting, I raised the idea
>     of restricting the SI parm to being Read-only, and mandating that
>     state changes must utilize ServiceChange (in both directions).  This
>     would also require a new Method to set the term to Test.  The big
>     problem is that this is a change from the current function, and may
>     have to wait until V3 due to the parsing change with the Method
>     parm (unless there is wide acceptance to push this into earlier
>     versions...)
>      
>     This simplifies the termination state model by removing the ability
>     to change the parm in two different, competing ways.  It also
>     provides the MG the capability of setting the term into Test (which
>     I think has value and utility).
>      
>     Comments?
>      
>     Kevin
> 
>         -----Original Message-----
>         From: CHATRAS Bruno FTRD/DAC/ISS
>         [mailto:bruno.chatras@francetelecom.com]
>         Sent: Wednesday, October 01, 2003 1:06 PM
>         To: megaco@ietf.org
>         Subject: [Megaco] Service Change and Testing
> 
>         Hi,
>          
>         H.248 defines three values for the Termination State descriptor
>         ("in service", "out of service" and "test"). The ServiceChange
>         procedures allows the MG to notify the MGC when a termination is
>         about to be taken out of service (or is being returned to
>         service). It seems that there is not equivalent procedure when a
>         termination is about to be tested (i.e. termination state =
>         test) and is therefore not available for normal traffic. Is
>         there a specific reason for treating these two states
>         differently or is just that the wording "out of service" in the
>         ServiceChange description encompasses both the "test" and "out
>         of service" termination states. If this is the case, I think a
>         clarification in the IG guide might be useful.
>          
>         Regards,
>         BC


_______________________________________________
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-admin@ietf.org  Fri Dec 12 11:20:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14743
	for <megaco-archive@lists.ietf.org>; Fri, 12 Dec 2003 11:20:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUq1L-0001S8-7V; Fri, 12 Dec 2003 11:20:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUq0V-0001R9-Oq
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 11:19:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14705
	for <megaco@ietf.org>; Fri, 12 Dec 2003 11:19:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUq0U-0000R1-00
	for megaco@ietf.org; Fri, 12 Dec 2003 11:19:10 -0500
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUq0T-0000Qy-00
	for megaco@ietf.org; Fri, 12 Dec 2003 11:19:09 -0500
Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Fri, 12 Dec 2003 17:18:57 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C0CB.A3752E98"
Subject: RE : RE : RE : [Megaco] Service Change and Testing
Date: Fri, 12 Dec 2003 17:18:54 +0100
Message-ID: <869954804BD53B41AF69F225F15FC331AA9A7E@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: RE : RE : [Megaco] Service Change and Testing
Thread-Index: AcPAyWTcEuIf680GQbG7FkRTIlUqXgAAVgeg
From: "CHATRAS Bruno FTRD/DAC/ISS" <bruno.chatras@francetelecom.com>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Christian Groves" <Christian.Groves@ericsson.com>
Cc: <megaco@ietf.org>
X-OriginalArrivalTime: 12 Dec 2003 16:18:57.0552 (UTC) FILETIME=[A4FE2900:01C3C0CB]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3C0CB.A3752E98
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I agree. Having the MGC aware of the reason why the terminaition is out =
of sevrice would be much better. Adding a new service change reason =
should not be a big issue.
=20
Actually metallic test access is exactly what I had in mind when I wrote =
"direct connection to specific devices".
=20
Bruno
=20
=20
-----Message d'origine-----
De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]=20
Envoy=E9 : vendredi 12 d=E9cembre 2003 17:03
=C0 : CHATRAS Bruno FTRD/DAC/ISS; Christian Groves
Cc : megaco@ietf.org
Objet : RE: RE : RE : [Megaco] Service Change and Testing



I believe that there is benefit to having the MGC aware that the reason =
that the term is OOS is because it is undergoing test.  Given that the =
MGC and MG may be in very different physical locations, the personnel at =
the MGC site may not have immediate knowledge of what is going on at the =
remote MG location.  Denoting that a particular termination is OOS tends =
to cause concern if the term should otherwise be inservice.  However, =
having that term in a test state shows that there isn't necessarily =
anything wrong at the MG -- just that the term is being tested.

I believe the test state also applies to things like metallic test =
access -- not just test calls.=20

Kevin=20

-----Original Message-----=20
From: CHATRAS Bruno FTRD/DAC/ISS =
[mailto:bruno.chatras@francetelecom.com]=20
Sent: Friday, December 12, 2003 4:24 AM=20
To: Christian Groves; Boyle, Kevin [NCRTP:3Z40:EXCH]=20
Cc: megaco@ietf.org=20
Subject: RE : RE : [Megaco] Service Change and Testing=20

Hello Christian,=20

Testing : What I'm really looking for is a solution that ensures that if =
a local operator starts testing a termination, the MG notifies the MGC =
that this termination cannot be used for normal traffic. The type of =
test I have in mind is not a test call, but the direct connection of =
specific devices to check the physical properties (e.g.; resistance, =
strand insulation)of the copper line. I agree that in such cases, we may =
use "out of service" instead of "test". However, if this is the =
agreement, I believe that explanatory text would need to be added to the =
IG to limit the scope of the "test" state to the case of test calls.

TISPAN : I did not thought about submitting the TISPAN profiles to Q3 at =
this stage. However, this might be a good opportunity to get comments =
from a wider audience.

Bruno=20



-----Message d'origine-----=20
De : Christian Groves [mailto:Christian.Groves@ericsson.com]=20
Envoy=E9 : vendredi 12 d=E9cembre 2003 00:12 =C0 : CHATRAS Bruno =
FTRD/DAC/ISS; Kevin Boyle Cc : megaco@ietf.org Objet : Re: RE : [Megaco] =
Service Change and Testing


Hello Bruno and Kevin,=20

I think there is/was some confusion over what "test state" is. I believe =
when it=20
was added to the protocol it was for the situation of test calls. The =
MGC=20
ordered these test calls thus there was no reason to have the MG =
indicate this=20
through a Servicechange. In "test state" there is no restriction on what =
the MGC=20
can do with the termination.=20

It seems that people may be using "test state" for more than the example =
above.=20
If we add a ServiceChange reason for test state then we'll have 2 =
methods of=20
changing the state.=20

With respect to having multiple ways of changing state to =
"out-of-service" this=20
is unfortunate and I agree can be looked at but whatever solution is =
proposed=20
should ensure backwards compatibility. There's not a problem changing=20
"out-of-service" to "in-service" because the MGC can't ADD/MOD those =
terminations.=20

Bruno: Will you be sending the Tispan: Residential/Access Gateway =
Profile Gate Control Profile to Q.3 and Megaco for info/review? People =
may be interested=20

in these.=20

Regards, Christian=20

CHATRAS Bruno FTRD/DAC/ISS wrote:=20

> Hello,=20
> =20
> As we are getting close to the next Q3 meeting, I'd like to come kack=20
> on=20
> this discussion about Sevrice Change and Testing.=20
> =20
> Actually, there seems to be two issues :=20
> =20
> 1) Need to modify the description of the Service Change procedure to=20
> allow the MG to report state transitions when a termination is brought =

> in test and when it is returned to service. Whether the state =
transation=20
> is triggerred by the MGC (i.e. using a modify command) or by the MG=20
> (i.e. test activated via a local management interface) is irrelevant =
to=20
> this issue. As this modification does not require any new method, I=20
> believe that it could be included in the IG as a clarification to =
H.248=20
> V2. A new service change reason might need to be registered (e.g. 918=20
> "Term in Test").=20
> =20
> 2) Need to remove the ability to change the Service State in two=20
> different competing ways. Beyond making the Service State read-only,=20
> this indeed requires a new Method and might be differred to V3,=20
> although, I think that there is value in removing competing options as =

> soon as possible.=20
> =20
> Bruno=20
> =20
> =20
> =20
>=20
>     -----Message d'origine-----=20
>     De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]=20
>     Envoy=E9 : mercredi 1 octobre 2003 19:44=20
>     =C0 : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org=20
>     Objet : RE: [Megaco] Service Change and Testing=20
>=20
>     I have noticed this same discrepancy.  The problem is that the MGC =

>     is allowed to set the ServiceStates parm utilizing a Modify =
command,=20
>     while the MG has no such capability (it must utilize=20
>     ServiceChange).  Therefore, there is no way for the MG to set the=20
>     term into the Test state.=20
>     =20
>     In the Annex F work at the most recent Q3 meeting, I raised the =
idea=20
>     of restricting the SI parm to being Read-only, and mandating that=20
>     state changes must utilize ServiceChange (in both directions).  =
This=20
>     would also require a new Method to set the term to Test.  The big=20
>     problem is that this is a change from the current function, and =
may=20
>     have to wait until V3 due to the parsing change with the Method=20
>     parm (unless there is wide acceptance to push this into earlier=20
>     versions...)=20
>     =20
>     This simplifies the termination state model by removing the =
ability=20
>     to change the parm in two different, competing ways.  It also=20
>     provides the MG the capability of setting the term into Test =
(which=20
>     I think has value and utility).=20
>     =20
>     Comments?=20
>     =20
>     Kevin=20
>=20
>         -----Original Message-----=20
>         From: CHATRAS Bruno FTRD/DAC/ISS=20
>         [mailto:bruno.chatras@francetelecom.com]=20
>         Sent: Wednesday, October 01, 2003 1:06 PM=20
>         To: megaco@ietf.org=20
>         Subject: [Megaco] Service Change and Testing=20
>=20
>         Hi,=20
>         =20
>         H.248 defines three values for the Termination State =
descriptor=20
>         ("in service", "out of service" and "test"). The ServiceChange =

>         procedures allows the MG to notify the MGC when a termination =
is=20
>         about to be taken out of service (or is being returned to=20
>         service). It seems that there is not equivalent procedure when =
a=20
>         termination is about to be tested (i.e. termination state =3D=20
>         test) and is therefore not available for normal traffic. Is=20
>         there a specific reason for treating these two states=20
>         differently or is just that the wording "out of service" in =
the=20
>         ServiceChange description encompasses both the "test" and "out =

>         of service" termination states. If this is the case, I think a =

>         clarification in the IG guide might be useful.=20
>         =20
>         Regards,=20
>         BC=20


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


------_=_NextPart_001_01C3C0CB.A3752E98
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4728.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
agree. Having the MGC aware of the reason why the terminaition is out of =
sevrice=20
would be much better. Adding a new service change reason should not be a =
big=20
issue.</FONT></SPAN></DIV>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Actually metallic test access is exactly what I had in mind =
when I wrote=20
"direct connection to specific devices".</FONT></SPAN></DIV>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Bruno</FONT></SPAN></DIV>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV></DIV>
<DIV><FONT face=3DTahoma size=3D2>-----Message =
d'origine-----<BR><B>De&nbsp;:</B>=20
Kevin Boyle [mailto:kboyle@nortelnetworks.com] =
<BR><B>Envoy=E9&nbsp;:</B> vendredi=20
12 d=E9cembre 2003 17:03<BR><B>=C0&nbsp;:</B> CHATRAS Bruno =
FTRD/DAC/ISS; Christian=20
Groves<BR><B>Cc&nbsp;:</B> megaco@ietf.org<BR><B>Objet&nbsp;:</B> RE: RE =
: RE :=20
[Megaco] Service Change and Testing<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <P><FONT size=3D2>I believe that there is benefit to having the MGC =
aware that=20
  the reason that the term is OOS is because it is undergoing =
test.&nbsp; Given=20
  that the MGC and MG may be in very different physical locations, the =
personnel=20
  at the MGC site may not have immediate knowledge of what is going on =
at the=20
  remote MG location.&nbsp; Denoting that a particular termination is =
OOS tends=20
  to cause concern if the term should otherwise be inservice.&nbsp; =
However,=20
  having that term in a test state shows that there isn't necessarily =
anything=20
  wrong at the MG -- just that the term is being tested.</FONT></P>
  <P><FONT size=3D2>I believe the test state also applies to things like =
metallic=20
  test access -- not just test calls.</FONT> </P>
  <P><FONT size=3D2>Kevin</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  CHATRAS Bruno FTRD/DAC/ISS [<A=20
  =
href=3D"mailto:bruno.chatras@francetelecom.com">mailto:bruno.chatras@fran=
cetelecom.com</A>]=20
  </FONT><BR><FONT size=3D2>Sent: Friday, December 12, 2003 4:24 =
AM</FONT>=20
  <BR><FONT size=3D2>To: Christian Groves; Boyle, Kevin =
[NCRTP:3Z40:EXCH]</FONT>=20
  <BR><FONT size=3D2>Cc: megaco@ietf.org</FONT> <BR><FONT =
size=3D2>Subject: RE : RE=20
  : [Megaco] Service Change and Testing</FONT> </P>
  <P><FONT size=3D2>Hello Christian,</FONT> </P>
  <P><FONT size=3D2>Testing : What I'm really looking for is a solution =
that=20
  ensures that if a local operator starts testing a termination, the MG =
notifies=20
  the MGC that this termination cannot be used for normal traffic. The =
type of=20
  test I have in mind is not a test call, but the direct connection of =
specific=20
  devices to check the physical properties (e.g.; resistance, strand=20
  insulation)of the copper line. I agree that in such cases, we may use =
"out of=20
  service" instead of "test". However, if this is the agreement, I =
believe that=20
  explanatory text would need to be added to the IG to limit the scope =
of the=20
  "test" state to the case of test calls.</FONT></P>
  <P><FONT size=3D2>TISPAN : I did not thought about submitting the =
TISPAN=20
  profiles to Q3 at this stage. However, this might be a good =
opportunity to get=20
  comments from a wider audience.</FONT></P>
  <P><FONT size=3D2>Bruno</FONT> </P><BR><BR>
  <P><FONT size=3D2>-----Message d'origine-----</FONT> <BR><FONT =
size=3D2>De :=20
  Christian Groves [<A=20
  =
href=3D"mailto:Christian.Groves@ericsson.com">mailto:Christian.Groves@eri=
csson.com</A>]</FONT>=20
  <BR><FONT size=3D2>Envoy=E9 : vendredi 12 d=E9cembre 2003 00:12 =C0 : =
CHATRAS Bruno=20
  FTRD/DAC/ISS; Kevin Boyle Cc : megaco@ietf.org Objet : Re: RE : =
[Megaco]=20
  Service Change and Testing</FONT></P><BR>
  <P><FONT size=3D2>Hello Bruno and Kevin,</FONT> </P>
  <P><FONT size=3D2>I think there is/was some confusion over what "test =
state" is.=20
  I believe when it </FONT><BR><FONT size=3D2>was added to the protocol =
it was for=20
  the situation of test calls. The MGC </FONT><BR><FONT size=3D2>ordered =
these=20
  test calls thus there was no reason to have the MG indicate this=20
  </FONT><BR><FONT size=3D2>through a Servicechange. In "test state" =
there is no=20
  restriction on what the MGC </FONT><BR><FONT size=3D2>can do with the=20
  termination.</FONT> </P>
  <P><FONT size=3D2>It seems that people may be using "test state" for =
more than=20
  the example above. </FONT><BR><FONT size=3D2>If we add a ServiceChange =
reason=20
  for test state then we'll have 2 methods of </FONT><BR><FONT =
size=3D2>changing=20
  the state.</FONT> </P>
  <P><FONT size=3D2>With respect to having multiple ways of changing =
state to=20
  "out-of-service" this </FONT><BR><FONT size=3D2>is unfortunate and I =
agree can=20
  be looked at but whatever solution is proposed </FONT><BR><FONT =
size=3D2>should=20
  ensure backwards compatibility. There's not a problem changing=20
  </FONT><BR><FONT size=3D2>"out-of-service" to "in-service" because the =
MGC can't=20
  ADD/MOD those terminations.</FONT> </P>
  <P><FONT size=3D2>Bruno: Will you be sending the Tispan: =
Residential/Access=20
  Gateway Profile Gate Control Profile to Q.3 and Megaco for =
info/review? People=20
  may be interested </FONT></P>
  <P><FONT size=3D2>in these.</FONT> </P>
  <P><FONT size=3D2>Regards, Christian</FONT> </P>
  <P><FONT size=3D2>CHATRAS Bruno FTRD/DAC/ISS wrote:</FONT> </P>
  <P><FONT size=3D2>&gt; Hello,</FONT> <BR><FONT size=3D2>&gt;&nbsp;=20
  </FONT><BR><FONT size=3D2>&gt; As we are getting close to the next Q3 =
meeting,=20
  I'd like to come kack </FONT><BR><FONT size=3D2>&gt; on</FONT> =
<BR><FONT=20
  size=3D2>&gt; this discussion about Sevrice Change and Testing.</FONT> =
<BR><FONT=20
  size=3D2>&gt;&nbsp; </FONT><BR><FONT size=3D2>&gt; Actually, there =
seems to be two=20
  issues :</FONT> <BR><FONT size=3D2>&gt;&nbsp; </FONT><BR><FONT =
size=3D2>&gt; 1)=20
  Need to modify the description of the Service Change procedure =
to</FONT>=20
  <BR><FONT size=3D2>&gt; allow the MG to report state transitions when =
a=20
  termination is brought </FONT><BR><FONT size=3D2>&gt; in test and when =
it is=20
  returned to service. Whether the state transation </FONT><BR><FONT =
size=3D2>&gt;=20
  is triggerred by the MGC (i.e. using a modify command) or by the MG=20
  </FONT><BR><FONT size=3D2>&gt; (i.e. test activated via a local =
management=20
  interface) is irrelevant to </FONT><BR><FONT size=3D2>&gt; this issue. =
As this=20
  modification does not require any new method, I </FONT><BR><FONT =
size=3D2>&gt;=20
  believe that it could be included in the IG as a clarification to =
H.248=20
  </FONT><BR><FONT size=3D2>&gt; V2. A new service change reason might =
need to be=20
  registered (e.g. 918 </FONT><BR><FONT size=3D2>&gt; "Term in =
Test").</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp; </FONT><BR><FONT size=3D2>&gt; 2) Need =
to remove the=20
  ability to change the Service State in two</FONT> <BR><FONT =
size=3D2>&gt;=20
  different competing ways. Beyond making the Service State read-only,=20
  </FONT><BR><FONT size=3D2>&gt; this indeed requires a new Method and =
might be=20
  differred to V3, </FONT><BR><FONT size=3D2>&gt; although, I think that =
there is=20
  value in removing competing options as </FONT><BR><FONT size=3D2>&gt; =
soon as=20
  possible.</FONT> <BR><FONT size=3D2>&gt;&nbsp; </FONT><BR><FONT =
size=3D2>&gt;=20
  Bruno</FONT> <BR><FONT size=3D2>&gt;&nbsp; </FONT><BR><FONT =
size=3D2>&gt;&nbsp;=20
  </FONT><BR><FONT size=3D2>&gt;&nbsp; </FONT><BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; -----Message=20
  d'origine-----</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
De : Kevin=20
  Boyle [<A=20
  =
href=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.co=
m</A>]</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Envoy=E9 : mercredi 1 =
octobre 2003=20
  19:44</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =C0 : =
CHATRAS Bruno=20
  FTRD/DAC/ISS; megaco@ietf.org</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Objet : RE: [Megaco] Service =
Change and=20
  Testing</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; I have noticed this same=20
  discrepancy.&nbsp; The problem is that the MGC</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; is allowed to set the =
ServiceStates parm=20
  utilizing a Modify command,</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; while the MG has no such =
capability (it=20
  must utilize</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
  ServiceChange).&nbsp; Therefore, there is no way for the MG to set =
the</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; term into the Test =
state.</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT =

  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; In the Annex F work at the most =
recent Q3=20
  meeting, I raised the idea</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; of restricting the SI parm to =
being=20
  Read-only, and mandating that</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; state changes must utilize =
ServiceChange=20
  (in both directions).&nbsp; This</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; would also require a new Method =
to set the=20
  term to Test.&nbsp; The big</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; problem is that this is a change =
from the=20
  current function, and may</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
  have to wait until V3 due to the parsing change with the Method</FONT> =

  <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; parm (unless there is =
wide=20
  acceptance to push this into earlier</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; versions...)</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This simplifies the termination =
state=20
  model by removing the ability</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; to change the parm in two =
different,=20
  competing ways.&nbsp; It also</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; provides the MG the capability =
of setting=20
  the term into Test (which</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
  I think has value and utility).</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Comments?</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Kevin</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  -----Original Message-----</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: =
CHATRAS=20
  Bruno FTRD/DAC/ISS</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<A=20
  =
href=3D"mailto:bruno.chatras@francetelecom.com">mailto:bruno.chatras@fran=
cetelecom.com</A>]</FONT>=20
  <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sent:=20
  Wednesday, October 01, 2003 1:06 PM</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:=20
  megaco@ietf.org</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject: =
[Megaco]=20
  Service Change and Testing</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Hi,</FONT>=20
  <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  H.248 defines three values for the Termination State descriptor</FONT> =

  <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("in=20
  service", "out of service" and "test"). The ServiceChange</FONT> =
<BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
procedures allows=20
  the MG to notify the MGC when a termination is</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; about to =
be taken=20
  out of service (or is being returned to</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
service). It seems=20
  that there is not equivalent procedure when a</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
termination is=20
  about to be tested (i.e. termination state =3D</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; test) =
and is=20
  therefore not available for normal traffic. Is</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; there a =
specific=20
  reason for treating these two states</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
differently or is=20
  just that the wording "out of service" in the</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ServiceChange=20
  description encompasses both the "test" and "out</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of =
service"=20
  termination states. If this is the case, I think a</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
clarification in=20
  the IG guide might be useful.</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Regards,</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
BC</FONT> </P><BR>
  <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 target=3D_blank=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.=
org/mailman/listinfo/megaco</A></FONT>=20
  </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3C0CB.A3752E98--

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


From exim@www1.ietf.org  Fri Dec 12 11:20:37 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14761
	for <megaco-archive@odin.ietf.org>; Fri, 12 Dec 2003 11:20:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUq1P-0001TR-NY
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 11:20:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCGK6fb005659
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 11:20:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUq1N-0001T5-DW
	for megaco-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 11:20:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14726
	for <megaco-web-archive@ietf.org>; Fri, 12 Dec 2003 11:20:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUq1M-0000S5-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 11:20:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUq1L-0000S2-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 11:20:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUq1L-0001S8-7V; Fri, 12 Dec 2003 11:20:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUq0V-0001R9-Oq
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 11:19:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14705
	for <megaco@ietf.org>; Fri, 12 Dec 2003 11:19:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUq0U-0000R1-00
	for megaco@ietf.org; Fri, 12 Dec 2003 11:19:10 -0500
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUq0T-0000Qy-00
	for megaco@ietf.org; Fri, 12 Dec 2003 11:19:09 -0500
Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Fri, 12 Dec 2003 17:18:57 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C0CB.A3752E98"
Subject: RE : RE : RE : [Megaco] Service Change and Testing
Date: Fri, 12 Dec 2003 17:18:54 +0100
Message-ID: <869954804BD53B41AF69F225F15FC331AA9A7E@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: RE : RE : [Megaco] Service Change and Testing
Thread-Index: AcPAyWTcEuIf680GQbG7FkRTIlUqXgAAVgeg
From: "CHATRAS Bruno FTRD/DAC/ISS" <bruno.chatras@francetelecom.com>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Christian Groves" <Christian.Groves@ericsson.com>
Cc: <megaco@ietf.org>
X-OriginalArrivalTime: 12 Dec 2003 16:18:57.0552 (UTC) FILETIME=[A4FE2900:01C3C0CB]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3C0CB.A3752E98
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I agree. Having the MGC aware of the reason why the terminaition is out =
of sevrice would be much better. Adding a new service change reason =
should not be a big issue.
=20
Actually metallic test access is exactly what I had in mind when I wrote =
"direct connection to specific devices".
=20
Bruno
=20
=20
-----Message d'origine-----
De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]=20
Envoy=E9 : vendredi 12 d=E9cembre 2003 17:03
=C0 : CHATRAS Bruno FTRD/DAC/ISS; Christian Groves
Cc : megaco@ietf.org
Objet : RE: RE : RE : [Megaco] Service Change and Testing



I believe that there is benefit to having the MGC aware that the reason =
that the term is OOS is because it is undergoing test.  Given that the =
MGC and MG may be in very different physical locations, the personnel at =
the MGC site may not have immediate knowledge of what is going on at the =
remote MG location.  Denoting that a particular termination is OOS tends =
to cause concern if the term should otherwise be inservice.  However, =
having that term in a test state shows that there isn't necessarily =
anything wrong at the MG -- just that the term is being tested.

I believe the test state also applies to things like metallic test =
access -- not just test calls.=20

Kevin=20

-----Original Message-----=20
From: CHATRAS Bruno FTRD/DAC/ISS =
[mailto:bruno.chatras@francetelecom.com]=20
Sent: Friday, December 12, 2003 4:24 AM=20
To: Christian Groves; Boyle, Kevin [NCRTP:3Z40:EXCH]=20
Cc: megaco@ietf.org=20
Subject: RE : RE : [Megaco] Service Change and Testing=20

Hello Christian,=20

Testing : What I'm really looking for is a solution that ensures that if =
a local operator starts testing a termination, the MG notifies the MGC =
that this termination cannot be used for normal traffic. The type of =
test I have in mind is not a test call, but the direct connection of =
specific devices to check the physical properties (e.g.; resistance, =
strand insulation)of the copper line. I agree that in such cases, we may =
use "out of service" instead of "test". However, if this is the =
agreement, I believe that explanatory text would need to be added to the =
IG to limit the scope of the "test" state to the case of test calls.

TISPAN : I did not thought about submitting the TISPAN profiles to Q3 at =
this stage. However, this might be a good opportunity to get comments =
from a wider audience.

Bruno=20



-----Message d'origine-----=20
De : Christian Groves [mailto:Christian.Groves@ericsson.com]=20
Envoy=E9 : vendredi 12 d=E9cembre 2003 00:12 =C0 : CHATRAS Bruno =
FTRD/DAC/ISS; Kevin Boyle Cc : megaco@ietf.org Objet : Re: RE : [Megaco] =
Service Change and Testing


Hello Bruno and Kevin,=20

I think there is/was some confusion over what "test state" is. I believe =
when it=20
was added to the protocol it was for the situation of test calls. The =
MGC=20
ordered these test calls thus there was no reason to have the MG =
indicate this=20
through a Servicechange. In "test state" there is no restriction on what =
the MGC=20
can do with the termination.=20

It seems that people may be using "test state" for more than the example =
above.=20
If we add a ServiceChange reason for test state then we'll have 2 =
methods of=20
changing the state.=20

With respect to having multiple ways of changing state to =
"out-of-service" this=20
is unfortunate and I agree can be looked at but whatever solution is =
proposed=20
should ensure backwards compatibility. There's not a problem changing=20
"out-of-service" to "in-service" because the MGC can't ADD/MOD those =
terminations.=20

Bruno: Will you be sending the Tispan: Residential/Access Gateway =
Profile Gate Control Profile to Q.3 and Megaco for info/review? People =
may be interested=20

in these.=20

Regards, Christian=20

CHATRAS Bruno FTRD/DAC/ISS wrote:=20

> Hello,=20
> =20
> As we are getting close to the next Q3 meeting, I'd like to come kack=20
> on=20
> this discussion about Sevrice Change and Testing.=20
> =20
> Actually, there seems to be two issues :=20
> =20
> 1) Need to modify the description of the Service Change procedure to=20
> allow the MG to report state transitions when a termination is brought =

> in test and when it is returned to service. Whether the state =
transation=20
> is triggerred by the MGC (i.e. using a modify command) or by the MG=20
> (i.e. test activated via a local management interface) is irrelevant =
to=20
> this issue. As this modification does not require any new method, I=20
> believe that it could be included in the IG as a clarification to =
H.248=20
> V2. A new service change reason might need to be registered (e.g. 918=20
> "Term in Test").=20
> =20
> 2) Need to remove the ability to change the Service State in two=20
> different competing ways. Beyond making the Service State read-only,=20
> this indeed requires a new Method and might be differred to V3,=20
> although, I think that there is value in removing competing options as =

> soon as possible.=20
> =20
> Bruno=20
> =20
> =20
> =20
>=20
>     -----Message d'origine-----=20
>     De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]=20
>     Envoy=E9 : mercredi 1 octobre 2003 19:44=20
>     =C0 : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org=20
>     Objet : RE: [Megaco] Service Change and Testing=20
>=20
>     I have noticed this same discrepancy.  The problem is that the MGC =

>     is allowed to set the ServiceStates parm utilizing a Modify =
command,=20
>     while the MG has no such capability (it must utilize=20
>     ServiceChange).  Therefore, there is no way for the MG to set the=20
>     term into the Test state.=20
>     =20
>     In the Annex F work at the most recent Q3 meeting, I raised the =
idea=20
>     of restricting the SI parm to being Read-only, and mandating that=20
>     state changes must utilize ServiceChange (in both directions).  =
This=20
>     would also require a new Method to set the term to Test.  The big=20
>     problem is that this is a change from the current function, and =
may=20
>     have to wait until V3 due to the parsing change with the Method=20
>     parm (unless there is wide acceptance to push this into earlier=20
>     versions...)=20
>     =20
>     This simplifies the termination state model by removing the =
ability=20
>     to change the parm in two different, competing ways.  It also=20
>     provides the MG the capability of setting the term into Test =
(which=20
>     I think has value and utility).=20
>     =20
>     Comments?=20
>     =20
>     Kevin=20
>=20
>         -----Original Message-----=20
>         From: CHATRAS Bruno FTRD/DAC/ISS=20
>         [mailto:bruno.chatras@francetelecom.com]=20
>         Sent: Wednesday, October 01, 2003 1:06 PM=20
>         To: megaco@ietf.org=20
>         Subject: [Megaco] Service Change and Testing=20
>=20
>         Hi,=20
>         =20
>         H.248 defines three values for the Termination State =
descriptor=20
>         ("in service", "out of service" and "test"). The ServiceChange =

>         procedures allows the MG to notify the MGC when a termination =
is=20
>         about to be taken out of service (or is being returned to=20
>         service). It seems that there is not equivalent procedure when =
a=20
>         termination is about to be tested (i.e. termination state =3D=20
>         test) and is therefore not available for normal traffic. Is=20
>         there a specific reason for treating these two states=20
>         differently or is just that the wording "out of service" in =
the=20
>         ServiceChange description encompasses both the "test" and "out =

>         of service" termination states. If this is the case, I think a =

>         clarification in the IG guide might be useful.=20
>         =20
>         Regards,=20
>         BC=20


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


------_=_NextPart_001_01C3C0CB.A3752E98
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4728.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
agree. Having the MGC aware of the reason why the terminaition is out of =
sevrice=20
would be much better. Adding a new service change reason should not be a =
big=20
issue.</FONT></SPAN></DIV>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Actually metallic test access is exactly what I had in mind =
when I wrote=20
"direct connection to specific devices".</FONT></SPAN></DIV>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Bruno</FONT></SPAN></DIV>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D384281216-12122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV></DIV>
<DIV><FONT face=3DTahoma size=3D2>-----Message =
d'origine-----<BR><B>De&nbsp;:</B>=20
Kevin Boyle [mailto:kboyle@nortelnetworks.com] =
<BR><B>Envoy=E9&nbsp;:</B> vendredi=20
12 d=E9cembre 2003 17:03<BR><B>=C0&nbsp;:</B> CHATRAS Bruno =
FTRD/DAC/ISS; Christian=20
Groves<BR><B>Cc&nbsp;:</B> megaco@ietf.org<BR><B>Objet&nbsp;:</B> RE: RE =
: RE :=20
[Megaco] Service Change and Testing<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <P><FONT size=3D2>I believe that there is benefit to having the MGC =
aware that=20
  the reason that the term is OOS is because it is undergoing =
test.&nbsp; Given=20
  that the MGC and MG may be in very different physical locations, the =
personnel=20
  at the MGC site may not have immediate knowledge of what is going on =
at the=20
  remote MG location.&nbsp; Denoting that a particular termination is =
OOS tends=20
  to cause concern if the term should otherwise be inservice.&nbsp; =
However,=20
  having that term in a test state shows that there isn't necessarily =
anything=20
  wrong at the MG -- just that the term is being tested.</FONT></P>
  <P><FONT size=3D2>I believe the test state also applies to things like =
metallic=20
  test access -- not just test calls.</FONT> </P>
  <P><FONT size=3D2>Kevin</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  CHATRAS Bruno FTRD/DAC/ISS [<A=20
  =
href=3D"mailto:bruno.chatras@francetelecom.com">mailto:bruno.chatras@fran=
cetelecom.com</A>]=20
  </FONT><BR><FONT size=3D2>Sent: Friday, December 12, 2003 4:24 =
AM</FONT>=20
  <BR><FONT size=3D2>To: Christian Groves; Boyle, Kevin =
[NCRTP:3Z40:EXCH]</FONT>=20
  <BR><FONT size=3D2>Cc: megaco@ietf.org</FONT> <BR><FONT =
size=3D2>Subject: RE : RE=20
  : [Megaco] Service Change and Testing</FONT> </P>
  <P><FONT size=3D2>Hello Christian,</FONT> </P>
  <P><FONT size=3D2>Testing : What I'm really looking for is a solution =
that=20
  ensures that if a local operator starts testing a termination, the MG =
notifies=20
  the MGC that this termination cannot be used for normal traffic. The =
type of=20
  test I have in mind is not a test call, but the direct connection of =
specific=20
  devices to check the physical properties (e.g.; resistance, strand=20
  insulation)of the copper line. I agree that in such cases, we may use =
"out of=20
  service" instead of "test". However, if this is the agreement, I =
believe that=20
  explanatory text would need to be added to the IG to limit the scope =
of the=20
  "test" state to the case of test calls.</FONT></P>
  <P><FONT size=3D2>TISPAN : I did not thought about submitting the =
TISPAN=20
  profiles to Q3 at this stage. However, this might be a good =
opportunity to get=20
  comments from a wider audience.</FONT></P>
  <P><FONT size=3D2>Bruno</FONT> </P><BR><BR>
  <P><FONT size=3D2>-----Message d'origine-----</FONT> <BR><FONT =
size=3D2>De :=20
  Christian Groves [<A=20
  =
href=3D"mailto:Christian.Groves@ericsson.com">mailto:Christian.Groves@eri=
csson.com</A>]</FONT>=20
  <BR><FONT size=3D2>Envoy=E9 : vendredi 12 d=E9cembre 2003 00:12 =C0 : =
CHATRAS Bruno=20
  FTRD/DAC/ISS; Kevin Boyle Cc : megaco@ietf.org Objet : Re: RE : =
[Megaco]=20
  Service Change and Testing</FONT></P><BR>
  <P><FONT size=3D2>Hello Bruno and Kevin,</FONT> </P>
  <P><FONT size=3D2>I think there is/was some confusion over what "test =
state" is.=20
  I believe when it </FONT><BR><FONT size=3D2>was added to the protocol =
it was for=20
  the situation of test calls. The MGC </FONT><BR><FONT size=3D2>ordered =
these=20
  test calls thus there was no reason to have the MG indicate this=20
  </FONT><BR><FONT size=3D2>through a Servicechange. In "test state" =
there is no=20
  restriction on what the MGC </FONT><BR><FONT size=3D2>can do with the=20
  termination.</FONT> </P>
  <P><FONT size=3D2>It seems that people may be using "test state" for =
more than=20
  the example above. </FONT><BR><FONT size=3D2>If we add a ServiceChange =
reason=20
  for test state then we'll have 2 methods of </FONT><BR><FONT =
size=3D2>changing=20
  the state.</FONT> </P>
  <P><FONT size=3D2>With respect to having multiple ways of changing =
state to=20
  "out-of-service" this </FONT><BR><FONT size=3D2>is unfortunate and I =
agree can=20
  be looked at but whatever solution is proposed </FONT><BR><FONT =
size=3D2>should=20
  ensure backwards compatibility. There's not a problem changing=20
  </FONT><BR><FONT size=3D2>"out-of-service" to "in-service" because the =
MGC can't=20
  ADD/MOD those terminations.</FONT> </P>
  <P><FONT size=3D2>Bruno: Will you be sending the Tispan: =
Residential/Access=20
  Gateway Profile Gate Control Profile to Q.3 and Megaco for =
info/review? People=20
  may be interested </FONT></P>
  <P><FONT size=3D2>in these.</FONT> </P>
  <P><FONT size=3D2>Regards, Christian</FONT> </P>
  <P><FONT size=3D2>CHATRAS Bruno FTRD/DAC/ISS wrote:</FONT> </P>
  <P><FONT size=3D2>&gt; Hello,</FONT> <BR><FONT size=3D2>&gt;&nbsp;=20
  </FONT><BR><FONT size=3D2>&gt; As we are getting close to the next Q3 =
meeting,=20
  I'd like to come kack </FONT><BR><FONT size=3D2>&gt; on</FONT> =
<BR><FONT=20
  size=3D2>&gt; this discussion about Sevrice Change and Testing.</FONT> =
<BR><FONT=20
  size=3D2>&gt;&nbsp; </FONT><BR><FONT size=3D2>&gt; Actually, there =
seems to be two=20
  issues :</FONT> <BR><FONT size=3D2>&gt;&nbsp; </FONT><BR><FONT =
size=3D2>&gt; 1)=20
  Need to modify the description of the Service Change procedure =
to</FONT>=20
  <BR><FONT size=3D2>&gt; allow the MG to report state transitions when =
a=20
  termination is brought </FONT><BR><FONT size=3D2>&gt; in test and when =
it is=20
  returned to service. Whether the state transation </FONT><BR><FONT =
size=3D2>&gt;=20
  is triggerred by the MGC (i.e. using a modify command) or by the MG=20
  </FONT><BR><FONT size=3D2>&gt; (i.e. test activated via a local =
management=20
  interface) is irrelevant to </FONT><BR><FONT size=3D2>&gt; this issue. =
As this=20
  modification does not require any new method, I </FONT><BR><FONT =
size=3D2>&gt;=20
  believe that it could be included in the IG as a clarification to =
H.248=20
  </FONT><BR><FONT size=3D2>&gt; V2. A new service change reason might =
need to be=20
  registered (e.g. 918 </FONT><BR><FONT size=3D2>&gt; "Term in =
Test").</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp; </FONT><BR><FONT size=3D2>&gt; 2) Need =
to remove the=20
  ability to change the Service State in two</FONT> <BR><FONT =
size=3D2>&gt;=20
  different competing ways. Beyond making the Service State read-only,=20
  </FONT><BR><FONT size=3D2>&gt; this indeed requires a new Method and =
might be=20
  differred to V3, </FONT><BR><FONT size=3D2>&gt; although, I think that =
there is=20
  value in removing competing options as </FONT><BR><FONT size=3D2>&gt; =
soon as=20
  possible.</FONT> <BR><FONT size=3D2>&gt;&nbsp; </FONT><BR><FONT =
size=3D2>&gt;=20
  Bruno</FONT> <BR><FONT size=3D2>&gt;&nbsp; </FONT><BR><FONT =
size=3D2>&gt;&nbsp;=20
  </FONT><BR><FONT size=3D2>&gt;&nbsp; </FONT><BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; -----Message=20
  d'origine-----</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
De : Kevin=20
  Boyle [<A=20
  =
href=3D"mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.co=
m</A>]</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Envoy=E9 : mercredi 1 =
octobre 2003=20
  19:44</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =C0 : =
CHATRAS Bruno=20
  FTRD/DAC/ISS; megaco@ietf.org</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Objet : RE: [Megaco] Service =
Change and=20
  Testing</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; I have noticed this same=20
  discrepancy.&nbsp; The problem is that the MGC</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; is allowed to set the =
ServiceStates parm=20
  utilizing a Modify command,</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; while the MG has no such =
capability (it=20
  must utilize</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
  ServiceChange).&nbsp; Therefore, there is no way for the MG to set =
the</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; term into the Test =
state.</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT =

  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; In the Annex F work at the most =
recent Q3=20
  meeting, I raised the idea</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; of restricting the SI parm to =
being=20
  Read-only, and mandating that</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; state changes must utilize =
ServiceChange=20
  (in both directions).&nbsp; This</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; would also require a new Method =
to set the=20
  term to Test.&nbsp; The big</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; problem is that this is a change =
from the=20
  current function, and may</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
  have to wait until V3 due to the parsing change with the Method</FONT> =

  <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; parm (unless there is =
wide=20
  acceptance to push this into earlier</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; versions...)</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This simplifies the termination =
state=20
  model by removing the ability</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; to change the parm in two =
different,=20
  competing ways.&nbsp; It also</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; provides the MG the capability =
of setting=20
  the term into Test (which</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
  I think has value and utility).</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Comments?</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Kevin</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  -----Original Message-----</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: =
CHATRAS=20
  Bruno FTRD/DAC/ISS</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<A=20
  =
href=3D"mailto:bruno.chatras@francetelecom.com">mailto:bruno.chatras@fran=
cetelecom.com</A>]</FONT>=20
  <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sent:=20
  Wednesday, October 01, 2003 1:06 PM</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:=20
  megaco@ietf.org</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject: =
[Megaco]=20
  Service Change and Testing</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Hi,</FONT>=20
  <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  H.248 defines three values for the Termination State descriptor</FONT> =

  <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ("in=20
  service", "out of service" and "test"). The ServiceChange</FONT> =
<BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
procedures allows=20
  the MG to notify the MGC when a termination is</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; about to =
be taken=20
  out of service (or is being returned to</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
service). It seems=20
  that there is not equivalent procedure when a</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
termination is=20
  about to be tested (i.e. termination state =3D</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; test) =
and is=20
  therefore not available for normal traffic. Is</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; there a =
specific=20
  reason for treating these two states</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
differently or is=20
  just that the wording "out of service" in the</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ServiceChange=20
  description encompasses both the "test" and "out</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of =
service"=20
  termination states. If this is the case, I think a</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
clarification in=20
  the IG guide might be useful.</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Regards,</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
BC</FONT> </P><BR>
  <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 target=3D_blank=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.=
org/mailman/listinfo/megaco</A></FONT>=20
  </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3C0CB.A3752E98--

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



From exim@www1.ietf.org  Fri Dec 12 11:52:26 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14131
	for <megaco-archive@odin.ietf.org>; Fri, 12 Dec 2003 11:04:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUpls-0000Px-FL
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 11:04:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCG446v001599
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 11:04:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUpls-0000Pa-BB
	for megaco-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 11:04:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14068
	for <megaco-web-archive@ietf.org>; Fri, 12 Dec 2003 11:03:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUplp-00002z-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 11:04:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUplo-00002v-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 11:04:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUplp-0000OD-O7; Fri, 12 Dec 2003 11:04:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUpl4-0000NU-3P
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 11:03:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14009
	for <megaco@ietf.org>; Fri, 12 Dec 2003 11:03:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUpl1-00001D-00
	for megaco@ietf.org; Fri, 12 Dec 2003 11:03:11 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUpl0-0007nh-00
	for megaco@ietf.org; Fri, 12 Dec 2003 11:03:10 -0500
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 hBCG2ct26449
	for <megaco@ietf.org>; Fri, 12 Dec 2003 11:02:38 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1ZFXG>; Fri, 12 Dec 2003 11:02:38 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D2B3BF2@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Christian Groves <Christian.Groves@ericsson.com>,
        CHATRAS Bruno FTRD/DAC/ISS <bruno.chatras@francetelecom.com>
Cc: megaco@ietf.org
Subject: RE: RE : [Megaco] Service Change and Testing
Date: Fri, 12 Dec 2003 11:02:37 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Only Add and Move are prohibited by ServiceState.  Modifies of OOS terms are
allowed -- although some actions undertaken through a modify may not make
sense.

I agree that we should not have two methods to change the state -- hence the
suggestion that the ServiceStates property be made ReadOnly.  That way the
only way to modify the ServiceState of the termination will be via
ServiceChange.

Kevin

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com] 
Sent: Thursday, December 11, 2003 6:12 PM
To: CHATRAS Bruno FTRD/DAC/ISS; Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: Re: RE : [Megaco] Service Change and Testing

Hello Bruno and Kevin,

I think there is/was some confusion over what "test state" is. I believe
when it was added to the protocol it was for the situation of test calls.
The MGC ordered these test calls thus there was no reason to have the MG
indicate this through a Servicechange. In "test state" there is no
restriction on what the MGC can do with the termination.

It seems that people may be using "test state" for more than the example
above. 
If we add a ServiceChange reason for test state then we'll have 2 methods of
changing the state.

With respect to having multiple ways of changing state to "out-of-service"
this is unfortunate and I agree can be looked at but whatever solution is
proposed should ensure backwards compatibility. There's not a problem
changing "out-of-service" to "in-service" because the MGC can't ADD/MOD
those terminations.

Bruno: Will you be sending the Tispan: Residential/Access Gateway Profile
Gate Control Profile to Q.3 and Megaco for info/review? People may be
interested in these.

Regards, Christian

CHATRAS Bruno FTRD/DAC/ISS wrote:

> Hello,
>  
> As we are getting close to the next Q3 meeting, I'd like to come kack 
> on this discussion about Sevrice Change and Testing.
>  
> Actually, there seems to be two issues :
>  
> 1) Need to modify the description of the Service Change procedure to 
> allow the MG to report state transitions when a termination is brought 
> in test and when it is returned to service. Whether the state 
> transation is triggerred by the MGC (i.e. using a modify command) or 
> by the MG (i.e. test activated via a local management interface) is 
> irrelevant to this issue. As this modification does not require any 
> new method, I believe that it could be included in the IG as a 
> clarification to H.248 V2. A new service change reason might need to 
> be registered (e.g. 918 "Term in Test").
>  
> 2) Need to remove the ability to change the Service State in two 
> different competing ways. Beyond making the Service State read-only, 
> this indeed requires a new Method and might be differred to V3, 
> although, I think that there is value in removing competing options as 
> soon as possible.
>  
> Bruno
>  
>  
>  
> 
>     -----Message d'origine-----
>     De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>     Envoyé : mercredi 1 octobre 2003 19:44
>     À : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
>     Objet : RE: [Megaco] Service Change and Testing
> 
>     I have noticed this same discrepancy.  The problem is that the MGC
>     is allowed to set the ServiceStates parm utilizing a Modify command,
>     while the MG has no such capability (it must utilize
>     ServiceChange).  Therefore, there is no way for the MG to set the
>     term into the Test state.
>      
>     In the Annex F work at the most recent Q3 meeting, I raised the idea
>     of restricting the SI parm to being Read-only, and mandating that
>     state changes must utilize ServiceChange (in both directions).  This
>     would also require a new Method to set the term to Test.  The big
>     problem is that this is a change from the current function, and may
>     have to wait until V3 due to the parsing change with the Method
>     parm (unless there is wide acceptance to push this into earlier
>     versions...)
>      
>     This simplifies the termination state model by removing the ability
>     to change the parm in two different, competing ways.  It also
>     provides the MG the capability of setting the term into Test (which
>     I think has value and utility).
>      
>     Comments?
>      
>     Kevin
> 
>         -----Original Message-----
>         From: CHATRAS Bruno FTRD/DAC/ISS
>         [mailto:bruno.chatras@francetelecom.com]
>         Sent: Wednesday, October 01, 2003 1:06 PM
>         To: megaco@ietf.org
>         Subject: [Megaco] Service Change and Testing
> 
>         Hi,
>          
>         H.248 defines three values for the Termination State descriptor
>         ("in service", "out of service" and "test"). The ServiceChange
>         procedures allows the MG to notify the MGC when a termination is
>         about to be taken out of service (or is being returned to
>         service). It seems that there is not equivalent procedure when a
>         termination is about to be tested (i.e. termination state =
>         test) and is therefore not available for normal traffic. Is
>         there a specific reason for treating these two states
>         differently or is just that the wording "out of service" in the
>         ServiceChange description encompasses both the "test" and "out
>         of service" termination states. If this is the case, I think a
>         clarification in the IG guide might be useful.
>          
>         Regards,
>         BC


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



From megaco-admin@ietf.org  Fri Dec 12 11:52:27 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14102
	for <megaco-archive@lists.ietf.org>; Fri, 12 Dec 2003 11:04:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUplq-0000ON-DJ; Fri, 12 Dec 2003 11:04:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUpl4-0000NV-CP
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 11:03:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14012
	for <megaco@ietf.org>; Fri, 12 Dec 2003 11:03:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUpl1-00001I-00
	for megaco@ietf.org; Fri, 12 Dec 2003 11:03:11 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUpl0-0007nk-00
	for megaco@ietf.org; Fri, 12 Dec 2003 11:03:10 -0500
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 hBCG2c904854
	for <megaco@ietf.org>; Fri, 12 Dec 2003 11:02:38 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y1ZFXH>; Fri, 12 Dec 2003 11:02:38 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D2B3BEF@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: CHATRAS Bruno FTRD/DAC/ISS <bruno.chatras@francetelecom.com>,
        Christian Groves <Christian.Groves@ericsson.com>
Cc: megaco@ietf.org
Subject: RE: RE : RE : [Megaco] Service Change and Testing
Date: Fri, 12 Dec 2003 11:02:36 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

I believe that there is benefit to having the MGC aware that the reason that
the term is OOS is because it is undergoing test.  Given that the MGC and MG
may be in very different physical locations, the personnel at the MGC site
may not have immediate knowledge of what is going on at the remote MG
location.  Denoting that a particular termination is OOS tends to cause
concern if the term should otherwise be inservice.  However, having that
term in a test state shows that there isn't necessarily anything wrong at
the MG -- just that the term is being tested.

I believe the test state also applies to things like metallic test access --
not just test calls.

Kevin

-----Original Message-----
From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] 
Sent: Friday, December 12, 2003 4:24 AM
To: Christian Groves; Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: RE : RE : [Megaco] Service Change and Testing

Hello Christian,

Testing : What I'm really looking for is a solution that ensures that if a
local operator starts testing a termination, the MG notifies the MGC that
this termination cannot be used for normal traffic. The type of test I have
in mind is not a test call, but the direct connection of specific devices to
check the physical properties (e.g.; resistance, strand insulation)of the
copper line. I agree that in such cases, we may use "out of service" instead
of "test". However, if this is the agreement, I believe that explanatory
text would need to be added to the IG to limit the scope of the "test" state
to the case of test calls.

TISPAN : I did not thought about submitting the TISPAN profiles to Q3 at
this stage. However, this might be a good opportunity to get comments from a
wider audience.

Bruno



-----Message d'origine-----
De : Christian Groves [mailto:Christian.Groves@ericsson.com]
Envoyé : vendredi 12 décembre 2003 00:12 À : CHATRAS Bruno FTRD/DAC/ISS;
Kevin Boyle Cc : megaco@ietf.org Objet : Re: RE : [Megaco] Service Change
and Testing


Hello Bruno and Kevin,

I think there is/was some confusion over what "test state" is. I believe
when it 
was added to the protocol it was for the situation of test calls. The MGC 
ordered these test calls thus there was no reason to have the MG indicate
this 
through a Servicechange. In "test state" there is no restriction on what the
MGC 
can do with the termination.

It seems that people may be using "test state" for more than the example
above. 
If we add a ServiceChange reason for test state then we'll have 2 methods of

changing the state.

With respect to having multiple ways of changing state to "out-of-service"
this 
is unfortunate and I agree can be looked at but whatever solution is
proposed 
should ensure backwards compatibility. There's not a problem changing 
"out-of-service" to "in-service" because the MGC can't ADD/MOD those
terminations.

Bruno: Will you be sending the Tispan: Residential/Access Gateway Profile
Gate Control Profile to Q.3 and Megaco for info/review? People may be
interested 
in these.

Regards, Christian

CHATRAS Bruno FTRD/DAC/ISS wrote:

> Hello,
>  
> As we are getting close to the next Q3 meeting, I'd like to come kack 
> on
> this discussion about Sevrice Change and Testing.
>  
> Actually, there seems to be two issues :
>  
> 1) Need to modify the description of the Service Change procedure to
> allow the MG to report state transitions when a termination is brought 
> in test and when it is returned to service. Whether the state transation 
> is triggerred by the MGC (i.e. using a modify command) or by the MG 
> (i.e. test activated via a local management interface) is irrelevant to 
> this issue. As this modification does not require any new method, I 
> believe that it could be included in the IG as a clarification to H.248 
> V2. A new service change reason might need to be registered (e.g. 918 
> "Term in Test").
>  
> 2) Need to remove the ability to change the Service State in two
> different competing ways. Beyond making the Service State read-only, 
> this indeed requires a new Method and might be differred to V3, 
> although, I think that there is value in removing competing options as 
> soon as possible.
>  
> Bruno
>  
>  
>  
> 
>     -----Message d'origine-----
>     De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>     Envoyé : mercredi 1 octobre 2003 19:44
>     À : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
>     Objet : RE: [Megaco] Service Change and Testing
> 
>     I have noticed this same discrepancy.  The problem is that the MGC
>     is allowed to set the ServiceStates parm utilizing a Modify command,
>     while the MG has no such capability (it must utilize
>     ServiceChange).  Therefore, there is no way for the MG to set the
>     term into the Test state.
>      
>     In the Annex F work at the most recent Q3 meeting, I raised the idea
>     of restricting the SI parm to being Read-only, and mandating that
>     state changes must utilize ServiceChange (in both directions).  This
>     would also require a new Method to set the term to Test.  The big
>     problem is that this is a change from the current function, and may
>     have to wait until V3 due to the parsing change with the Method
>     parm (unless there is wide acceptance to push this into earlier
>     versions...)
>      
>     This simplifies the termination state model by removing the ability
>     to change the parm in two different, competing ways.  It also
>     provides the MG the capability of setting the term into Test (which
>     I think has value and utility).
>      
>     Comments?
>      
>     Kevin
> 
>         -----Original Message-----
>         From: CHATRAS Bruno FTRD/DAC/ISS
>         [mailto:bruno.chatras@francetelecom.com]
>         Sent: Wednesday, October 01, 2003 1:06 PM
>         To: megaco@ietf.org
>         Subject: [Megaco] Service Change and Testing
> 
>         Hi,
>          
>         H.248 defines three values for the Termination State descriptor
>         ("in service", "out of service" and "test"). The ServiceChange
>         procedures allows the MG to notify the MGC when a termination is
>         about to be taken out of service (or is being returned to
>         service). It seems that there is not equivalent procedure when a
>         termination is about to be tested (i.e. termination state =
>         test) and is therefore not available for normal traffic. Is
>         there a specific reason for treating these two states
>         differently or is just that the wording "out of service" in the
>         ServiceChange description encompasses both the "test" and "out
>         of service" termination states. If this is the case, I think a
>         clarification in the IG guide might be useful.
>          
>         Regards,
>         BC


_______________________________________________
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-admin@ietf.org  Fri Dec 12 12:03:32 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16369
	for <megaco-archive@lists.ietf.org>; Fri, 12 Dec 2003 12:03:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUqgv-00046l-9V; Fri, 12 Dec 2003 12:03:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUqgO-00044E-Qt
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 12:02:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16347
	for <megaco@ietf.org>; Fri, 12 Dec 2003 12:02:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUqgN-0001RM-00
	for megaco@ietf.org; Fri, 12 Dec 2003 12:02:27 -0500
Received: from [202.41.97.50] (helo=u1.doe.ernet.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUqgL-0001R6-00
	for megaco@ietf.org; Fri, 12 Dec 2003 12:02:26 -0500
Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134])
	by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id hBCGtuSQ008940;
	Fri, 12 Dec 2003 22:25:57 +0530
Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0)
	id WAA01221; Fri, 12 Dec 2003 22:41:03 -0500 (GMT)
>Received: from cancer.cdotd.ernet.in by cdotd.cdotd.ernet.in (8.9.3+Sun/SMI-SVR4)
	id WAA05398; Fri, 12 Dec 2003 22:34:03 -0500 (GMT)
Received: from cdotd.ernet.in by cancer.cdotd.ernet.in (8.8.8/1.1.10.5/27Oct98-0333PM)
	id WAA26418; Fri, 12 Dec 2003 22:27:33 +0500 (GMT+0500)
Message-ID: <3FD9F2A0.591D178A@cdotd.ernet.in>
Date: Fri, 12 Dec 2003 22:23:53 +0530
From: manish rathi <rathi@cdotd.ernet.in>
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.11.00 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: CHATRAS Bruno FTRD/DAC/ISS 
 <bruno.chatras@francetelecom.com>,
        megaco@ietf.org
CC: Kevin Boyle <kboyle@nortelnetworks.com>,
        Christian Groves <Christian.Groves@ericsson.com>
Subject: Re: RE : RE : RE : [Megaco] Service Change and Testing
References: <869954804BD53B41AF69F225F15FC331AA9A7E@ftrdmel1.rd.francetelecom.fr>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

hi,
cd u tell me
1) whether this configuration works multiple servers (MGC) and one Media
gateway?
2) whether does physical wire terminate media gateway or MGC?



thanks
regards
Manish





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


From exim@www1.ietf.org  Fri Dec 12 12:03:37 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16384
	for <megaco-archive@odin.ietf.org>; Fri, 12 Dec 2003 12:03:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUqh0-00048F-Ue
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 12:03:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCH36IY015882
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 12:03:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUqh0-000485-O6
	for megaco-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 12:03:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16361
	for <megaco-web-archive@ietf.org>; Fri, 12 Dec 2003 12:03:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUqgz-0001Ry-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 12:03:05 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUqgy-0001Rv-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 12:03:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUqgv-00046l-9V; Fri, 12 Dec 2003 12:03:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUqgO-00044E-Qt
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 12:02:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16347
	for <megaco@ietf.org>; Fri, 12 Dec 2003 12:02:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUqgN-0001RM-00
	for megaco@ietf.org; Fri, 12 Dec 2003 12:02:27 -0500
Received: from [202.41.97.50] (helo=u1.doe.ernet.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUqgL-0001R6-00
	for megaco@ietf.org; Fri, 12 Dec 2003 12:02:26 -0500
Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134])
	by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id hBCGtuSQ008940;
	Fri, 12 Dec 2003 22:25:57 +0530
Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0)
	id WAA01221; Fri, 12 Dec 2003 22:41:03 -0500 (GMT)
>Received: from cancer.cdotd.ernet.in by cdotd.cdotd.ernet.in (8.9.3+Sun/SMI-SVR4)
	id WAA05398; Fri, 12 Dec 2003 22:34:03 -0500 (GMT)
Received: from cdotd.ernet.in by cancer.cdotd.ernet.in (8.8.8/1.1.10.5/27Oct98-0333PM)
	id WAA26418; Fri, 12 Dec 2003 22:27:33 +0500 (GMT+0500)
Message-ID: <3FD9F2A0.591D178A@cdotd.ernet.in>
Date: Fri, 12 Dec 2003 22:23:53 +0530
From: manish rathi <rathi@cdotd.ernet.in>
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.11.00 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: CHATRAS Bruno FTRD/DAC/ISS 
 <bruno.chatras@francetelecom.com>,
        megaco@ietf.org
CC: Kevin Boyle <kboyle@nortelnetworks.com>,
        Christian Groves <Christian.Groves@ericsson.com>
Subject: Re: RE : RE : RE : [Megaco] Service Change and Testing
References: <869954804BD53B41AF69F225F15FC331AA9A7E@ftrdmel1.rd.francetelecom.fr>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

hi,
cd u tell me
1) whether this configuration works multiple servers (MGC) and one Media
gateway?
2) whether does physical wire terminate media gateway or MGC?



thanks
regards
Manish





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



From megaco-admin@ietf.org  Fri Dec 12 12:28:29 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17501
	for <megaco-archive@lists.ietf.org>; Fri, 12 Dec 2003 12:28:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUr57-0005lK-TK; Fri, 12 Dec 2003 12:28:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUr4B-0005kA-Ce
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 12:27:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17453
	for <megaco@ietf.org>; Fri, 12 Dec 2003 12:26:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUr49-0002Az-00
	for megaco@ietf.org; Fri, 12 Dec 2003 12:27:01 -0500
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUr49-0002Aw-00
	for megaco@ietf.org; Fri, 12 Dec 2003 12:27:01 -0500
Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Fri, 12 Dec 2003 18:26:33 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE : RE : RE : RE : [Megaco] Service Change and Testing
Date: Fri, 12 Dec 2003 18:26:32 +0100
Message-ID: <869954804BD53B41AF69F225F15FC331AA9ADF@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: RE : RE : RE : [Megaco] Service Change and Testing
Thread-Index: AcPA0a9VSqzM9NyNRNWLYko7ggboOAAAma1g
From: "CHATRAS Bruno FTRD/DAC/ISS" <bruno.chatras@francetelecom.com>
To: "manish rathi" <rathi@cdotd.ernet.in>, <megaco@ietf.org>
Cc: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Christian Groves" <Christian.Groves@ericsson.com>
X-OriginalArrivalTime: 12 Dec 2003 17:26:33.0914 (UTC) FILETIME=[16C5E1A0:01C3C0D5]
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: quoted-printable

Physical wires terminate at the MG. The MG sends the Service Change to =
the MGC with which it has previously registered. There might be multiple =
MGCs involved in the configuration if the MG is partitioned into several =
virtuals MGs, each of which being registered with a different MGC.

Bruno

-----Message d'origine-----
De : manish rathi [mailto:rathi@cdotd.ernet.in]=20
Envoy=E9 : vendredi 12 d=E9cembre 2003 17:54
=C0 : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
Cc : Kevin Boyle; Christian Groves
Objet : Re: RE : RE : RE : [Megaco] Service Change and Testing


hi,
cd u tell me
1) whether this configuration works multiple servers (MGC) and one Media =
gateway?
2) whether does physical wire terminate media gateway or MGC?



thanks
regards
Manish





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


From exim@www1.ietf.org  Fri Dec 12 12:28:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17518
	for <megaco-archive@odin.ietf.org>; Fri, 12 Dec 2003 12:28:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUr59-0005mo-P7
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 12:28:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCHS3oB022208
	for megaco-archive@odin.ietf.org; Fri, 12 Dec 2003 12:28:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUr59-0005m7-Ik
	for megaco-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 12:28:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17481
	for <megaco-web-archive@ietf.org>; Fri, 12 Dec 2003 12:27:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUr57-0002Dk-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 12:28:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUr57-0002Dh-00
	for megaco-web-archive@ietf.org; Fri, 12 Dec 2003 12:28:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUr57-0005lK-TK; Fri, 12 Dec 2003 12:28:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUr4B-0005kA-Ce
	for megaco@optimus.ietf.org; Fri, 12 Dec 2003 12:27:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17453
	for <megaco@ietf.org>; Fri, 12 Dec 2003 12:26:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUr49-0002Az-00
	for megaco@ietf.org; Fri, 12 Dec 2003 12:27:01 -0500
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUr49-0002Aw-00
	for megaco@ietf.org; Fri, 12 Dec 2003 12:27:01 -0500
Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Fri, 12 Dec 2003 18:26:33 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE : RE : RE : RE : [Megaco] Service Change and Testing
Date: Fri, 12 Dec 2003 18:26:32 +0100
Message-ID: <869954804BD53B41AF69F225F15FC331AA9ADF@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: RE : RE : RE : [Megaco] Service Change and Testing
Thread-Index: AcPA0a9VSqzM9NyNRNWLYko7ggboOAAAma1g
From: "CHATRAS Bruno FTRD/DAC/ISS" <bruno.chatras@francetelecom.com>
To: "manish rathi" <rathi@cdotd.ernet.in>, <megaco@ietf.org>
Cc: "Kevin Boyle" <kboyle@nortelnetworks.com>,
        "Christian Groves" <Christian.Groves@ericsson.com>
X-OriginalArrivalTime: 12 Dec 2003 17:26:33.0914 (UTC) FILETIME=[16C5E1A0:01C3C0D5]
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Physical wires terminate at the MG. The MG sends the Service Change to =
the MGC with which it has previously registered. There might be multiple =
MGCs involved in the configuration if the MG is partitioned into several =
virtuals MGs, each of which being registered with a different MGC.

Bruno

-----Message d'origine-----
De : manish rathi [mailto:rathi@cdotd.ernet.in]=20
Envoy=E9 : vendredi 12 d=E9cembre 2003 17:54
=C0 : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
Cc : Kevin Boyle; Christian Groves
Objet : Re: RE : RE : RE : [Megaco] Service Change and Testing


hi,
cd u tell me
1) whether this configuration works multiple servers (MGC) and one Media =
gateway?
2) whether does physical wire terminate media gateway or MGC?



thanks
regards
Manish





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



From megaco-admin@ietf.org  Sun Dec 14 23:15:38 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08523
	for <megaco-archive@lists.ietf.org>; Sun, 14 Dec 2003 23:15:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVk8N-0007HJ-Iy; Sun, 14 Dec 2003 23:15:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVk83-0007Gl-K6
	for megaco@optimus.ietf.org; Sun, 14 Dec 2003 23:14:43 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08484
	for <megaco@ietf.org>; Sun, 14 Dec 2003 23:14:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVk81-0002G1-00
	for megaco@ietf.org; Sun, 14 Dec 2003 23:14:41 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVk7z-0002Fw-00
	for megaco@ietf.org; Sun, 14 Dec 2003 23:14:41 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBF0Qxv09685;
	Mon, 15 Dec 2003 11:27:00 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.189]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5LYST0; Mon, 15 Dec 2003 11:28:42 +1100
Message-ID: <3FDCFFCD.1000207@ericsson.com>
Date: Mon, 15 Dec 2003 11:26:53 +1100
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: Kevin Boyle <kboyle@nortelnetworks.com>
CC: CHATRAS Bruno FTRD/DAC/ISS <bruno.chatras@francetelecom.com>,
        megaco@ietf.org
Subject: Re: RE : RE : [Megaco] Service Change and Testing
References: <ABA227A15B80D511BD1A00508BF93A1C0D2B3BEF@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0D2B3BEF@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id hBF0Qxv09685
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: quoted-printable

Hello Kevin,

What will the MGC do with this test state information? It can't take any=20
maintenance action all it needs to know is if it can use a termination.

We already have:
5.2.6	Reason #: 905 Name: Termination taken out of service
Definition: This indicates that the entity indicated with the Termination=
ID is=20
in ServiceState "Out Of-Service" due to maintenance action.

I'm sure testing equates to a maintenance action. This should be enough t=
o make=20
the MGC people happy, they could be more concerned at "904 Termination=20
malfunctioning" so I don't think we need a new reason code.

With regards to Bruno's comment I think we could add something in Annex F=
 saying=20
that: MOD(test) is used for MGC initiated testing, State "Test" can be us=
ed=20
internally in the MG for terminations and is indicated to the MG via=20
ServiceChange(Graceful/Forced:reason 905). No new functionality needed an=
d how=20
it was designed to work. To further clear up confusion we could also clar=
ify=20
that MOD.req(Inservice) is used only change state from test to in-service=
 and=20
must not be used to put a termination out-of-service.

Regards, Christian

Kevin Boyle wrote:

> I believe that there is benefit to having the MGC aware that the reason=
=20
> that the term is OOS is because it is undergoing test.  Given that the=20
> MGC and MG may be in very different physical locations, the personnel a=
t=20
> the MGC site may not have immediate knowledge of what is going on at th=
e=20
> remote MG location.  Denoting that a particular termination is OOS tend=
s=20
> to cause concern if the term should otherwise be inservice.  However,=20
> having that term in a test state shows that there isn't necessarily=20
> anything wrong at the MG -- just that the term is being tested.
>=20
> I believe the test state also applies to things like metallic test=20
> access -- not just test calls.
>=20
> Kevin
>=20
> -----Original Message-----
> From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.co=
m]
> Sent: Friday, December 12, 2003 4:24 AM
> To: Christian Groves; Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: megaco@ietf.org
> Subject: RE : RE : [Megaco] Service Change and Testing
>=20
> Hello Christian,
>=20
> Testing : What I'm really looking for is a solution that ensures that i=
f=20
> a local operator starts testing a termination, the MG notifies the MGC=20
> that this termination cannot be used for normal traffic. The type of=20
> test I have in mind is not a test call, but the direct connection of=20
> specific devices to check the physical properties (e.g.; resistance,=20
> strand insulation)of the copper line. I agree that in such cases, we ma=
y=20
> use "out of service" instead of "test". However, if this is the=20
> agreement, I believe that explanatory text would need to be added to th=
e=20
> IG to limit the scope of the "test" state to the case of test calls.
>=20
> TISPAN : I did not thought about submitting the TISPAN profiles to Q3 a=
t=20
> this stage. However, this might be a good opportunity to get comments=20
> from a wider audience.
>=20
> Bruno
>=20
>=20
>=20
> -----Message d'origine-----
> De : Christian Groves [mailto:Christian.Groves@ericsson.com]
> Envoy=E9 : vendredi 12 d=E9cembre 2003 00:12 =C0 : CHATRAS Bruno FTRD/D=
AC/ISS;=20
> Kevin Boyle Cc : megaco@ietf.org Objet : Re: RE : [Megaco] Service=20
> Change and Testing
>=20
>=20
> Hello Bruno and Kevin,
>=20
> I think there is/was some confusion over what "test state" is. I believ=
e=20
> when it
> was added to the protocol it was for the situation of test calls. The M=
GC
> ordered these test calls thus there was no reason to have the MG=20
> indicate this
> through a Servicechange. In "test state" there is no restriction on wha=
t=20
> the MGC
> can do with the termination.
>=20
> It seems that people may be using "test state" for more than the exampl=
e=20
> above.
> If we add a ServiceChange reason for test state then we'll have 2=20
> methods of
> changing the state.
>=20
> With respect to having multiple ways of changing state to=20
> "out-of-service" this
> is unfortunate and I agree can be looked at but whatever solution is=20
> proposed
> should ensure backwards compatibility. There's not a problem changing
> "out-of-service" to "in-service" because the MGC can't ADD/MOD those=20
> terminations.
>=20
> Bruno: Will you be sending the Tispan: Residential/Access Gateway=20
> Profile Gate Control Profile to Q.3 and Megaco for info/review? People=20
> may be interested
>=20
> in these.
>=20
> Regards, Christian
>=20
> CHATRAS Bruno FTRD/DAC/ISS wrote:
>=20
>  > Hello,
>  >=20
>  > As we are getting close to the next Q3 meeting, I'd like to come kac=
k
>  > on
>  > this discussion about Sevrice Change and Testing.
>  >=20
>  > Actually, there seems to be two issues :
>  >=20
>  > 1) Need to modify the description of the Service Change procedure to
>  > allow the MG to report state transitions when a termination is broug=
ht
>  > in test and when it is returned to service. Whether the state transa=
tion
>  > is triggerred by the MGC (i.e. using a modify command) or by the MG
>  > (i.e. test activated via a local management interface) is irrelevant=
 to
>  > this issue. As this modification does not require any new method, I
>  > believe that it could be included in the IG as a clarification to H.=
248
>  > V2. A new service change reason might need to be registered (e.g. 91=
8
>  > "Term in Test").
>  >=20
>  > 2) Need to remove the ability to change the Service State in two
>  > different competing ways. Beyond making the Service State read-only,
>  > this indeed requires a new Method and might be differred to V3,
>  > although, I think that there is value in removing competing options =
as
>  > soon as possible.
>  >=20
>  > Bruno
>  >=20
>  >=20
>  >=20
>  >
>  >     -----Message d'origine-----
>  >     De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>  >     Envoy=E9 : mercredi 1 octobre 2003 19:44
>  >     =C0 : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
>  >     Objet : RE: [Megaco] Service Change and Testing
>  >
>  >     I have noticed this same discrepancy.  The problem is that the M=
GC
>  >     is allowed to set the ServiceStates parm utilizing a Modify comm=
and,
>  >     while the MG has no such capability (it must utilize
>  >     ServiceChange).  Therefore, there is no way for the MG to set th=
e
>  >     term into the Test state.
>  >    =20
>  >     In the Annex F work at the most recent Q3 meeting, I raised the =
idea
>  >     of restricting the SI parm to being Read-only, and mandating tha=
t
>  >     state changes must utilize ServiceChange (in both directions).  =
This
>  >     would also require a new Method to set the term to Test.  The bi=
g
>  >     problem is that this is a change from the current function, and =
may
>  >     have to wait until V3 due to the parsing change with the Method
>  >     parm (unless there is wide acceptance to push this into earlier
>  >     versions...)
>  >    =20
>  >     This simplifies the termination state model by removing the abil=
ity
>  >     to change the parm in two different, competing ways.  It also
>  >     provides the MG the capability of setting the term into Test (wh=
ich
>  >     I think has value and utility).
>  >    =20
>  >     Comments?
>  >    =20
>  >     Kevin
>  >
>  >         -----Original Message-----
>  >         From: CHATRAS Bruno FTRD/DAC/ISS
>  >         [mailto:bruno.chatras@francetelecom.com]
>  >         Sent: Wednesday, October 01, 2003 1:06 PM
>  >         To: megaco@ietf.org
>  >         Subject: [Megaco] Service Change and Testing
>  >
>  >         Hi,
>  >        =20
>  >         H.248 defines three values for the Termination State descrip=
tor
>  >         ("in service", "out of service" and "test"). The ServiceChan=
ge
>  >         procedures allows the MG to notify the MGC when a terminatio=
n is
>  >         about to be taken out of service (or is being returned to
>  >         service). It seems that there is not equivalent procedure wh=
en a
>  >         termination is about to be tested (i.e. termination state =3D
>  >         test) and is therefore not available for normal traffic. Is
>  >         there a specific reason for treating these two states
>  >         differently or is just that the wording "out of service" in =
the
>  >         ServiceChange description encompasses both the "test" and "o=
ut
>  >         of service" termination states. If this is the case, I think=
 a
>  >         clarification in the IG guide might be useful.
>  >        =20
>  >         Regards,
>  >         BC
>=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 exim@www1.ietf.org  Sun Dec 14 23:16:41 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08561
	for <megaco-archive@odin.ietf.org>; Sun, 14 Dec 2003 23:16:40 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVk9U-0007JC-EE
	for megaco-archive@odin.ietf.org; Sun, 14 Dec 2003 23:16:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBF4GC2l028088
	for megaco-archive@odin.ietf.org; Sun, 14 Dec 2003 23:16:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVk9U-0007It-2Z
	for megaco-web-archive@optimus.ietf.org; Sun, 14 Dec 2003 23:16:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08542
	for <megaco-web-archive@ietf.org>; Sun, 14 Dec 2003 23:16:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVk9M-0002GN-00
	for megaco-web-archive@ietf.org; Sun, 14 Dec 2003 23:16:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVk8x-0002G8-00
	for megaco-web-archive@ietf.org; Sun, 14 Dec 2003 23:15:39 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVk8N-0007HJ-Iy; Sun, 14 Dec 2003 23:15:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVk83-0007Gl-K6
	for megaco@optimus.ietf.org; Sun, 14 Dec 2003 23:14:43 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08484
	for <megaco@ietf.org>; Sun, 14 Dec 2003 23:14:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVk81-0002G1-00
	for megaco@ietf.org; Sun, 14 Dec 2003 23:14:41 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVk7z-0002Fw-00
	for megaco@ietf.org; Sun, 14 Dec 2003 23:14:41 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBF0Qxv09685;
	Mon, 15 Dec 2003 11:27:00 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.189]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5LYST0; Mon, 15 Dec 2003 11:28:42 +1100
Message-ID: <3FDCFFCD.1000207@ericsson.com>
Date: Mon, 15 Dec 2003 11:26:53 +1100
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: Kevin Boyle <kboyle@nortelnetworks.com>
CC: CHATRAS Bruno FTRD/DAC/ISS <bruno.chatras@francetelecom.com>,
        megaco@ietf.org
Subject: Re: RE : RE : [Megaco] Service Change and Testing
References: <ABA227A15B80D511BD1A00508BF93A1C0D2B3BEF@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0D2B3BEF@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ish7.ericsson.com.au id hBF0Qxv09685
Content-Transfer-Encoding: quoted-printable
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hello Kevin,

What will the MGC do with this test state information? It can't take any=20
maintenance action all it needs to know is if it can use a termination.

We already have:
5.2.6	Reason #: 905 Name: Termination taken out of service
Definition: This indicates that the entity indicated with the Termination=
ID is=20
in ServiceState "Out Of-Service" due to maintenance action.

I'm sure testing equates to a maintenance action. This should be enough t=
o make=20
the MGC people happy, they could be more concerned at "904 Termination=20
malfunctioning" so I don't think we need a new reason code.

With regards to Bruno's comment I think we could add something in Annex F=
 saying=20
that: MOD(test) is used for MGC initiated testing, State "Test" can be us=
ed=20
internally in the MG for terminations and is indicated to the MG via=20
ServiceChange(Graceful/Forced:reason 905). No new functionality needed an=
d how=20
it was designed to work. To further clear up confusion we could also clar=
ify=20
that MOD.req(Inservice) is used only change state from test to in-service=
 and=20
must not be used to put a termination out-of-service.

Regards, Christian

Kevin Boyle wrote:

> I believe that there is benefit to having the MGC aware that the reason=
=20
> that the term is OOS is because it is undergoing test.  Given that the=20
> MGC and MG may be in very different physical locations, the personnel a=
t=20
> the MGC site may not have immediate knowledge of what is going on at th=
e=20
> remote MG location.  Denoting that a particular termination is OOS tend=
s=20
> to cause concern if the term should otherwise be inservice.  However,=20
> having that term in a test state shows that there isn't necessarily=20
> anything wrong at the MG -- just that the term is being tested.
>=20
> I believe the test state also applies to things like metallic test=20
> access -- not just test calls.
>=20
> Kevin
>=20
> -----Original Message-----
> From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.co=
m]
> Sent: Friday, December 12, 2003 4:24 AM
> To: Christian Groves; Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: megaco@ietf.org
> Subject: RE : RE : [Megaco] Service Change and Testing
>=20
> Hello Christian,
>=20
> Testing : What I'm really looking for is a solution that ensures that i=
f=20
> a local operator starts testing a termination, the MG notifies the MGC=20
> that this termination cannot be used for normal traffic. The type of=20
> test I have in mind is not a test call, but the direct connection of=20
> specific devices to check the physical properties (e.g.; resistance,=20
> strand insulation)of the copper line. I agree that in such cases, we ma=
y=20
> use "out of service" instead of "test". However, if this is the=20
> agreement, I believe that explanatory text would need to be added to th=
e=20
> IG to limit the scope of the "test" state to the case of test calls.
>=20
> TISPAN : I did not thought about submitting the TISPAN profiles to Q3 a=
t=20
> this stage. However, this might be a good opportunity to get comments=20
> from a wider audience.
>=20
> Bruno
>=20
>=20
>=20
> -----Message d'origine-----
> De : Christian Groves [mailto:Christian.Groves@ericsson.com]
> Envoy=E9 : vendredi 12 d=E9cembre 2003 00:12 =C0 : CHATRAS Bruno FTRD/D=
AC/ISS;=20
> Kevin Boyle Cc : megaco@ietf.org Objet : Re: RE : [Megaco] Service=20
> Change and Testing
>=20
>=20
> Hello Bruno and Kevin,
>=20
> I think there is/was some confusion over what "test state" is. I believ=
e=20
> when it
> was added to the protocol it was for the situation of test calls. The M=
GC
> ordered these test calls thus there was no reason to have the MG=20
> indicate this
> through a Servicechange. In "test state" there is no restriction on wha=
t=20
> the MGC
> can do with the termination.
>=20
> It seems that people may be using "test state" for more than the exampl=
e=20
> above.
> If we add a ServiceChange reason for test state then we'll have 2=20
> methods of
> changing the state.
>=20
> With respect to having multiple ways of changing state to=20
> "out-of-service" this
> is unfortunate and I agree can be looked at but whatever solution is=20
> proposed
> should ensure backwards compatibility. There's not a problem changing
> "out-of-service" to "in-service" because the MGC can't ADD/MOD those=20
> terminations.
>=20
> Bruno: Will you be sending the Tispan: Residential/Access Gateway=20
> Profile Gate Control Profile to Q.3 and Megaco for info/review? People=20
> may be interested
>=20
> in these.
>=20
> Regards, Christian
>=20
> CHATRAS Bruno FTRD/DAC/ISS wrote:
>=20
>  > Hello,
>  >=20
>  > As we are getting close to the next Q3 meeting, I'd like to come kac=
k
>  > on
>  > this discussion about Sevrice Change and Testing.
>  >=20
>  > Actually, there seems to be two issues :
>  >=20
>  > 1) Need to modify the description of the Service Change procedure to
>  > allow the MG to report state transitions when a termination is broug=
ht
>  > in test and when it is returned to service. Whether the state transa=
tion
>  > is triggerred by the MGC (i.e. using a modify command) or by the MG
>  > (i.e. test activated via a local management interface) is irrelevant=
 to
>  > this issue. As this modification does not require any new method, I
>  > believe that it could be included in the IG as a clarification to H.=
248
>  > V2. A new service change reason might need to be registered (e.g. 91=
8
>  > "Term in Test").
>  >=20
>  > 2) Need to remove the ability to change the Service State in two
>  > different competing ways. Beyond making the Service State read-only,
>  > this indeed requires a new Method and might be differred to V3,
>  > although, I think that there is value in removing competing options =
as
>  > soon as possible.
>  >=20
>  > Bruno
>  >=20
>  >=20
>  >=20
>  >
>  >     -----Message d'origine-----
>  >     De : Kevin Boyle [mailto:kboyle@nortelnetworks.com]
>  >     Envoy=E9 : mercredi 1 octobre 2003 19:44
>  >     =C0 : CHATRAS Bruno FTRD/DAC/ISS; megaco@ietf.org
>  >     Objet : RE: [Megaco] Service Change and Testing
>  >
>  >     I have noticed this same discrepancy.  The problem is that the M=
GC
>  >     is allowed to set the ServiceStates parm utilizing a Modify comm=
and,
>  >     while the MG has no such capability (it must utilize
>  >     ServiceChange).  Therefore, there is no way for the MG to set th=
e
>  >     term into the Test state.
>  >    =20
>  >     In the Annex F work at the most recent Q3 meeting, I raised the =
idea
>  >     of restricting the SI parm to being Read-only, and mandating tha=
t
>  >     state changes must utilize ServiceChange (in both directions).  =
This
>  >     would also require a new Method to set the term to Test.  The bi=
g
>  >     problem is that this is a change from the current function, and =
may
>  >     have to wait until V3 due to the parsing change with the Method
>  >     parm (unless there is wide acceptance to push this into earlier
>  >     versions...)
>  >    =20
>  >     This simplifies the termination state model by removing the abil=
ity
>  >     to change the parm in two different, competing ways.  It also
>  >     provides the MG the capability of setting the term into Test (wh=
ich
>  >     I think has value and utility).
>  >    =20
>  >     Comments?
>  >    =20
>  >     Kevin
>  >
>  >         -----Original Message-----
>  >         From: CHATRAS Bruno FTRD/DAC/ISS
>  >         [mailto:bruno.chatras@francetelecom.com]
>  >         Sent: Wednesday, October 01, 2003 1:06 PM
>  >         To: megaco@ietf.org
>  >         Subject: [Megaco] Service Change and Testing
>  >
>  >         Hi,
>  >        =20
>  >         H.248 defines three values for the Termination State descrip=
tor
>  >         ("in service", "out of service" and "test"). The ServiceChan=
ge
>  >         procedures allows the MG to notify the MGC when a terminatio=
n is
>  >         about to be taken out of service (or is being returned to
>  >         service). It seems that there is not equivalent procedure wh=
en a
>  >         termination is about to be tested (i.e. termination state =3D
>  >         test) and is therefore not available for normal traffic. Is
>  >         there a specific reason for treating these two states
>  >         differently or is just that the wording "out of service" in =
the
>  >         ServiceChange description encompasses both the "test" and "o=
ut
>  >         of service" termination states. If this is the case, I think=
 a
>  >         clarification in the IG guide might be useful.
>  >        =20
>  >         Regards,
>  >         BC
>=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-admin@ietf.org  Mon Dec 15 04:17:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00547
	for <megaco-archive@lists.ietf.org>; Mon, 15 Dec 2003 04:17:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVoqc-0002q7-1E; Mon, 15 Dec 2003 04:17:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVoq7-0002pQ-6H
	for megaco@optimus.ietf.org; Mon, 15 Dec 2003 04:16:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00522
	for <megaco@ietf.org>; Mon, 15 Dec 2003 04:16:28 -0500 (EST)
From: assingh@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVoq4-00009o-00
	for megaco@ietf.org; Mon, 15 Dec 2003 04:16:28 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVopt-000078-00
	for megaco@ietf.org; Mon, 15 Dec 2003 04:16:17 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id hBF9CriB027494
	for <megaco@ietf.org>; Mon, 15 Dec 2003 14:42:53 +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 hBF9Dsb22481
	for <megaco@ietf.org>; Mon, 15 Dec 2003 14:43:54 +0530 (IST)
To: megaco@ietf.org
Date: Mon, 15 Dec 2003 14:38:47 +0530
Message-ID: <OF6F900B29.DB3DD9A8-ON65256DFD.00320E37@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 12/15/2003
 14:34:43
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Subject: [Megaco] Regarding Context Audit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: quoted-printable







Hi List,

I have a doubt in context audit grammer.

Assume that there is an active context which is not emergency. Now a
context audit request comes with only emergency token
MEGACO/1 [10.10.1.1]:2100 Transaction=3D1100000 {Context =3D=A01 { Cont=
extAudit
{Emergency} } }

As per the grammer
Action reply should have error descriptor or command reply. In command
reply we can send context properties whose grammer is
contextProperties=A0=A0=A0 =3D contextProperty *(COMMA contextProperty)=

contextProperty=A0=A0=A0 =3D (topologyDescriptor / priority / Emergency=
Token)
Now here it is mandatory to send=A0one of these tokens in context prope=
rties.
It is not possible to send emergency token=A0in this case as context is=
 not
emergency and the emergency token does not have a way to specify the va=
lue
as TRUE or FALSE.

What should be returned in this case ? Is there a=A0way to send an empt=
y
context audit reply.

Thanks in advance
Ashish

www.hssworld.com


"DISCLAIMER: This message is proprietary to Hughes Software Systems Lim=
ited
(HSS) and is intended solely for the use of the individual to whom it i=
s
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it=
 is
intended. If you have received this message in error, please notify the=

originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering=
, or
disclosing the contents of this message. HSS accepts no responsibility =
for
loss or damage arising from the use of the information transmitted by t=
his
email including damage from virus."=



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


From exim@www1.ietf.org  Mon Dec 15 04:17:37 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00563
	for <megaco-archive@odin.ietf.org>; Mon, 15 Dec 2003 04:17:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVoqi-0002rN-QX
	for megaco-archive@odin.ietf.org; Mon, 15 Dec 2003 04:17:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBF9H7ll010987
	for megaco-archive@odin.ietf.org; Mon, 15 Dec 2003 04:17:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVoqf-0002r8-S3
	for megaco-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 04:17:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00540
	for <megaco-web-archive@ietf.org>; Mon, 15 Dec 2003 04:17:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVoqd-0000AR-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 04:17:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVoqc-0000AN-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 04:17:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVoqc-0002q7-1E; Mon, 15 Dec 2003 04:17:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVoq7-0002pQ-6H
	for megaco@optimus.ietf.org; Mon, 15 Dec 2003 04:16:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00522
	for <megaco@ietf.org>; Mon, 15 Dec 2003 04:16:28 -0500 (EST)
From: assingh@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVoq4-00009o-00
	for megaco@ietf.org; Mon, 15 Dec 2003 04:16:28 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVopt-000078-00
	for megaco@ietf.org; Mon, 15 Dec 2003 04:16:17 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id hBF9CriB027494
	for <megaco@ietf.org>; Mon, 15 Dec 2003 14:42:53 +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 hBF9Dsb22481
	for <megaco@ietf.org>; Mon, 15 Dec 2003 14:43:54 +0530 (IST)
To: megaco@ietf.org
Date: Mon, 15 Dec 2003 14:38:47 +0530
Message-ID: <OF6F900B29.DB3DD9A8-ON65256DFD.00320E37@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 12/15/2003
 14:34:43
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Subject: [Megaco] Regarding Context Audit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable







Hi List,

I have a doubt in context audit grammer.

Assume that there is an active context which is not emergency. Now a
context audit request comes with only emergency token
MEGACO/1 [10.10.1.1]:2100 Transaction=3D1100000 {Context =3D=A01 { Cont=
extAudit
{Emergency} } }

As per the grammer
Action reply should have error descriptor or command reply. In command
reply we can send context properties whose grammer is
contextProperties=A0=A0=A0 =3D contextProperty *(COMMA contextProperty)=

contextProperty=A0=A0=A0 =3D (topologyDescriptor / priority / Emergency=
Token)
Now here it is mandatory to send=A0one of these tokens in context prope=
rties.
It is not possible to send emergency token=A0in this case as context is=
 not
emergency and the emergency token does not have a way to specify the va=
lue
as TRUE or FALSE.

What should be returned in this case ? Is there a=A0way to send an empt=
y
context audit reply.

Thanks in advance
Ashish

www.hssworld.com


"DISCLAIMER: This message is proprietary to Hughes Software Systems Lim=
ited
(HSS) and is intended solely for the use of the individual to whom it i=
s
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it=
 is
intended. If you have received this message in error, please notify the=

originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering=
, or
disclosing the contents of this message. HSS accepts no responsibility =
for
loss or damage arising from the use of the information transmitted by t=
his
email including damage from virus."=



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



From megaco-admin@ietf.org  Mon Dec 15 09:43:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10013
	for <megaco-archive@lists.ietf.org>; Mon, 15 Dec 2003 09:43:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVtw8-0006Te-Ka; Mon, 15 Dec 2003 09:43:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVivR-0005Fu-4Q
	for megaco@optimus.ietf.org; Sun, 14 Dec 2003 21:57:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06916
	for <megaco@ietf.org>; Sun, 14 Dec 2003 21:57:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVivO-0001G0-00
	for megaco@ietf.org; Sun, 14 Dec 2003 21:57:34 -0500
Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVivJ-0001FV-00
	for megaco@ietf.org; Sun, 14 Dec 2003 21:57:32 -0500
Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38])
	by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id hBF2pg93013220
	for <megaco@ietf.org>; Mon, 15 Dec 2003 10:51:47 +0800 (CST)
Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Mon Dec 15 10:58:03 2003 +0800
Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 15 Dec 2003 10:58:02 +0800
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="utf-7"
Content-Transfer-Encoding: 7bit
Date: Mon, 15 Dec 2003 10:58:02 +0800
Message-ID: <C2DB7F5BC458EA4C8EB46B7A4EFF7E76BE835F@bellnet-mail1.sbell.com.cn>
Thread-Topic: a question about timer related to SVC message with Graceful method .
Thread-Index: AcPCtz/GaEsC8jj3QPe7YWR/wWuWpg+AD0APQ-
From: "FND-V Wang JuLin" <JuLin.Wang@alcatel-sbell.com.cn>
To: <megaco@ietf.org>
Cc: <madhu@syndeocorp.com>, <prerepa.viswanadham@marconi.com>,
        <krishna_gundamaraju@adc.com>
X-OriginalArrivalTime: 15 Dec 2003 02:58:02.0695 (UTC) FILETIME=[414E2570:01C3C2B7]
Content-Transfer-Encoding: 7bit
Subject: [Megaco] a question about timer related to SVC message with Graceful method .
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hello list,
When MG issues SVC message with graceful method on a specific term or a group of terms, does it means MG let the related term(s) out of service by MG itself or under the control of MGC's subtract command afterwards?  I think MG take the related term(s) out of service (no matter they are in null context or call context) according to the delay time in  graceful SVC message without any relationship to MGC. While the exact occasion that MGC issue the Subtract commmand to indicate MG to  remove the terms into null context (only if the terms had been involved in calls) is not clearly defined in the protocol. Please clear my mind. Thank you+ACE-

 best  regards
+AD4- :-)Jerry Wang
tel:(8621)58541240 ext 9531
MP:13621761050
mailto:Julin.Wang+AEA-alcatel-sbell.com.cn 
Alcatel Shanghai Bell Co.LTD


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


From exim@www1.ietf.org  Mon Dec 15 09:43:47 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10039
	for <megaco-archive@odin.ietf.org>; Mon, 15 Dec 2003 09:43:47 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVtwH-0006aE-5z
	for megaco-archive@odin.ietf.org; Mon, 15 Dec 2003 09:43:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFEhCFg025300
	for megaco-archive@odin.ietf.org; Mon, 15 Dec 2003 09:43:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVtwG-0006Zz-IR
	for megaco-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 09:43:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09997
	for <megaco-web-archive@ietf.org>; Mon, 15 Dec 2003 09:43:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVtwA-0005je-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 09:43:06 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVtwA-0005jb-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 09:43:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVtw8-0006Te-Ka; Mon, 15 Dec 2003 09:43:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVivR-0005Fu-4Q
	for megaco@optimus.ietf.org; Sun, 14 Dec 2003 21:57:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06916
	for <megaco@ietf.org>; Sun, 14 Dec 2003 21:57:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVivO-0001G0-00
	for megaco@ietf.org; Sun, 14 Dec 2003 21:57:34 -0500
Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVivJ-0001FV-00
	for megaco@ietf.org; Sun, 14 Dec 2003 21:57:32 -0500
Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38])
	by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id hBF2pg93013220
	for <megaco@ietf.org>; Mon, 15 Dec 2003 10:51:47 +0800 (CST)
Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Mon Dec 15 10:58:03 2003 +0800
Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 15 Dec 2003 10:58:02 +0800
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="utf-7"
Content-Transfer-Encoding: 7bit
Date: Mon, 15 Dec 2003 10:58:02 +0800
Message-ID: <C2DB7F5BC458EA4C8EB46B7A4EFF7E76BE835F@bellnet-mail1.sbell.com.cn>
Thread-Topic: a question about timer related to SVC message with Graceful method .
Thread-Index: AcPCtz/GaEsC8jj3QPe7YWR/wWuWpg+AD0APQ-
From: "FND-V Wang JuLin" <JuLin.Wang@alcatel-sbell.com.cn>
To: <megaco@ietf.org>
Cc: <madhu@syndeocorp.com>, <prerepa.viswanadham@marconi.com>,
        <krishna_gundamaraju@adc.com>
X-OriginalArrivalTime: 15 Dec 2003 02:58:02.0695 (UTC) FILETIME=[414E2570:01C3C2B7]
Content-Transfer-Encoding: 7bit
Subject: [Megaco] a question about timer related to SVC message with Graceful method .
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello list,
When MG issues SVC message with graceful method on a specific term or a group of terms, does it means MG let the related term(s) out of service by MG itself or under the control of MGC's subtract command afterwards?  I think MG take the related term(s) out of service (no matter they are in null context or call context) according to the delay time in  graceful SVC message without any relationship to MGC. While the exact occasion that MGC issue the Subtract commmand to indicate MG to  remove the terms into null context (only if the terms had been involved in calls) is not clearly defined in the protocol. Please clear my mind. Thank you+ACE-

 best  regards
+AD4- :-)Jerry Wang
tel:(8621)58541240 ext 9531
MP:13621761050
mailto:Julin.Wang+AEA-alcatel-sbell.com.cn 
Alcatel Shanghai Bell Co.LTD


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



From megaco-admin@ietf.org  Mon Dec 15 12:30:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17573
	for <megaco-archive@lists.ietf.org>; Mon, 15 Dec 2003 12:30:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVwXj-0005bV-Cw; Mon, 15 Dec 2003 12:30:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVwXK-0005an-2L
	for megaco@optimus.ietf.org; Mon, 15 Dec 2003 12:29:38 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17546
	for <megaco@ietf.org>; Mon, 15 Dec 2003 12:29:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVwXI-0001Bd-00
	for megaco@ietf.org; Mon, 15 Dec 2003 12:29:36 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVwXH-0001Ba-00
	for megaco@ietf.org; Mon, 15 Dec 2003 12:29:35 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Mon, 15 Dec 2003 12:29:22 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZTHXL>; Mon, 15 Dec 2003 12:29:22 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B0A7A@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        Steve Cipolli
	 <SCipolli@radvision.com>,
        "'Troy Cauble'" <troy@bell-labs.com>
Cc: "'megaco@ietf.org'" <megaco@ietf.org>
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 	 L), & Short T imers (S)
Date: Mon, 15 Dec 2003 12:29:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C330.F8DF5BE0"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3C330.F8DF5BE0
Content-Type: text/plain;
	charset="iso-8859-1"

 
Kevin,
 
I think "ZX" and "Z[123]" should be valid.  Your additions seem to prohibit
these.  
 
On a related topic should an empty range specification ("[]") be rejected as
well, since nothing could possibly match it.
 
--Stephen
 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Wednesday, December 10, 2003 7:35 PM
To: Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)



All, 

Here is some proposed text for this.  I will include this in the IG.  Please
let me know any changes that would be better.  New text is demarcated by
>><<.

7.1.14.3        DigitMap Syntax 
... 
In addition to these event symbols, the string may contain "S" and "L"
inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
respectively indicate that the MG should use the short (S) timer or the long
(L) timer for subsequent events, overriding the timing rules described
above. If an explicit timing specifier is in effect in one alternative event
sequence, but none is given in any other candidate alternative, the timer
value set by the explicit timing specifier must be used. If all sequences
with explicit timing controls are dropped from the candidate set, timing
reverts to the default rules given above. >>If used inside a range notation,
the S and L specifiers shall be ignored.<<  Finally, if conflicting timing
specifiers are in effect in different alternative sequences, the long timer
shall be used.

A "Z" designates a long duration event: placed in front of the symbol(s)
designating the event(s) which satisfy a given digit position, it indicates
that that position is satisfied only if the duration of the event exceeds
the long-duration threshold. The value of this threshold is assumed to be
provisioned in the MG.  >>If the Z specifier is not followed by a digit (0-9
or A-K), then the MG shall reject the digitmap as invalid protocol.  When
used in a range notation, the Z specifier applies solely to the immediately
following digit.<<

Kevin 
________________________________ 

        From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
        Sent: Friday, December 05, 2003 1:09 PM 
        To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Troy Cauble' 
        Cc: megaco@ietf.org 
        Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
Timers ( L), & Short T imers (S) 
        
        
        While I tend to agree with most of the answers below, I don't see
any of this specified in the specification.  If we can agree that the
answers below are the correct interpretation, then we still need
clarification in the spec or implementors guide.  I'm still hoping the
original author of this section of the spec will clarify the original
intention.

         
        --Stephen 

                -----Original Message----- 
                From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 
                Sent: Tuesday, December 02, 2003 3:18 PM 
                To: Steve Cipolli; 'Troy Cauble' 
                Cc: megaco@ietf.org 
                Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 
                
                

                Comments inline. [KJBII] 

                Kevin 

                -----Original Message----- 
                From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                Sent: Tuesday, December 02, 2003 2:40 PM 
                To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH] 
                Cc: megaco@ietf.org 
                Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 

                Perhaps I moved us off track a bit.  It is clear that there
is more than one interpretation of the specification with regard to L, S,
and to a lesser extent Z.  Can the authors comment on what the intent of the
specification was and then perhaps we can reach some conclusion?

                Here is a partial list of odd digitmaps that seem to defy
interpretation: 
                        "123Z"                          - "Z" ignored or
error? 
                [KJBII] Z here has nothing to modify.  Error. 

                        "123S"                  - "S" (or "L") ignored or
error? 
                [KJBII] In this instance, the digitmap switches to short
interdigit timing after detecting "123".  So, neither. 

                        "1ZZ23"                 - First "Z" ignored or
error? 
                [KJBII] Because Z is defined as modifying the following
digit, and Z cannot modify Z, this should be an error. 

                        "1ZSSSSSSSSS23"         - "Z" applied to the "2" or
ignored or error? 
                [KJBII] See above.  Error as Z cannot modify S (or L). 

                        "135[2Z46]"                     - "Z" applied to "4"
or to all in the range (246) or ignored or error? 

                [KJBII] Z applies solely to the 4 here. 

                        "135[246Z]79"           - "Z" applied to "7" or
ignored or error? 
                [KJBII] Nothing for Z to modify.  Error. 

                        "135[2S46]"                     - "S" (or "L")
applied to all in range (246) or ignored or error? 

                [KJBII] This is the root of our earlier discussion.  L and S
do not modify digits -- they modify timing strategy for the digitmap at the
time they are encountered.  [246] means "match 2, 4 or 6".  So [2S46]
means... What exactly? "Match 2, short timeout, 4 or 6"?  Or "match 2, 4 or
6 while running the short timer for this digit only"?  Or "run the short
timer S after detecting 2, but not if 4 or 6 is detected"?  If the string
were "135S[246]" then we would start using the short timer before looking
for 2, 4 or 6.  If it were "135[246]S", we would start using the short timer
AFTER matching 2, 4 or 6.  But, with the S timer INSIDE the range, that
would indicate that the timer would have to fire to continue.  For instance,
if the string were "135[2S46]79", that would seem to indicate that if NO
digit was detected for the duration of the short timer, then we should
continue with the string to find 7.  This is a contrary usage to S and L at
any other point in a digitmap.  I think S and L should be ignored within
ranges.  If the MGC wants to use the S or L timer, then put them outside the
range.

                        "135[2L4S6]"            - "L" or "S" applied or both
(somehow?) or ignored or error? 
                [KJBII] See above -- the same arguments apply here.  I would
note that L would never get "detected" here, since S would match first.

                Thanks, 
                --Stephen 

      [Stephen>] Snip... 


------_=_NextPart_001_01C3C330.F8DF5BE0
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] Digit Maps: Long Duration Modifier(Z), Long Timers ( L), & Short T imers (S)</TITLE>

<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2>Kevin,</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff size=2>I 
think "ZX" and "Z[123]" should be valid.&nbsp; Your additions seem to prohibit 
these.&nbsp;&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff size=2>On a 
related&nbsp;topic should an empty range specification ("[]") be rejected as 
well, since nothing could possibly match it.</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2>--Stephen</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; 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> Wednesday, December 10, 
  2003 7:35 PM<BR><B>To:</B> Steve Cipolli; 'Troy Cauble'<BR><B>Cc:</B> 
  megaco@ietf.org<BR><B>Subject:</B> RE: [Megaco] Digit Maps: Long Duration 
  Modifier(Z), Long Timers ( L), &amp; Short T imers (S)<BR><BR></FONT></DIV>
  <P><FONT size=2>All,</FONT> </P>
  <P><FONT size=2>Here is some proposed text for this.&nbsp; I will include this 
  in the IG.&nbsp; Please let me know any changes that would be better.&nbsp; 
  New text is demarcated by &gt;&gt;&lt;&lt;.</FONT></P>
  <P><FONT size=2>7.1.14.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DigitMap 
  Syntax</FONT> <BR><FONT size=2>...</FONT> <BR><FONT size=2>In addition to 
  these event symbols, the string may contain "S" and "L" inter-event timing 
  specifiers and the "Z" duration modifier. "S" and "L" respectively indicate 
  that the MG should use the short (S) timer or the long (L) timer for 
  subsequent events, overriding the timing rules described above. If an explicit 
  timing specifier is in effect in one alternative event sequence, but none is 
  given in any other candidate alternative, the timer value set by the explicit 
  timing specifier must be used. If all sequences with explicit timing controls 
  are dropped from the candidate set, timing reverts to the default rules given 
  above. &gt;&gt;If used inside a range notation, the S and L specifiers shall 
  be ignored.&lt;&lt;&nbsp; Finally, if conflicting timing specifiers are in 
  effect in different alternative sequences, the long timer shall be 
  used.</FONT></P>
  <P><FONT size=2>A "Z" designates a long duration event: placed in front of the 
  symbol(s) designating the event(s) which satisfy a given digit position, it 
  indicates that that position is satisfied only if the duration of the event 
  exceeds the long-duration threshold. The value of this threshold is assumed to 
  be provisioned in the MG.&nbsp; &gt;&gt;If the Z specifier is not followed by 
  a digit (0-9 or A-K), then the MG shall reject the digitmap as invalid 
  protocol.&nbsp; When used in a range notation, the Z specifier applies solely 
  to the immediately following digit.&lt;&lt;</FONT></P>
  <P><FONT size=2>Kevin</FONT> <BR><FONT 
  size=2>________________________________</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>From: Steve Cipolli 
  [<A href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Sent: 
  Friday, December 05, 2003 1:09 PM</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>To: Boyle, Kevin 
  [NCRTP:3Z40:EXCH]; 'Troy Cauble'</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Cc: 
  megaco@ietf.org</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
  Timers ( L), &amp; Short T imers (S)</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>While I tend to 
  agree with most of the answers below, I don't see any of this specified in the 
  specification.&nbsp; If we can agree that the answers below are the correct 
  interpretation, then we still need clarification in the spec or implementors 
  guide.&nbsp; I'm still hoping the original author of this section of the spec 
  will clarify the original intention.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT size=2> 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>--Stephen</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>-----Original 
  Message-----</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>From: Kevin Boyle [<A 
  href="mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.com</A>]</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Sent: Tuesday, 
  December 02, 2003 3:18 PM</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>To: Steve Cipolli; 
  'Troy Cauble'</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Cc: 
  megaco@ietf.org</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Subject: RE: [Megaco] 
  Digit Maps: Long Duration Modifier(Z), Long Timers ( L), &amp; Short T imers 
  (S)</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Comments inline. 
  [KJBII] </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Kevin </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>-----Original 
  Message----- </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>From: Steve Cipolli 
  [<A href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Sent: Tuesday, 
  December 02, 2003 2:40 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>To: 'Troy Cauble'; 
  Boyle, Kevin [NCRTP:3Z40:EXCH] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Cc: megaco@ietf.org 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Subject: RE: [Megaco] 
  Digit Maps: Long Duration Modifier(Z), Long Timers ( L), &amp; Short T imers 
  (S) </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Perhaps I moved us off 
  track a bit.&nbsp; It is clear that there is more than one interpretation of 
  the specification with regard to L, S, and to a lesser extent Z.&nbsp; Can the 
  authors comment on what the intent of the specification was and then perhaps 
  we can reach some conclusion?</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Here is a partial list 
  of odd digitmaps that seem to defy interpretation: 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "123Z"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "Z" ignored or error? </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Z here has 
  nothing to modify.&nbsp; Error. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "123S"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "S" (or "L") ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] In this 
  instance, the digitmap switches to short interdigit timing after detecting 
  "123".&nbsp; So, neither. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "1ZZ23"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - First "Z" ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Because Z is 
  defined as modifying the following digit, and Z cannot modify Z, this should 
  be an error. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "1ZSSSSSSSSS23"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "Z" applied 
  to the "2" or ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] See 
  above.&nbsp; Error as Z cannot modify S (or L). </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2Z46]"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "Z" applied to "4" or to all in the range (246) or ignored or error? 
  </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Z applies 
  solely to the 4 here. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[246Z]79"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 
  "Z" applied to "7" or ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Nothing for Z 
  to modify.&nbsp; Error. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2S46]"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "S" (or "L") applied to all in range (246) or ignored or error? </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] This is the 
  root of our earlier discussion.&nbsp; L and S do not modify digits -- they 
  modify timing strategy for the digitmap at the time they are 
  encountered.&nbsp; [246] means "match 2, 4 or 6".&nbsp; So [2S46] means... 
  What exactly? "Match 2, short timeout, 4 or 6"?&nbsp; Or "match 2, 4 or 6 
  while running the short timer for this digit only"?&nbsp; Or "run the short 
  timer S after detecting 2, but not if 4 or 6 is detected"?&nbsp; If the string 
  were "135S[246]" then we would start using the short timer before looking for 
  2, 4 or 6.&nbsp; If it were "135[246]S", we would start using the short timer 
  AFTER matching 2, 4 or 6.&nbsp; But, with the S timer INSIDE the range, that 
  would indicate that the timer would have to fire to continue.&nbsp; For 
  instance, if the string were "135[2S46]79", that would seem to indicate that 
  if NO digit was detected for the duration of the short timer, then we should 
  continue with the string to find 7.&nbsp; This is a contrary usage to S and L 
  at any other point in a digitmap.&nbsp; I think S and L should be ignored 
  within ranges.&nbsp; If the MGC wants to use the S or L timer, then put them 
  outside the range.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2L4S6]"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "L" or "S" applied or both (somehow?) or ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] See above -- 
  the same arguments apply here.&nbsp; I would note that L would never get 
  "detected" here, since S would match first.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Thanks, 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>--Stephen </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN class=261132422-12122003><FONT 
  face=Arial 
size=2>[Stephen&gt;]&nbsp;Snip...&nbsp;</FONT></SPAN></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3C330.F8DF5BE0--

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


From exim@www1.ietf.org  Mon Dec 15 12:30:37 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17588
	for <megaco-archive@odin.ietf.org>; Mon, 15 Dec 2003 12:30:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVwXo-0005cn-Et
	for megaco-archive@odin.ietf.org; Mon, 15 Dec 2003 12:30:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFHU84w021615
	for megaco-archive@odin.ietf.org; Mon, 15 Dec 2003 12:30:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVwXo-0005cY-9H
	for megaco-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 12:30:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17551
	for <megaco-web-archive@ietf.org>; Mon, 15 Dec 2003 12:30:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVwXm-0001Bk-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 12:30:06 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVwXm-0001Bh-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 12:30:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVwXj-0005bV-Cw; Mon, 15 Dec 2003 12:30:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVwXK-0005an-2L
	for megaco@optimus.ietf.org; Mon, 15 Dec 2003 12:29:38 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17546
	for <megaco@ietf.org>; Mon, 15 Dec 2003 12:29:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVwXI-0001Bd-00
	for megaco@ietf.org; Mon, 15 Dec 2003 12:29:36 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVwXH-0001Ba-00
	for megaco@ietf.org; Mon, 15 Dec 2003 12:29:35 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Mon, 15 Dec 2003 12:29:22 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZTHXL>; Mon, 15 Dec 2003 12:29:22 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B0A7A@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        Steve Cipolli
	 <SCipolli@radvision.com>,
        "'Troy Cauble'" <troy@bell-labs.com>
Cc: "'megaco@ietf.org'" <megaco@ietf.org>
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 	 L), & Short T imers (S)
Date: Mon, 15 Dec 2003 12:29:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C330.F8DF5BE0"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3C330.F8DF5BE0
Content-Type: text/plain;
	charset="iso-8859-1"

 
Kevin,
 
I think "ZX" and "Z[123]" should be valid.  Your additions seem to prohibit
these.  
 
On a related topic should an empty range specification ("[]") be rejected as
well, since nothing could possibly match it.
 
--Stephen
 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Wednesday, December 10, 2003 7:35 PM
To: Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)



All, 

Here is some proposed text for this.  I will include this in the IG.  Please
let me know any changes that would be better.  New text is demarcated by
>><<.

7.1.14.3        DigitMap Syntax 
... 
In addition to these event symbols, the string may contain "S" and "L"
inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
respectively indicate that the MG should use the short (S) timer or the long
(L) timer for subsequent events, overriding the timing rules described
above. If an explicit timing specifier is in effect in one alternative event
sequence, but none is given in any other candidate alternative, the timer
value set by the explicit timing specifier must be used. If all sequences
with explicit timing controls are dropped from the candidate set, timing
reverts to the default rules given above. >>If used inside a range notation,
the S and L specifiers shall be ignored.<<  Finally, if conflicting timing
specifiers are in effect in different alternative sequences, the long timer
shall be used.

A "Z" designates a long duration event: placed in front of the symbol(s)
designating the event(s) which satisfy a given digit position, it indicates
that that position is satisfied only if the duration of the event exceeds
the long-duration threshold. The value of this threshold is assumed to be
provisioned in the MG.  >>If the Z specifier is not followed by a digit (0-9
or A-K), then the MG shall reject the digitmap as invalid protocol.  When
used in a range notation, the Z specifier applies solely to the immediately
following digit.<<

Kevin 
________________________________ 

        From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
        Sent: Friday, December 05, 2003 1:09 PM 
        To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Troy Cauble' 
        Cc: megaco@ietf.org 
        Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
Timers ( L), & Short T imers (S) 
        
        
        While I tend to agree with most of the answers below, I don't see
any of this specified in the specification.  If we can agree that the
answers below are the correct interpretation, then we still need
clarification in the spec or implementors guide.  I'm still hoping the
original author of this section of the spec will clarify the original
intention.

         
        --Stephen 

                -----Original Message----- 
                From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 
                Sent: Tuesday, December 02, 2003 3:18 PM 
                To: Steve Cipolli; 'Troy Cauble' 
                Cc: megaco@ietf.org 
                Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 
                
                

                Comments inline. [KJBII] 

                Kevin 

                -----Original Message----- 
                From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                Sent: Tuesday, December 02, 2003 2:40 PM 
                To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH] 
                Cc: megaco@ietf.org 
                Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 

                Perhaps I moved us off track a bit.  It is clear that there
is more than one interpretation of the specification with regard to L, S,
and to a lesser extent Z.  Can the authors comment on what the intent of the
specification was and then perhaps we can reach some conclusion?

                Here is a partial list of odd digitmaps that seem to defy
interpretation: 
                        "123Z"                          - "Z" ignored or
error? 
                [KJBII] Z here has nothing to modify.  Error. 

                        "123S"                  - "S" (or "L") ignored or
error? 
                [KJBII] In this instance, the digitmap switches to short
interdigit timing after detecting "123".  So, neither. 

                        "1ZZ23"                 - First "Z" ignored or
error? 
                [KJBII] Because Z is defined as modifying the following
digit, and Z cannot modify Z, this should be an error. 

                        "1ZSSSSSSSSS23"         - "Z" applied to the "2" or
ignored or error? 
                [KJBII] See above.  Error as Z cannot modify S (or L). 

                        "135[2Z46]"                     - "Z" applied to "4"
or to all in the range (246) or ignored or error? 

                [KJBII] Z applies solely to the 4 here. 

                        "135[246Z]79"           - "Z" applied to "7" or
ignored or error? 
                [KJBII] Nothing for Z to modify.  Error. 

                        "135[2S46]"                     - "S" (or "L")
applied to all in range (246) or ignored or error? 

                [KJBII] This is the root of our earlier discussion.  L and S
do not modify digits -- they modify timing strategy for the digitmap at the
time they are encountered.  [246] means "match 2, 4 or 6".  So [2S46]
means... What exactly? "Match 2, short timeout, 4 or 6"?  Or "match 2, 4 or
6 while running the short timer for this digit only"?  Or "run the short
timer S after detecting 2, but not if 4 or 6 is detected"?  If the string
were "135S[246]" then we would start using the short timer before looking
for 2, 4 or 6.  If it were "135[246]S", we would start using the short timer
AFTER matching 2, 4 or 6.  But, with the S timer INSIDE the range, that
would indicate that the timer would have to fire to continue.  For instance,
if the string were "135[2S46]79", that would seem to indicate that if NO
digit was detected for the duration of the short timer, then we should
continue with the string to find 7.  This is a contrary usage to S and L at
any other point in a digitmap.  I think S and L should be ignored within
ranges.  If the MGC wants to use the S or L timer, then put them outside the
range.

                        "135[2L4S6]"            - "L" or "S" applied or both
(somehow?) or ignored or error? 
                [KJBII] See above -- the same arguments apply here.  I would
note that L would never get "detected" here, since S would match first.

                Thanks, 
                --Stephen 

      [Stephen>] Snip... 


------_=_NextPart_001_01C3C330.F8DF5BE0
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] Digit Maps: Long Duration Modifier(Z), Long Timers ( L), & Short T imers (S)</TITLE>

<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2>Kevin,</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff size=2>I 
think "ZX" and "Z[123]" should be valid.&nbsp; Your additions seem to prohibit 
these.&nbsp;&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff size=2>On a 
related&nbsp;topic should an empty range specification ("[]") be rejected as 
well, since nothing could possibly match it.</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2>--Stephen</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; 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> Wednesday, December 10, 
  2003 7:35 PM<BR><B>To:</B> Steve Cipolli; 'Troy Cauble'<BR><B>Cc:</B> 
  megaco@ietf.org<BR><B>Subject:</B> RE: [Megaco] Digit Maps: Long Duration 
  Modifier(Z), Long Timers ( L), &amp; Short T imers (S)<BR><BR></FONT></DIV>
  <P><FONT size=2>All,</FONT> </P>
  <P><FONT size=2>Here is some proposed text for this.&nbsp; I will include this 
  in the IG.&nbsp; Please let me know any changes that would be better.&nbsp; 
  New text is demarcated by &gt;&gt;&lt;&lt;.</FONT></P>
  <P><FONT size=2>7.1.14.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DigitMap 
  Syntax</FONT> <BR><FONT size=2>...</FONT> <BR><FONT size=2>In addition to 
  these event symbols, the string may contain "S" and "L" inter-event timing 
  specifiers and the "Z" duration modifier. "S" and "L" respectively indicate 
  that the MG should use the short (S) timer or the long (L) timer for 
  subsequent events, overriding the timing rules described above. If an explicit 
  timing specifier is in effect in one alternative event sequence, but none is 
  given in any other candidate alternative, the timer value set by the explicit 
  timing specifier must be used. If all sequences with explicit timing controls 
  are dropped from the candidate set, timing reverts to the default rules given 
  above. &gt;&gt;If used inside a range notation, the S and L specifiers shall 
  be ignored.&lt;&lt;&nbsp; Finally, if conflicting timing specifiers are in 
  effect in different alternative sequences, the long timer shall be 
  used.</FONT></P>
  <P><FONT size=2>A "Z" designates a long duration event: placed in front of the 
  symbol(s) designating the event(s) which satisfy a given digit position, it 
  indicates that that position is satisfied only if the duration of the event 
  exceeds the long-duration threshold. The value of this threshold is assumed to 
  be provisioned in the MG.&nbsp; &gt;&gt;If the Z specifier is not followed by 
  a digit (0-9 or A-K), then the MG shall reject the digitmap as invalid 
  protocol.&nbsp; When used in a range notation, the Z specifier applies solely 
  to the immediately following digit.&lt;&lt;</FONT></P>
  <P><FONT size=2>Kevin</FONT> <BR><FONT 
  size=2>________________________________</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>From: Steve Cipolli 
  [<A href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Sent: 
  Friday, December 05, 2003 1:09 PM</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>To: Boyle, Kevin 
  [NCRTP:3Z40:EXCH]; 'Troy Cauble'</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Cc: 
  megaco@ietf.org</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
  Timers ( L), &amp; Short T imers (S)</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>While I tend to 
  agree with most of the answers below, I don't see any of this specified in the 
  specification.&nbsp; If we can agree that the answers below are the correct 
  interpretation, then we still need clarification in the spec or implementors 
  guide.&nbsp; I'm still hoping the original author of this section of the spec 
  will clarify the original intention.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT size=2> 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>--Stephen</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>-----Original 
  Message-----</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>From: Kevin Boyle [<A 
  href="mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.com</A>]</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Sent: Tuesday, 
  December 02, 2003 3:18 PM</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>To: Steve Cipolli; 
  'Troy Cauble'</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Cc: 
  megaco@ietf.org</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Subject: RE: [Megaco] 
  Digit Maps: Long Duration Modifier(Z), Long Timers ( L), &amp; Short T imers 
  (S)</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Comments inline. 
  [KJBII] </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Kevin </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>-----Original 
  Message----- </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>From: Steve Cipolli 
  [<A href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Sent: Tuesday, 
  December 02, 2003 2:40 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>To: 'Troy Cauble'; 
  Boyle, Kevin [NCRTP:3Z40:EXCH] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Cc: megaco@ietf.org 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Subject: RE: [Megaco] 
  Digit Maps: Long Duration Modifier(Z), Long Timers ( L), &amp; Short T imers 
  (S) </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Perhaps I moved us off 
  track a bit.&nbsp; It is clear that there is more than one interpretation of 
  the specification with regard to L, S, and to a lesser extent Z.&nbsp; Can the 
  authors comment on what the intent of the specification was and then perhaps 
  we can reach some conclusion?</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Here is a partial list 
  of odd digitmaps that seem to defy interpretation: 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "123Z"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "Z" ignored or error? </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Z here has 
  nothing to modify.&nbsp; Error. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "123S"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "S" (or "L") ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] In this 
  instance, the digitmap switches to short interdigit timing after detecting 
  "123".&nbsp; So, neither. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "1ZZ23"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - First "Z" ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Because Z is 
  defined as modifying the following digit, and Z cannot modify Z, this should 
  be an error. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "1ZSSSSSSSSS23"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "Z" applied 
  to the "2" or ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] See 
  above.&nbsp; Error as Z cannot modify S (or L). </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2Z46]"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "Z" applied to "4" or to all in the range (246) or ignored or error? 
  </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Z applies 
  solely to the 4 here. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[246Z]79"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 
  "Z" applied to "7" or ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Nothing for Z 
  to modify.&nbsp; Error. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2S46]"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "S" (or "L") applied to all in range (246) or ignored or error? </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] This is the 
  root of our earlier discussion.&nbsp; L and S do not modify digits -- they 
  modify timing strategy for the digitmap at the time they are 
  encountered.&nbsp; [246] means "match 2, 4 or 6".&nbsp; So [2S46] means... 
  What exactly? "Match 2, short timeout, 4 or 6"?&nbsp; Or "match 2, 4 or 6 
  while running the short timer for this digit only"?&nbsp; Or "run the short 
  timer S after detecting 2, but not if 4 or 6 is detected"?&nbsp; If the string 
  were "135S[246]" then we would start using the short timer before looking for 
  2, 4 or 6.&nbsp; If it were "135[246]S", we would start using the short timer 
  AFTER matching 2, 4 or 6.&nbsp; But, with the S timer INSIDE the range, that 
  would indicate that the timer would have to fire to continue.&nbsp; For 
  instance, if the string were "135[2S46]79", that would seem to indicate that 
  if NO digit was detected for the duration of the short timer, then we should 
  continue with the string to find 7.&nbsp; This is a contrary usage to S and L 
  at any other point in a digitmap.&nbsp; I think S and L should be ignored 
  within ranges.&nbsp; If the MGC wants to use the S or L timer, then put them 
  outside the range.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2L4S6]"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "L" or "S" applied or both (somehow?) or ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] See above -- 
  the same arguments apply here.&nbsp; I would note that L would never get 
  "detected" here, since S would match first.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Thanks, 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>--Stephen </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN class=261132422-12122003><FONT 
  face=Arial 
size=2>[Stephen&gt;]&nbsp;Snip...&nbsp;</FONT></SPAN></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3C330.F8DF5BE0--

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



From megaco-admin@ietf.org  Mon Dec 15 12:45:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18005
	for <megaco-archive@lists.ietf.org>; Mon, 15 Dec 2003 12:45:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVwmF-0006Il-Pn; Mon, 15 Dec 2003 12:45:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVwS4-0005Ue-Cn
	for megaco@optimus.ietf.org; Mon, 15 Dec 2003 12:24:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17325
	for <megaco@ietf.org>; Mon, 15 Dec 2003 12:24:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVwS2-00015b-00
	for megaco@ietf.org; Mon, 15 Dec 2003 12:24:10 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVwS0-00015Y-00
	for megaco@ietf.org; Mon, 15 Dec 2003 12:24:08 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Mon, 15 Dec 2003 12:23:55 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZTHW0>; Mon, 15 Dec 2003 12:23:55 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B0A79@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        Steve Cipolli
	 <SCipolli@radvision.com>,
        "'Troy Cauble'" <troy@bell-labs.com>
Cc: "'megaco@ietf.org'" <megaco@ietf.org>
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 	 L), & Short T imers (S)
Date: Mon, 15 Dec 2003 12:23:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C330.36FD6AD0"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3C330.36FD6AD0
Content-Type: text/plain;
	charset="iso-8859-1"

Kevin,
 
I think "ZX" and "Z[123]" should be valid.  Your additions seem to prohibit
these.  
 
On a related topic should an empty range specification ("[]") be rejected as
well, since nothing could possibly match it.
 
--Stephen
 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Wednesday, December 10, 2003 7:35 PM
To: Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)



All, 

Here is some proposed text for this.  I will include this in the IG.  Please
let me know any changes that would be better.  New text is demarcated by
>><<.

7.1.14.3        DigitMap Syntax 
... 
In addition to these event symbols, the string may contain "S" and "L"
inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
respectively indicate that the MG should use the short (S) timer or the long
(L) timer for subsequent events, overriding the timing rules described
above. If an explicit timing specifier is in effect in one alternative event
sequence, but none is given in any other candidate alternative, the timer
value set by the explicit timing specifier must be used. If all sequences
with explicit timing controls are dropped from the candidate set, timing
reverts to the default rules given above. >>If used inside a range notation,
the S and L specifiers shall be ignored.<<  Finally, if conflicting timing
specifiers are in effect in different alternative sequences, the long timer
shall be used.

A "Z" designates a long duration event: placed in front of the symbol(s)
designating the event(s) which satisfy a given digit position, it indicates
that that position is satisfied only if the duration of the event exceeds
the long-duration threshold. The value of this threshold is assumed to be
provisioned in the MG.  >>If the Z specifier is not followed by a digit (0-9
or A-K), then the MG shall reject the digitmap as invalid protocol.  When
used in a range notation, the Z specifier applies solely to the immediately
following digit.<<

Kevin 
________________________________ 

        From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
        Sent: Friday, December 05, 2003 1:09 PM 
        To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Troy Cauble' 
        Cc: megaco@ietf.org 
        Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
Timers ( L), & Short T imers (S) 
        
        
        While I tend to agree with most of the answers below, I don't see
any of this specified in the specification.  If we can agree that the
answers below are the correct interpretation, then we still need
clarification in the spec or implementors guide.  I'm still hoping the
original author of this section of the spec will clarify the original
intention.

         
        --Stephen 

                -----Original Message----- 
                From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 
                Sent: Tuesday, December 02, 2003 3:18 PM 
                To: Steve Cipolli; 'Troy Cauble' 
                Cc: megaco@ietf.org 
                Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 
                
                

                Comments inline. [KJBII] 

                Kevin 

                -----Original Message----- 
                From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                Sent: Tuesday, December 02, 2003 2:40 PM 
                To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH] 
                Cc: megaco@ietf.org 
                Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 

                Perhaps I moved us off track a bit.  It is clear that there
is more than one interpretation of the specification with regard to L, S,
and to a lesser extent Z.  Can the authors comment on what the intent of the
specification was and then perhaps we can reach some conclusion?

                Here is a partial list of odd digitmaps that seem to defy
interpretation: 
                        "123Z"                          - "Z" ignored or
error? 
                [KJBII] Z here has nothing to modify.  Error. 

                        "123S"                  - "S" (or "L") ignored or
error? 
                [KJBII] In this instance, the digitmap switches to short
interdigit timing after detecting "123".  So, neither. 

                        "1ZZ23"                 - First "Z" ignored or
error? 
                [KJBII] Because Z is defined as modifying the following
digit, and Z cannot modify Z, this should be an error. 

                        "1ZSSSSSSSSS23"         - "Z" applied to the "2" or
ignored or error? 
                [KJBII] See above.  Error as Z cannot modify S (or L). 

                        "135[2Z46]"                     - "Z" applied to "4"
or to all in the range (246) or ignored or error? 

                [KJBII] Z applies solely to the 4 here. 

                        "135[246Z]79"           - "Z" applied to "7" or
ignored or error? 
                [KJBII] Nothing for Z to modify.  Error. 

                        "135[2S46]"                     - "S" (or "L")
applied to all in range (246) or ignored or error? 

                [KJBII] This is the root of our earlier discussion.  L and S
do not modify digits -- they modify timing strategy for the digitmap at the
time they are encountered.  [246] means "match 2, 4 or 6".  So [2S46]
means... What exactly? "Match 2, short timeout, 4 or 6"?  Or "match 2, 4 or
6 while running the short timer for this digit only"?  Or "run the short
timer S after detecting 2, but not if 4 or 6 is detected"?  If the string
were "135S[246]" then we would start using the short timer before looking
for 2, 4 or 6.  If it were "135[246]S", we would start using the short timer
AFTER matching 2, 4 or 6.  But, with the S timer INSIDE the range, that
would indicate that the timer would have to fire to continue.  For instance,
if the string were "135[2S46]79", that would seem to indicate that if NO
digit was detected for the duration of the short timer, then we should
continue with the string to find 7.  This is a contrary usage to S and L at
any other point in a digitmap.  I think S and L should be ignored within
ranges.  If the MGC wants to use the S or L timer, then put them outside the
range.

                        "135[2L4S6]"            - "L" or "S" applied or both
(somehow?) or ignored or error? 
                [KJBII] See above -- the same arguments apply here.  I would
note that L would never get "detected" here, since S would match first.

                Thanks, 
                --Stephen 

                        

                > -----Original Message----- 
                > From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                > Sent: Monday, December 01, 2003 8:01 PM 
                > To: 'Troy Cauble'; Kevin Boyle 
                > Cc: megaco@ietf.org 
                > Subject: RE: [Megaco] Digit Maps: Long Duration
Modifier(Z), Long 
                > Timers ( L), & Short T imers (S) 
                > 
                > 
                > Part of the problem is the term "alternatives" is not
clear.  
                > The text in 
                > 7.1.14.3 says of "alternatives": 
                > A DigitMap, according to this syntax, is defined either by
a string or 
                > by a list of strings.  Each string in the list is an
alternative event 
                > sequence, specified either as a sequence of digit map
symbols or as a 
                > regular expression of digit map symbols. 
                > 
                > My reading of this is that "alternatives" are each string
and not the 
                > possible sequences through a range, but admittedly this is
not clear. 
                > 
                > The section doesn't seem to explain other odd sequences
like "123Z". 
                > Presumably the "Z" is simply ignored although an error
could also be 
                > considered the proper outcome. 
                > 
                > I must say I prefer an interpretation in which the number
of possible 
                > ways to perform the same action is as close to 1 and
possible. 
                > Therefore, I'd 
                > prefer to ban (or at least ignore) "L" and "S" within
ranges. 
                > 
                > --Stephen 
                > 
                > > -----Original Message----- 
                > > From: Troy Cauble [ mailto:troy@bell-labs.com
<mailto:troy@bell-labs.com> ] 
                > > Sent: Monday, December 01, 2003 6:33 PM 
                > > To: Kevin Boyle 
                > > Cc: megaco@ietf.org 
                > > Subject: Re: [Megaco] Digit Maps: Long Duration
Modifier(Z), Long 
                > > Timers ( L), & Short T imers (S) 
                > > 
                > > 
                > > 
                > > 
                > > I disagree that "L" and "S" are meaningless within a
range. 
                > > 
                > > "L" and "S" are used to specify the timer used for
"subsequent 
                > > events". 
                > > 
                > > I would argue that the "5" is a subsequent event in
"[34L]5", just 
                > > as it is in "[34]L5". 
                > > 
                > > I would also argue that the "4" in "[3L4]5" is NOT a
"subsequent 
                > > event", although one might debate the definition of
"subsequent". 
                > > 
                > > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and 
                > "[34]L5" are all 
                > > the same. (And the "L" is not meaningless.) 
                > > 
                > > 
                > > Note that section 7.1.14.3 does bother to specify what
happens when 
                > > explicit timing specifiers are only active in some
"alternatives", 
                > or when they 
                > > differ in among alternatives -- the same timer value is
used for all 
                > > alternatives. 
                > > 
                > > 
                > > 7.1.14.3: 
                > > 
                > >  > In addition to these event symbols, the string may
contain "S" 
                > > and "L" 
                > >  > inter-event timing specifiers and the "Z" duration
modifier. "S" 
                > > and "L" 
                > >  > respectively indicate that the MG should use the
short (S) timer 
                > > or the  > long (L) timer for subsequent events,
overriding the 
                > > timing rules  > described above. If an explicit timing
specifier is 
                > > in effect in one  > alternative event sequence, but none
is given in 
                > > any other candidate  > alternative, the timer value set
by the 
                > > explicit timing specifier must be  > used. If all
sequences with 
                > > explicit timing controls are dropped from the  >
candidate set, 
                > > timing reverts to the default rules given above.
Finally,  > if 
                > > conflicting timing specifiers are in effect in different
alternative  
                > > > sequences, the long timer shall be used. 
                > > 
                > > 
                > > -troy 
                > > 
                > > 
                > > 
                > > Kevin Boyle wrote: 
                > > 
                > > > Since a range means "match one of these", I would
agree 
                > > with the assessment 
                > > > that L and S are meaningless within a range. 
                > > >  
                > > > Kevin 
                > > > 
                > > > 
                > > >   _____ 
                > > > 
                > > > From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                > > > Sent: Monday, December 01, 2003 5:22 PM 
                > > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org 
                > > > Subject: RE: [Megaco] Digit Maps: Long Duration 
                > > Modifier(Z), Long Timers ( 
                > > > L), & Short T imers (S) 
                > > > 
                > > > 
                > > > Thanks for the feedback.  
                > > >  
                > > > Just to make sure I understand the L and S cases: 
                > > > They are syntactically legal in a range specification,
but 
                > > semantically they 
                > > > have no effect.  Correct? 
                > > >  
                > > > --Stephen 
                > > > 
                > > > -----Original Message----- 
                > > > From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 
                > > > Sent: Monday, December 01, 2003 5:15 PM 
                > > > To: Steve Cipolli; megaco@ietf.org 
                > > > Subject: RE: [Megaco] Digit Maps: Long Duration 
                > > Modifier(Z), Long Timers ( 
                > > > L), & Short T imers (S) 
                > > > 
                > > > 
                > > > Your interpretation is correct.  Because Z changes how
a 
                > > digit is matched, 
                > > > it makes sense within a range.  Think of Z as part of
the 
                > > digit it modifies, 
                > > > rather than a separate symbol. 
                > > >  
                > > > The L and S timers within a digitmap give specific 
                > > instruction as to which 
                > > > timer to run at that point in the digitmap.  While
allowed 
                > > in a range, I 
                > > > don't think they provide much value within a range
since 
                > they do not 
                > > > actually match anything.  For effective use, they
should be 
                > > outside the 
                > > > range. 
                > > >  
                > > > Kevin 
                > > > 
                > > > From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                > > > Sent: Monday, December 01, 2003 3:26 PM 
                > > > To: megaco@ietf.org 
                > > > Subject: [Megaco] Digit Maps: Long Duration
Modifier(Z), 
                > > Long Timers (L), & 
                > > > Short T imers (S) 
                > > > 
                > > > 
                > > >  
                > > > According to the syntax in RFCs 3015 & 3525 the long 
                > > duration modifier (Z), 
                > > > Long Timers (L), & Short Timers (S) in digit maps can 
                > > appear in a digit 
                > > > range.  For example (where Z is 1000ms): 
                > > >     "135[2Z46]" 
                > > >  
                > > > Is this valid?  If it is valid, does this mean that
the 
                > > fourth digit event 
                > > > must be either 2, 6 (held for any duration) or 4 held
for 1000 ms? 
                > > >  
                > > > How does long timer (L) and short timer (S) in a digit

                > range apply? 
                > > >  
                > > > --Stephen 
 


------_=_NextPart_001_01C3C330.36FD6AD0
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] Digit Maps: Long Duration Modifier(Z), Long Timers ( L), & Short T imers (S)</TITLE>

<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2>Kevin,</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff size=2>I 
think "ZX" and "Z[123]" should be valid.&nbsp; Your additions seem to prohibit 
these.&nbsp;&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff size=2>On a 
related&nbsp;topic should an empty range specification ("[]") be rejected as 
well, since nothing could possibly match it.</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2>--Stephen</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; 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> Wednesday, December 10, 
  2003 7:35 PM<BR><B>To:</B> Steve Cipolli; 'Troy Cauble'<BR><B>Cc:</B> 
  megaco@ietf.org<BR><B>Subject:</B> RE: [Megaco] Digit Maps: Long Duration 
  Modifier(Z), Long Timers ( L), &amp; Short T imers (S)<BR><BR></FONT></DIV>
  <P><FONT size=2>All,</FONT> </P>
  <P><FONT size=2>Here is some proposed text for this.&nbsp; I will include this 
  in the IG.&nbsp; Please let me know any changes that would be better.&nbsp; 
  New text is demarcated by &gt;&gt;&lt;&lt;.</FONT></P>
  <P><FONT size=2>7.1.14.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DigitMap 
  Syntax</FONT> <BR><FONT size=2>...</FONT> <BR><FONT size=2>In addition to 
  these event symbols, the string may contain "S" and "L" inter-event timing 
  specifiers and the "Z" duration modifier. "S" and "L" respectively indicate 
  that the MG should use the short (S) timer or the long (L) timer for 
  subsequent events, overriding the timing rules described above. If an explicit 
  timing specifier is in effect in one alternative event sequence, but none is 
  given in any other candidate alternative, the timer value set by the explicit 
  timing specifier must be used. If all sequences with explicit timing controls 
  are dropped from the candidate set, timing reverts to the default rules given 
  above. &gt;&gt;If used inside a range notation, the S and L specifiers shall 
  be ignored.&lt;&lt;&nbsp; Finally, if conflicting timing specifiers are in 
  effect in different alternative sequences, the long timer shall be 
  used.</FONT></P>
  <P><FONT size=2>A "Z" designates a long duration event: placed in front of the 
  symbol(s) designating the event(s) which satisfy a given digit position, it 
  indicates that that position is satisfied only if the duration of the event 
  exceeds the long-duration threshold. The value of this threshold is assumed to 
  be provisioned in the MG.&nbsp; &gt;&gt;If the Z specifier is not followed by 
  a digit (0-9 or A-K), then the MG shall reject the digitmap as invalid 
  protocol.&nbsp; When used in a range notation, the Z specifier applies solely 
  to the immediately following digit.&lt;&lt;</FONT></P>
  <P><FONT size=2>Kevin</FONT> <BR><FONT 
  size=2>________________________________</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>From: Steve Cipolli 
  [<A href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Sent: 
  Friday, December 05, 2003 1:09 PM</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>To: Boyle, Kevin 
  [NCRTP:3Z40:EXCH]; 'Troy Cauble'</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Cc: 
  megaco@ietf.org</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
  Timers ( L), &amp; Short T imers (S)</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>While I tend to 
  agree with most of the answers below, I don't see any of this specified in the 
  specification.&nbsp; If we can agree that the answers below are the correct 
  interpretation, then we still need clarification in the spec or implementors 
  guide.&nbsp; I'm still hoping the original author of this section of the spec 
  will clarify the original intention.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT size=2> 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>--Stephen</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>-----Original 
  Message-----</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>From: Kevin Boyle [<A 
  href="mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.com</A>]</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Sent: Tuesday, 
  December 02, 2003 3:18 PM</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>To: Steve Cipolli; 
  'Troy Cauble'</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Cc: 
  megaco@ietf.org</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Subject: RE: [Megaco] 
  Digit Maps: Long Duration Modifier(Z), Long Timers ( L), &amp; Short T imers 
  (S)</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Comments inline. 
  [KJBII] </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Kevin </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>-----Original 
  Message----- </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>From: Steve Cipolli 
  [<A href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Sent: Tuesday, 
  December 02, 2003 2:40 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>To: 'Troy Cauble'; 
  Boyle, Kevin [NCRTP:3Z40:EXCH] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Cc: megaco@ietf.org 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Subject: RE: [Megaco] 
  Digit Maps: Long Duration Modifier(Z), Long Timers ( L), &amp; Short T imers 
  (S) </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Perhaps I moved us off 
  track a bit.&nbsp; It is clear that there is more than one interpretation of 
  the specification with regard to L, S, and to a lesser extent Z.&nbsp; Can the 
  authors comment on what the intent of the specification was and then perhaps 
  we can reach some conclusion?</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Here is a partial list 
  of odd digitmaps that seem to defy interpretation: 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "123Z"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "Z" ignored or error? </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Z here has 
  nothing to modify.&nbsp; Error. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "123S"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "S" (or "L") ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] In this 
  instance, the digitmap switches to short interdigit timing after detecting 
  "123".&nbsp; So, neither. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "1ZZ23"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - First "Z" ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Because Z is 
  defined as modifying the following digit, and Z cannot modify Z, this should 
  be an error. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "1ZSSSSSSSSS23"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "Z" applied 
  to the "2" or ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] See 
  above.&nbsp; Error as Z cannot modify S (or L). </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2Z46]"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "Z" applied to "4" or to all in the range (246) or ignored or error? 
  </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Z applies 
  solely to the 4 here. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[246Z]79"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 
  "Z" applied to "7" or ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Nothing for Z 
  to modify.&nbsp; Error. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2S46]"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "S" (or "L") applied to all in range (246) or ignored or error? </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] This is the 
  root of our earlier discussion.&nbsp; L and S do not modify digits -- they 
  modify timing strategy for the digitmap at the time they are 
  encountered.&nbsp; [246] means "match 2, 4 or 6".&nbsp; So [2S46] means... 
  What exactly? "Match 2, short timeout, 4 or 6"?&nbsp; Or "match 2, 4 or 6 
  while running the short timer for this digit only"?&nbsp; Or "run the short 
  timer S after detecting 2, but not if 4 or 6 is detected"?&nbsp; If the string 
  were "135S[246]" then we would start using the short timer before looking for 
  2, 4 or 6.&nbsp; If it were "135[246]S", we would start using the short timer 
  AFTER matching 2, 4 or 6.&nbsp; But, with the S timer INSIDE the range, that 
  would indicate that the timer would have to fire to continue.&nbsp; For 
  instance, if the string were "135[2S46]79", that would seem to indicate that 
  if NO digit was detected for the duration of the short timer, then we should 
  continue with the string to find 7.&nbsp; This is a contrary usage to S and L 
  at any other point in a digitmap.&nbsp; I think S and L should be ignored 
  within ranges.&nbsp; If the MGC wants to use the S or L timer, then put them 
  outside the range.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2L4S6]"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "L" or "S" applied or both (somehow?) or ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] See above -- 
  the same arguments apply here.&nbsp; I would note that L would never get 
  "detected" here, since S would match first.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Thanks, 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>--Stephen </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; -----Original 
  Message----- </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; From: Steve 
  Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Sent: Monday, 
  December 01, 2003 8:01 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; To: 'Troy 
  Cauble'; Kevin Boyle </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Cc: 
  megaco@ietf.org </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Subject: RE: 
  [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Timers ( L), 
  &amp; Short T imers (S) </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Part of the 
  problem is the term "alternatives" is not clear.&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; The text in 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 7.1.14.3 says of 
  "alternatives": </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; A DigitMap, 
  according to this syntax, is defined either by a string or 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; by a list of 
  strings.&nbsp; Each string in the list is an alternative event 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; sequence, 
  specified either as a sequence of digit map symbols or as a 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; regular 
  expression of digit map symbols. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; My reading of 
  this is that "alternatives" are each string and not the 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; possible 
  sequences through a range, but admittedly this is not clear. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; The section 
  doesn't seem to explain other odd sequences like "123Z". 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Presumably the 
  "Z" is simply ignored although an error could also be 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; considered the 
  proper outcome. </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; I must say I 
  prefer an interpretation in which the number of possible 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; ways to perform 
  the same action is as close to 1 and possible. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Therefore, I'd 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; prefer to ban (or 
  at least ignore) "L" and "S" within ranges. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; --Stephen 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  -----Original Message----- 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; From: Troy 
  Cauble [<A href="mailto:troy@bell-labs.com">mailto:troy@bell-labs.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Sent: 
  Monday, December 01, 2003 6:33 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; To: Kevin 
  Boyle </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Cc: 
  megaco@ietf.org </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Subject: Re: 
  [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Timers ( L), 
  &amp; Short T imers (S) </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; I disagree 
  that "L" and "S" are meaningless within a range. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; "L" and "S" 
  are used to specify the timer used for "subsequent 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; events". 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; I would 
  argue that the "5" is a subsequent event in "[34L]5", just 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; as it is in 
  "[34]L5". </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; I would also 
  argue that the "4" in "[3L4]5" is NOT a "subsequent 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; event", 
  although one might debate the definition of "subsequent". 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; In summary, 
  I think "[L34]5", "[3L4]5", "[34L]5", and 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; "[34]L5" are all 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; the same. 
  (And the "L" is not meaningless.) 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Note that 
  section 7.1.14.3 does bother to specify what happens when 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; explicit 
  timing specifiers are only active in some "alternatives", 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; or when they 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; differ in 
  among alternatives -- the same timer value is used for all 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  alternatives. </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 7.1.14.3: 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt;&nbsp; &gt; 
  In addition to these event symbols, the string may contain "S" 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; and "L" 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt;&nbsp; &gt; 
  inter-event timing specifiers and the "Z" duration modifier. "S" 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; and "L" 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt;&nbsp; &gt; 
  respectively indicate that the MG should use the short (S) timer 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; or the&nbsp; 
  &gt; long (L) timer for subsequent events, overriding the 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; timing 
  rules&nbsp; &gt; described above. If an explicit timing specifier is 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; in effect in 
  one&nbsp; &gt; alternative event sequence, but none is given in 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; any other 
  candidate&nbsp; &gt; alternative, the timer value set by the 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; explicit 
  timing specifier must be&nbsp; &gt; used. If all sequences with 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; explicit 
  timing controls are dropped from the&nbsp; &gt; candidate set, 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; timing 
  reverts to the default rules given above. Finally,&nbsp; &gt; if 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; conflicting 
  timing specifiers are in effect in different alternative&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  sequences, the long timer shall be used. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; -troy 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Kevin Boyle 
  wrote: </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Since a 
  range means "match one of these", I would agree 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; with the 
  assessment </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; that L 
  and S are meaningless within a range. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Kevin 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  &gt;&nbsp;&nbsp; _____ </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; From: 
  Steve Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Sent: 
  Monday, December 01, 2003 5:22 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; To: 
  Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  Subject: RE: [Megaco] Digit Maps: Long Duration 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Modifier(Z), 
  Long Timers ( </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; L), 
  &amp; Short T imers (S) </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Thanks 
  for the feedback.&nbsp; </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Just to 
  make sure I understand the L and S cases: 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; They 
  are syntactically legal in a range specification, but 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; semantically 
  they </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; have no 
  effect.&nbsp; Correct? </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  --Stephen </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  -----Original Message----- 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; From: 
  Kevin Boyle [<A 
  href="mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Sent: 
  Monday, December 01, 2003 5:15 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; To: 
  Steve Cipolli; megaco@ietf.org 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  Subject: RE: [Megaco] Digit Maps: Long Duration 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Modifier(Z), 
  Long Timers ( </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; L), 
  &amp; Short T imers (S) </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Your 
  interpretation is correct.&nbsp; Because Z changes how a 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; digit is 
  matched, </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; it 
  makes sense within a range.&nbsp; Think of Z as part of the 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; digit it 
  modifies, </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; rather 
  than a separate symbol. </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; The L 
  and S timers within a digitmap give specific 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; instruction 
  as to which </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; timer 
  to run at that point in the digitmap.&nbsp; While allowed 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; in a range, 
  I </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; don't 
  think they provide much value within a range since 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; they do not 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  actually match anything.&nbsp; For effective use, they should be 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; outside the 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; range. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  Kevin&nbsp;</FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; From: 
  Steve Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Sent: 
  Monday, December 01, 2003 3:26 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; To: 
  megaco@ietf.org </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Long Timers 
  (L), &amp; </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Short T 
  imers (S) </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  According to the syntax in RFCs 3015 &amp; 3525 the long 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; duration 
  modifier (Z), </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Long 
  Timers (L), &amp; Short Timers (S) in digit maps can 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; appear in a 
  digit </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  range.&nbsp; For example (where Z is 1000ms): 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp; "135[2Z46]" 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Is this 
  valid?&nbsp; If it is valid, does this mean that the 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; fourth digit 
  event </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; must be 
  either 2, 6 (held for any duration) or 4 held for 1000 ms? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; How 
  does long timer (L) and short timer (S) in a digit 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; range apply? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  --Stephen&nbsp;</FONT><BR>&nbsp;</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3C330.36FD6AD0--


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


From exim@www1.ietf.org  Mon Dec 15 12:45:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18020
	for <megaco-archive@odin.ietf.org>; Mon, 15 Dec 2003 12:45:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVwmK-0006Jj-Vl
	for megaco-archive@odin.ietf.org; Mon, 15 Dec 2003 12:45:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFHj8WJ024280
	for megaco-archive@odin.ietf.org; Mon, 15 Dec 2003 12:45:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVwmK-0006JX-D4
	for megaco-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 12:45:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17988
	for <megaco-web-archive@ietf.org>; Mon, 15 Dec 2003 12:45:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVwmI-0001Rg-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 12:45:06 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVwmH-0001Rd-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 12:45:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVwmF-0006Il-Pn; Mon, 15 Dec 2003 12:45:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVwS4-0005Ue-Cn
	for megaco@optimus.ietf.org; Mon, 15 Dec 2003 12:24:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17325
	for <megaco@ietf.org>; Mon, 15 Dec 2003 12:24:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVwS2-00015b-00
	for megaco@ietf.org; Mon, 15 Dec 2003 12:24:10 -0500
Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVwS0-00015Y-00
	for megaco@ietf.org; Mon, 15 Dec 2003 12:24:08 -0500
Received: from radvpost.radvision.com [192.168.216.29]
	by radvpost.radvision.com
	with XWall v3.28 ;
	Mon, 15 Dec 2003 12:23:55 -0500
Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19)
	id <V4QZTHW0>; Mon, 15 Dec 2003 12:23:55 -0500
Message-ID: <A3851AA1B761E944912B20D1E95A7EFE0B0A79@radvpost.radvision.com>
From: Steve Cipolli <SCipolli@radvision.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        Steve Cipolli
	 <SCipolli@radvision.com>,
        "'Troy Cauble'" <troy@bell-labs.com>
Cc: "'megaco@ietf.org'" <megaco@ietf.org>
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
	 	 L), & Short T imers (S)
Date: Mon, 15 Dec 2003 12:23:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C330.36FD6AD0"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3C330.36FD6AD0
Content-Type: text/plain;
	charset="iso-8859-1"

Kevin,
 
I think "ZX" and "Z[123]" should be valid.  Your additions seem to prohibit
these.  
 
On a related topic should an empty range specification ("[]") be rejected as
well, since nothing could possibly match it.
 
--Stephen
 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Wednesday, December 10, 2003 7:35 PM
To: Steve Cipolli; 'Troy Cauble'
Cc: megaco@ietf.org
Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long Timers (
L), & Short T imers (S)



All, 

Here is some proposed text for this.  I will include this in the IG.  Please
let me know any changes that would be better.  New text is demarcated by
>><<.

7.1.14.3        DigitMap Syntax 
... 
In addition to these event symbols, the string may contain "S" and "L"
inter-event timing specifiers and the "Z" duration modifier. "S" and "L"
respectively indicate that the MG should use the short (S) timer or the long
(L) timer for subsequent events, overriding the timing rules described
above. If an explicit timing specifier is in effect in one alternative event
sequence, but none is given in any other candidate alternative, the timer
value set by the explicit timing specifier must be used. If all sequences
with explicit timing controls are dropped from the candidate set, timing
reverts to the default rules given above. >>If used inside a range notation,
the S and L specifiers shall be ignored.<<  Finally, if conflicting timing
specifiers are in effect in different alternative sequences, the long timer
shall be used.

A "Z" designates a long duration event: placed in front of the symbol(s)
designating the event(s) which satisfy a given digit position, it indicates
that that position is satisfied only if the duration of the event exceeds
the long-duration threshold. The value of this threshold is assumed to be
provisioned in the MG.  >>If the Z specifier is not followed by a digit (0-9
or A-K), then the MG shall reject the digitmap as invalid protocol.  When
used in a range notation, the Z specifier applies solely to the immediately
following digit.<<

Kevin 
________________________________ 

        From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
        Sent: Friday, December 05, 2003 1:09 PM 
        To: Boyle, Kevin [NCRTP:3Z40:EXCH]; 'Troy Cauble' 
        Cc: megaco@ietf.org 
        Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long
Timers ( L), & Short T imers (S) 
        
        
        While I tend to agree with most of the answers below, I don't see
any of this specified in the specification.  If we can agree that the
answers below are the correct interpretation, then we still need
clarification in the spec or implementors guide.  I'm still hoping the
original author of this section of the spec will clarify the original
intention.

         
        --Stephen 

                -----Original Message----- 
                From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 
                Sent: Tuesday, December 02, 2003 3:18 PM 
                To: Steve Cipolli; 'Troy Cauble' 
                Cc: megaco@ietf.org 
                Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 
                
                

                Comments inline. [KJBII] 

                Kevin 

                -----Original Message----- 
                From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                Sent: Tuesday, December 02, 2003 2:40 PM 
                To: 'Troy Cauble'; Boyle, Kevin [NCRTP:3Z40:EXCH] 
                Cc: megaco@ietf.org 
                Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z),
Long Timers ( L), & Short T imers (S) 

                Perhaps I moved us off track a bit.  It is clear that there
is more than one interpretation of the specification with regard to L, S,
and to a lesser extent Z.  Can the authors comment on what the intent of the
specification was and then perhaps we can reach some conclusion?

                Here is a partial list of odd digitmaps that seem to defy
interpretation: 
                        "123Z"                          - "Z" ignored or
error? 
                [KJBII] Z here has nothing to modify.  Error. 

                        "123S"                  - "S" (or "L") ignored or
error? 
                [KJBII] In this instance, the digitmap switches to short
interdigit timing after detecting "123".  So, neither. 

                        "1ZZ23"                 - First "Z" ignored or
error? 
                [KJBII] Because Z is defined as modifying the following
digit, and Z cannot modify Z, this should be an error. 

                        "1ZSSSSSSSSS23"         - "Z" applied to the "2" or
ignored or error? 
                [KJBII] See above.  Error as Z cannot modify S (or L). 

                        "135[2Z46]"                     - "Z" applied to "4"
or to all in the range (246) or ignored or error? 

                [KJBII] Z applies solely to the 4 here. 

                        "135[246Z]79"           - "Z" applied to "7" or
ignored or error? 
                [KJBII] Nothing for Z to modify.  Error. 

                        "135[2S46]"                     - "S" (or "L")
applied to all in range (246) or ignored or error? 

                [KJBII] This is the root of our earlier discussion.  L and S
do not modify digits -- they modify timing strategy for the digitmap at the
time they are encountered.  [246] means "match 2, 4 or 6".  So [2S46]
means... What exactly? "Match 2, short timeout, 4 or 6"?  Or "match 2, 4 or
6 while running the short timer for this digit only"?  Or "run the short
timer S after detecting 2, but not if 4 or 6 is detected"?  If the string
were "135S[246]" then we would start using the short timer before looking
for 2, 4 or 6.  If it were "135[246]S", we would start using the short timer
AFTER matching 2, 4 or 6.  But, with the S timer INSIDE the range, that
would indicate that the timer would have to fire to continue.  For instance,
if the string were "135[2S46]79", that would seem to indicate that if NO
digit was detected for the duration of the short timer, then we should
continue with the string to find 7.  This is a contrary usage to S and L at
any other point in a digitmap.  I think S and L should be ignored within
ranges.  If the MGC wants to use the S or L timer, then put them outside the
range.

                        "135[2L4S6]"            - "L" or "S" applied or both
(somehow?) or ignored or error? 
                [KJBII] See above -- the same arguments apply here.  I would
note that L would never get "detected" here, since S would match first.

                Thanks, 
                --Stephen 

                        

                > -----Original Message----- 
                > From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                > Sent: Monday, December 01, 2003 8:01 PM 
                > To: 'Troy Cauble'; Kevin Boyle 
                > Cc: megaco@ietf.org 
                > Subject: RE: [Megaco] Digit Maps: Long Duration
Modifier(Z), Long 
                > Timers ( L), & Short T imers (S) 
                > 
                > 
                > Part of the problem is the term "alternatives" is not
clear.  
                > The text in 
                > 7.1.14.3 says of "alternatives": 
                > A DigitMap, according to this syntax, is defined either by
a string or 
                > by a list of strings.  Each string in the list is an
alternative event 
                > sequence, specified either as a sequence of digit map
symbols or as a 
                > regular expression of digit map symbols. 
                > 
                > My reading of this is that "alternatives" are each string
and not the 
                > possible sequences through a range, but admittedly this is
not clear. 
                > 
                > The section doesn't seem to explain other odd sequences
like "123Z". 
                > Presumably the "Z" is simply ignored although an error
could also be 
                > considered the proper outcome. 
                > 
                > I must say I prefer an interpretation in which the number
of possible 
                > ways to perform the same action is as close to 1 and
possible. 
                > Therefore, I'd 
                > prefer to ban (or at least ignore) "L" and "S" within
ranges. 
                > 
                > --Stephen 
                > 
                > > -----Original Message----- 
                > > From: Troy Cauble [ mailto:troy@bell-labs.com
<mailto:troy@bell-labs.com> ] 
                > > Sent: Monday, December 01, 2003 6:33 PM 
                > > To: Kevin Boyle 
                > > Cc: megaco@ietf.org 
                > > Subject: Re: [Megaco] Digit Maps: Long Duration
Modifier(Z), Long 
                > > Timers ( L), & Short T imers (S) 
                > > 
                > > 
                > > 
                > > 
                > > I disagree that "L" and "S" are meaningless within a
range. 
                > > 
                > > "L" and "S" are used to specify the timer used for
"subsequent 
                > > events". 
                > > 
                > > I would argue that the "5" is a subsequent event in
"[34L]5", just 
                > > as it is in "[34]L5". 
                > > 
                > > I would also argue that the "4" in "[3L4]5" is NOT a
"subsequent 
                > > event", although one might debate the definition of
"subsequent". 
                > > 
                > > In summary, I think "[L34]5", "[3L4]5", "[34L]5", and 
                > "[34]L5" are all 
                > > the same. (And the "L" is not meaningless.) 
                > > 
                > > 
                > > Note that section 7.1.14.3 does bother to specify what
happens when 
                > > explicit timing specifiers are only active in some
"alternatives", 
                > or when they 
                > > differ in among alternatives -- the same timer value is
used for all 
                > > alternatives. 
                > > 
                > > 
                > > 7.1.14.3: 
                > > 
                > >  > In addition to these event symbols, the string may
contain "S" 
                > > and "L" 
                > >  > inter-event timing specifiers and the "Z" duration
modifier. "S" 
                > > and "L" 
                > >  > respectively indicate that the MG should use the
short (S) timer 
                > > or the  > long (L) timer for subsequent events,
overriding the 
                > > timing rules  > described above. If an explicit timing
specifier is 
                > > in effect in one  > alternative event sequence, but none
is given in 
                > > any other candidate  > alternative, the timer value set
by the 
                > > explicit timing specifier must be  > used. If all
sequences with 
                > > explicit timing controls are dropped from the  >
candidate set, 
                > > timing reverts to the default rules given above.
Finally,  > if 
                > > conflicting timing specifiers are in effect in different
alternative  
                > > > sequences, the long timer shall be used. 
                > > 
                > > 
                > > -troy 
                > > 
                > > 
                > > 
                > > Kevin Boyle wrote: 
                > > 
                > > > Since a range means "match one of these", I would
agree 
                > > with the assessment 
                > > > that L and S are meaningless within a range. 
                > > >  
                > > > Kevin 
                > > > 
                > > > 
                > > >   _____ 
                > > > 
                > > > From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                > > > Sent: Monday, December 01, 2003 5:22 PM 
                > > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org 
                > > > Subject: RE: [Megaco] Digit Maps: Long Duration 
                > > Modifier(Z), Long Timers ( 
                > > > L), & Short T imers (S) 
                > > > 
                > > > 
                > > > Thanks for the feedback.  
                > > >  
                > > > Just to make sure I understand the L and S cases: 
                > > > They are syntactically legal in a range specification,
but 
                > > semantically they 
                > > > have no effect.  Correct? 
                > > >  
                > > > --Stephen 
                > > > 
                > > > -----Original Message----- 
                > > > From: Kevin Boyle [ mailto:kboyle@nortelnetworks.com
<mailto:kboyle@nortelnetworks.com> ] 
                > > > Sent: Monday, December 01, 2003 5:15 PM 
                > > > To: Steve Cipolli; megaco@ietf.org 
                > > > Subject: RE: [Megaco] Digit Maps: Long Duration 
                > > Modifier(Z), Long Timers ( 
                > > > L), & Short T imers (S) 
                > > > 
                > > > 
                > > > Your interpretation is correct.  Because Z changes how
a 
                > > digit is matched, 
                > > > it makes sense within a range.  Think of Z as part of
the 
                > > digit it modifies, 
                > > > rather than a separate symbol. 
                > > >  
                > > > The L and S timers within a digitmap give specific 
                > > instruction as to which 
                > > > timer to run at that point in the digitmap.  While
allowed 
                > > in a range, I 
                > > > don't think they provide much value within a range
since 
                > they do not 
                > > > actually match anything.  For effective use, they
should be 
                > > outside the 
                > > > range. 
                > > >  
                > > > Kevin 
                > > > 
                > > > From: Steve Cipolli [ mailto:SCipolli@radvision.com
<mailto:SCipolli@radvision.com> ] 
                > > > Sent: Monday, December 01, 2003 3:26 PM 
                > > > To: megaco@ietf.org 
                > > > Subject: [Megaco] Digit Maps: Long Duration
Modifier(Z), 
                > > Long Timers (L), & 
                > > > Short T imers (S) 
                > > > 
                > > > 
                > > >  
                > > > According to the syntax in RFCs 3015 & 3525 the long 
                > > duration modifier (Z), 
                > > > Long Timers (L), & Short Timers (S) in digit maps can 
                > > appear in a digit 
                > > > range.  For example (where Z is 1000ms): 
                > > >     "135[2Z46]" 
                > > >  
                > > > Is this valid?  If it is valid, does this mean that
the 
                > > fourth digit event 
                > > > must be either 2, 6 (held for any duration) or 4 held
for 1000 ms? 
                > > >  
                > > > How does long timer (L) and short timer (S) in a digit

                > range apply? 
                > > >  
                > > > --Stephen 
 


------_=_NextPart_001_01C3C330.36FD6AD0
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] Digit Maps: Long Duration Modifier(Z), Long Timers ( L), & Short T imers (S)</TITLE>

<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2>Kevin,</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff size=2>I 
think "ZX" and "Z[123]" should be valid.&nbsp; Your additions seem to prohibit 
these.&nbsp;&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff size=2>On a 
related&nbsp;topic should an empty range specification ("[]") be rejected as 
well, since nothing could possibly match it.</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2>--Stephen</FONT></SPAN></DIV>
<DIV><SPAN class=261132422-12122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; 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> Wednesday, December 10, 
  2003 7:35 PM<BR><B>To:</B> Steve Cipolli; 'Troy Cauble'<BR><B>Cc:</B> 
  megaco@ietf.org<BR><B>Subject:</B> RE: [Megaco] Digit Maps: Long Duration 
  Modifier(Z), Long Timers ( L), &amp; Short T imers (S)<BR><BR></FONT></DIV>
  <P><FONT size=2>All,</FONT> </P>
  <P><FONT size=2>Here is some proposed text for this.&nbsp; I will include this 
  in the IG.&nbsp; Please let me know any changes that would be better.&nbsp; 
  New text is demarcated by &gt;&gt;&lt;&lt;.</FONT></P>
  <P><FONT size=2>7.1.14.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DigitMap 
  Syntax</FONT> <BR><FONT size=2>...</FONT> <BR><FONT size=2>In addition to 
  these event symbols, the string may contain "S" and "L" inter-event timing 
  specifiers and the "Z" duration modifier. "S" and "L" respectively indicate 
  that the MG should use the short (S) timer or the long (L) timer for 
  subsequent events, overriding the timing rules described above. If an explicit 
  timing specifier is in effect in one alternative event sequence, but none is 
  given in any other candidate alternative, the timer value set by the explicit 
  timing specifier must be used. If all sequences with explicit timing controls 
  are dropped from the candidate set, timing reverts to the default rules given 
  above. &gt;&gt;If used inside a range notation, the S and L specifiers shall 
  be ignored.&lt;&lt;&nbsp; Finally, if conflicting timing specifiers are in 
  effect in different alternative sequences, the long timer shall be 
  used.</FONT></P>
  <P><FONT size=2>A "Z" designates a long duration event: placed in front of the 
  symbol(s) designating the event(s) which satisfy a given digit position, it 
  indicates that that position is satisfied only if the duration of the event 
  exceeds the long-duration threshold. The value of this threshold is assumed to 
  be provisioned in the MG.&nbsp; &gt;&gt;If the Z specifier is not followed by 
  a digit (0-9 or A-K), then the MG shall reject the digitmap as invalid 
  protocol.&nbsp; When used in a range notation, the Z specifier applies solely 
  to the immediately following digit.&lt;&lt;</FONT></P>
  <P><FONT size=2>Kevin</FONT> <BR><FONT 
  size=2>________________________________</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>From: Steve Cipolli 
  [<A href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Sent: 
  Friday, December 05, 2003 1:09 PM</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>To: Boyle, Kevin 
  [NCRTP:3Z40:EXCH]; 'Troy Cauble'</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Cc: 
  megaco@ietf.org</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>Subject: RE: [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
  Timers ( L), &amp; Short T imers (S)</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>While I tend to 
  agree with most of the answers below, I don't see any of this specified in the 
  specification.&nbsp; If we can agree that the answers below are the correct 
  interpretation, then we still need clarification in the spec or implementors 
  guide.&nbsp; I'm still hoping the original author of this section of the spec 
  will clarify the original intention.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT size=2> 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>--Stephen</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>-----Original 
  Message-----</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>From: Kevin Boyle [<A 
  href="mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.com</A>]</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Sent: Tuesday, 
  December 02, 2003 3:18 PM</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>To: Steve Cipolli; 
  'Troy Cauble'</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Cc: 
  megaco@ietf.org</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Subject: RE: [Megaco] 
  Digit Maps: Long Duration Modifier(Z), Long Timers ( L), &amp; Short T imers 
  (S)</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Comments inline. 
  [KJBII] </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Kevin </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>-----Original 
  Message----- </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>From: Steve Cipolli 
  [<A href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Sent: Tuesday, 
  December 02, 2003 2:40 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>To: 'Troy Cauble'; 
  Boyle, Kevin [NCRTP:3Z40:EXCH] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Cc: megaco@ietf.org 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Subject: RE: [Megaco] 
  Digit Maps: Long Duration Modifier(Z), Long Timers ( L), &amp; Short T imers 
  (S) </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Perhaps I moved us off 
  track a bit.&nbsp; It is clear that there is more than one interpretation of 
  the specification with regard to L, S, and to a lesser extent Z.&nbsp; Can the 
  authors comment on what the intent of the specification was and then perhaps 
  we can reach some conclusion?</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Here is a partial list 
  of odd digitmaps that seem to defy interpretation: 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "123Z"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "Z" ignored or error? </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Z here has 
  nothing to modify.&nbsp; Error. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "123S"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "S" (or "L") ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] In this 
  instance, the digitmap switches to short interdigit timing after detecting 
  "123".&nbsp; So, neither. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "1ZZ23"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - First "Z" ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Because Z is 
  defined as modifying the following digit, and Z cannot modify Z, this should 
  be an error. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "1ZSSSSSSSSS23"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - "Z" applied 
  to the "2" or ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] See 
  above.&nbsp; Error as Z cannot modify S (or L). </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2Z46]"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "Z" applied to "4" or to all in the range (246) or ignored or error? 
  </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Z applies 
  solely to the 4 here. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[246Z]79"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 
  "Z" applied to "7" or ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] Nothing for Z 
  to modify.&nbsp; Error. </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2S46]"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "S" (or "L") applied to all in range (246) or ignored or error? </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] This is the 
  root of our earlier discussion.&nbsp; L and S do not modify digits -- they 
  modify timing strategy for the digitmap at the time they are 
  encountered.&nbsp; [246] means "match 2, 4 or 6".&nbsp; So [2S46] means... 
  What exactly? "Match 2, short timeout, 4 or 6"?&nbsp; Or "match 2, 4 or 6 
  while running the short timer for this digit only"?&nbsp; Or "run the short 
  timer S after detecting 2, but not if 4 or 6 is detected"?&nbsp; If the string 
  were "135S[246]" then we would start using the short timer before looking for 
  2, 4 or 6.&nbsp; If it were "135[246]S", we would start using the short timer 
  AFTER matching 2, 4 or 6.&nbsp; But, with the S timer INSIDE the range, that 
  would indicate that the timer would have to fire to continue.&nbsp; For 
  instance, if the string were "135[2S46]79", that would seem to indicate that 
  if NO digit was detected for the duration of the short timer, then we should 
  continue with the string to find 7.&nbsp; This is a contrary usage to S and L 
  at any other point in a digitmap.&nbsp; I think S and L should be ignored 
  within ranges.&nbsp; If the MGC wants to use the S or L timer, then put them 
  outside the range.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  "135[2L4S6]"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  - "L" or "S" applied or both (somehow?) or ignored or error? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>[KJBII] See above -- 
  the same arguments apply here.&nbsp; I would note that L would never get 
  "detected" here, since S would match first.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Thanks, 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>--Stephen </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; -----Original 
  Message----- </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; From: Steve 
  Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Sent: Monday, 
  December 01, 2003 8:01 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; To: 'Troy 
  Cauble'; Kevin Boyle </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Cc: 
  megaco@ietf.org </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Subject: RE: 
  [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Timers ( L), 
  &amp; Short T imers (S) </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Part of the 
  problem is the term "alternatives" is not clear.&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; The text in 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 7.1.14.3 says of 
  "alternatives": </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; A DigitMap, 
  according to this syntax, is defined either by a string or 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; by a list of 
  strings.&nbsp; Each string in the list is an alternative event 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; sequence, 
  specified either as a sequence of digit map symbols or as a 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; regular 
  expression of digit map symbols. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; My reading of 
  this is that "alternatives" are each string and not the 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; possible 
  sequences through a range, but admittedly this is not clear. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; The section 
  doesn't seem to explain other odd sequences like "123Z". 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Presumably the 
  "Z" is simply ignored although an error could also be 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; considered the 
  proper outcome. </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; I must say I 
  prefer an interpretation in which the number of possible 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; ways to perform 
  the same action is as close to 1 and possible. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; Therefore, I'd 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; prefer to ban (or 
  at least ignore) "L" and "S" within ranges. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; --Stephen 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  -----Original Message----- 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; From: Troy 
  Cauble [<A href="mailto:troy@bell-labs.com">mailto:troy@bell-labs.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Sent: 
  Monday, December 01, 2003 6:33 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; To: Kevin 
  Boyle </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Cc: 
  megaco@ietf.org </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Subject: Re: 
  [Megaco] Digit Maps: Long Duration Modifier(Z), Long 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Timers ( L), 
  &amp; Short T imers (S) </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; I disagree 
  that "L" and "S" are meaningless within a range. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; "L" and "S" 
  are used to specify the timer used for "subsequent 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; events". 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; I would 
  argue that the "5" is a subsequent event in "[34L]5", just 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; as it is in 
  "[34]L5". </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; I would also 
  argue that the "4" in "[3L4]5" is NOT a "subsequent 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; event", 
  although one might debate the definition of "subsequent". 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; In summary, 
  I think "[L34]5", "[3L4]5", "[34L]5", and 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; "[34]L5" are all 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; the same. 
  (And the "L" is not meaningless.) 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Note that 
  section 7.1.14.3 does bother to specify what happens when 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; explicit 
  timing specifiers are only active in some "alternatives", 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; or when they 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; differ in 
  among alternatives -- the same timer value is used for all 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  alternatives. </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 7.1.14.3: 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt;&nbsp; &gt; 
  In addition to these event symbols, the string may contain "S" 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; and "L" 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt;&nbsp; &gt; 
  inter-event timing specifiers and the "Z" duration modifier. "S" 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; and "L" 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt;&nbsp; &gt; 
  respectively indicate that the MG should use the short (S) timer 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; or the&nbsp; 
  &gt; long (L) timer for subsequent events, overriding the 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; timing 
  rules&nbsp; &gt; described above. If an explicit timing specifier is 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; in effect in 
  one&nbsp; &gt; alternative event sequence, but none is given in 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; any other 
  candidate&nbsp; &gt; alternative, the timer value set by the 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; explicit 
  timing specifier must be&nbsp; &gt; used. If all sequences with 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; explicit 
  timing controls are dropped from the&nbsp; &gt; candidate set, 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; timing 
  reverts to the default rules given above. Finally,&nbsp; &gt; if 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; conflicting 
  timing specifiers are in effect in different alternative&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  sequences, the long timer shall be used. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; -troy 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Kevin Boyle 
  wrote: </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Since a 
  range means "match one of these", I would agree 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; with the 
  assessment </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; that L 
  and S are meaningless within a range. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Kevin 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  &gt;&nbsp;&nbsp; _____ </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; From: 
  Steve Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Sent: 
  Monday, December 01, 2003 5:22 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; To: 
  Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  Subject: RE: [Megaco] Digit Maps: Long Duration 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Modifier(Z), 
  Long Timers ( </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; L), 
  &amp; Short T imers (S) </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Thanks 
  for the feedback.&nbsp; </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Just to 
  make sure I understand the L and S cases: 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; They 
  are syntactically legal in a range specification, but 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; semantically 
  they </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; have no 
  effect.&nbsp; Correct? </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  --Stephen </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  -----Original Message----- 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; From: 
  Kevin Boyle [<A 
  href="mailto:kboyle@nortelnetworks.com">mailto:kboyle@nortelnetworks.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Sent: 
  Monday, December 01, 2003 5:15 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; To: 
  Steve Cipolli; megaco@ietf.org 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  Subject: RE: [Megaco] Digit Maps: Long Duration 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Modifier(Z), 
  Long Timers ( </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; L), 
  &amp; Short T imers (S) </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Your 
  interpretation is correct.&nbsp; Because Z changes how a 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; digit is 
  matched, </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; it 
  makes sense within a range.&nbsp; Think of Z as part of the 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; digit it 
  modifies, </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; rather 
  than a separate symbol. </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; The L 
  and S timers within a digitmap give specific 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; instruction 
  as to which </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; timer 
  to run at that point in the digitmap.&nbsp; While allowed 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; in a range, 
  I </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; don't 
  think they provide much value within a range since 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; they do not 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  actually match anything.&nbsp; For effective use, they should be 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; outside the 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; range. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  Kevin&nbsp;</FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; From: 
  Steve Cipolli [<A 
  href="mailto:SCipolli@radvision.com">mailto:SCipolli@radvision.com</A>] 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Sent: 
  Monday, December 01, 2003 3:26 PM 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; To: 
  megaco@ietf.org </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  Subject: [Megaco] Digit Maps: Long Duration Modifier(Z), 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; Long Timers 
  (L), &amp; </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Short T 
  imers (S) </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  According to the syntax in RFCs 3015 &amp; 3525 the long 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; duration 
  modifier (Z), </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Long 
  Timers (L), &amp; Short Timers (S) in digit maps can 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; appear in a 
  digit </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  range.&nbsp; For example (where Z is 1000ms): 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp; "135[2Z46]" 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; Is this 
  valid?&nbsp; If it is valid, does this mean that the 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; fourth digit 
  event </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; must be 
  either 2, 6 (held for any duration) or 4 held for 1000 ms? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; How 
  does long timer (L) and short timer (S) in a digit 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; range apply? 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt;&nbsp; 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&gt; &gt; &gt; 
  --Stephen&nbsp;</FONT><BR>&nbsp;</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3C330.36FD6AD0--


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



From megaco-admin@ietf.org  Mon Dec 15 16:04:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29714
	for <megaco-archive@lists.ietf.org>; Mon, 15 Dec 2003 16:04:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVzsn-0006v3-Ie; Mon, 15 Dec 2003 16:04:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVzs9-0006uc-21
	for megaco@optimus.ietf.org; Mon, 15 Dec 2003 16:03:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29693
	for <megaco@ietf.org>; Mon, 15 Dec 2003 16:03:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVzs7-0000Uw-00
	for megaco@ietf.org; Mon, 15 Dec 2003 16:03:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AVzs6-0000Up-00
	for megaco@ietf.org; Mon, 15 Dec 2003 16:03:19 -0500
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVzs6-0000Tv-00
	for megaco@ietf.org; Mon, 15 Dec 2003 16:03:18 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBFL1TJ21124
	for <megaco@ietf.org>; Mon, 15 Dec 2003 15:01:59 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA01454; Mon, 15 Dec 2003 16:01:24 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA01450; Mon, 15 Dec 2003 16:01:23 -0500 (EST)
Message-ID: <3FDE2122.8010703@bell-labs.com>
Date: Mon, 15 Dec 2003 16:01:22 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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] wildcarding question
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit


Regarding 6.6.1 in the IG.

The example would have been more informative if it matched two or more
terminations.

Should
	Context = 1 { Command=*{Descriptor/s}}

return
	Context = 1 {Command=t1/1{Descriptor/s},
	             Command=t2/1{Descriptor/s}}
or
	Context = 1 {Command=t1/1{Descriptor/s}}
	Context = 1 {Command=t2/1{Descriptor/s}}

The text says "identical to repeating the command with each of the
TerminationIDs", so I think the former is correct, but I'm not positive.



Also, regarding 6.6.4, wildcard responses:
A wildcard resonse request happens at the command level.
What if wildcard response commands and non-wildcard response commands
exist in the same request context?

	Context = * { Command=*{Descriptor/s},
	              W-Command=*{Descriptor/s},
	              Command=*{Descriptor/s}}

-troy


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


From exim@www1.ietf.org  Mon Dec 15 16:04:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29733
	for <megaco-archive@odin.ietf.org>; Mon, 15 Dec 2003 16:04:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVzst-0006vt-QI
	for megaco-archive@odin.ietf.org; Mon, 15 Dec 2003 16:04:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFL47op026648
	for megaco-archive@odin.ietf.org; Mon, 15 Dec 2003 16:04:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVzst-0006vi-9f
	for megaco-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 16:04:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29705
	for <megaco-web-archive@ietf.org>; Mon, 15 Dec 2003 16:04:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVzsr-0000Vc-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 16:04:05 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AVzsq-0000VS-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 16:04:05 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVzsq-0000VO-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 16:04:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVzsn-0006v3-Ie; Mon, 15 Dec 2003 16:04:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVzs9-0006uc-21
	for megaco@optimus.ietf.org; Mon, 15 Dec 2003 16:03:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29693
	for <megaco@ietf.org>; Mon, 15 Dec 2003 16:03:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVzs7-0000Uw-00
	for megaco@ietf.org; Mon, 15 Dec 2003 16:03:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AVzs6-0000Up-00
	for megaco@ietf.org; Mon, 15 Dec 2003 16:03:19 -0500
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVzs6-0000Tv-00
	for megaco@ietf.org; Mon, 15 Dec 2003 16:03:18 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBFL1TJ21124
	for <megaco@ietf.org>; Mon, 15 Dec 2003 15:01:59 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA01454; Mon, 15 Dec 2003 16:01:24 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA01450; Mon, 15 Dec 2003 16:01:23 -0500 (EST)
Message-ID: <3FDE2122.8010703@bell-labs.com>
Date: Mon, 15 Dec 2003 16:01:22 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] wildcarding question
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: 7bit


Regarding 6.6.1 in the IG.

The example would have been more informative if it matched two or more
terminations.

Should
	Context = 1 { Command=*{Descriptor/s}}

return
	Context = 1 {Command=t1/1{Descriptor/s},
	             Command=t2/1{Descriptor/s}}
or
	Context = 1 {Command=t1/1{Descriptor/s}}
	Context = 1 {Command=t2/1{Descriptor/s}}

The text says "identical to repeating the command with each of the
TerminationIDs", so I think the former is correct, but I'm not positive.



Also, regarding 6.6.4, wildcard responses:
A wildcard resonse request happens at the command level.
What if wildcard response commands and non-wildcard response commands
exist in the same request context?

	Context = * { Command=*{Descriptor/s},
	              W-Command=*{Descriptor/s},
	              Command=*{Descriptor/s}}

-troy


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



From megaco-admin@ietf.org  Mon Dec 15 21:29:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12688
	for <megaco-archive@lists.ietf.org>; Mon, 15 Dec 2003 21:29:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW4xJ-00027O-1a; Mon, 15 Dec 2003 21:29:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW4x7-00026v-DC
	for megaco@optimus.ietf.org; Mon, 15 Dec 2003 21:28:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12657
	for <megaco@ietf.org>; Mon, 15 Dec 2003 21:28:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW4x4-00044j-00
	for megaco@ietf.org; Mon, 15 Dec 2003 21:28:46 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AW4x3-00044b-00
	for megaco@ietf.org; Mon, 15 Dec 2003 21:28:46 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW4x3-00043g-00
	for megaco@ietf.org; Mon, 15 Dec 2003 21:28:45 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBFLR8v17721;
	Tue, 16 Dec 2003 08:27:08 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.228]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5LZD0P; Tue, 16 Dec 2003 08:28:51 +1100
Message-ID: <3FDE2721.8020406@ericsson.com>
Date: Tue, 16 Dec 2003 08:26:57 +1100
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: assingh@hss.hns.com
CC: megaco@ietf.org
Subject: Re: [Megaco] Regarding Context Audit
References: <OF6F900B29.DB3DD9A8-ON65256DFD.00320E37@hss.hns.com>
In-Reply-To: <OF6F900B29.DB3DD9A8-ON65256DFD.00320E37@hss.hns.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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=EXCUSE_16 autolearn=no 
	version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hello Ashish,

This is a problem in the ABNF as there is no way of returning a empty context 
audit. I am currently preparing a contribution for Sg16 discussing the problem. 
Will post to the list a link to the document when I've finished.

Christian

assingh@hss.hns.com wrote:

> 
> 
> 
> 
> 
> Hi List,
> 
> I have a doubt in context audit grammer.
> 
> Assume that there is an active context which is not emergency. Now a
> context audit request comes with only emergency token
> MEGACO/1 [10.10.1.1]:2100 Transaction=1100000 {Context = 1 { ContextAudit
> {Emergency} } }
> 
> As per the grammer
> Action reply should have error descriptor or command reply. In command
> reply we can send context properties whose grammer is
> contextProperties    = contextProperty *(COMMA contextProperty)
> contextProperty    = (topologyDescriptor / priority / EmergencyToken)
> Now here it is mandatory to send one of these tokens in context properties.
> It is not possible to send emergency token in this case as context is not
> emergency and the emergency token does not have a way to specify the value
> as TRUE or FALSE.
> 
> What should be returned in this case ? Is there a way to send an empty
> context audit reply.
> 
> Thanks in advance
> Ashish
> 
> www.hssworld.com
> 
> 
> "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
> (HSS) and is intended solely for the use of the individual to whom it is
> addressed. It may contain  privileged or confidential information and
> should not be circulated or used for any purpose other than for what it is
> intended. If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient, you are
> notified that you are strictly prohibited from using, copying, altering, or
> disclosing the contents of this message. HSS accepts no responsibility for
> loss or damage arising from the use of the information transmitted by this
> email including damage from virus."
> 
> 
> _______________________________________________
> 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 exim@www1.ietf.org  Mon Dec 15 21:29:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12705
	for <megaco-archive@odin.ietf.org>; Mon, 15 Dec 2003 21:29:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW4xN-00028I-F0
	for megaco-archive@odin.ietf.org; Mon, 15 Dec 2003 21:29:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBG2T5H6008194
	for megaco-archive@odin.ietf.org; Mon, 15 Dec 2003 21:29:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW4xN-000285-Av
	for megaco-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 21:29:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12675
	for <megaco-web-archive@ietf.org>; Mon, 15 Dec 2003 21:29:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW4xK-000469-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 21:29:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AW4xJ-00045u-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 21:29:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW4xI-00045r-00
	for megaco-web-archive@ietf.org; Mon, 15 Dec 2003 21:29:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW4xJ-00027O-1a; Mon, 15 Dec 2003 21:29:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW4x7-00026v-DC
	for megaco@optimus.ietf.org; Mon, 15 Dec 2003 21:28:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12657
	for <megaco@ietf.org>; Mon, 15 Dec 2003 21:28:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW4x4-00044j-00
	for megaco@ietf.org; Mon, 15 Dec 2003 21:28:46 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AW4x3-00044b-00
	for megaco@ietf.org; Mon, 15 Dec 2003 21:28:46 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW4x3-00043g-00
	for megaco@ietf.org; Mon, 15 Dec 2003 21:28:45 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBFLR8v17721;
	Tue, 16 Dec 2003 08:27:08 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.228]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5LZD0P; Tue, 16 Dec 2003 08:28:51 +1100
Message-ID: <3FDE2721.8020406@ericsson.com>
Date: Tue, 16 Dec 2003 08:26:57 +1100
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: assingh@hss.hns.com
CC: megaco@ietf.org
Subject: Re: [Megaco] Regarding Context Audit
References: <OF6F900B29.DB3DD9A8-ON65256DFD.00320E37@hss.hns.com>
In-Reply-To: <OF6F900B29.DB3DD9A8-ON65256DFD.00320E37@hss.hns.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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=EXCUSE_16 autolearn=no 
	version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Ashish,

This is a problem in the ABNF as there is no way of returning a empty context 
audit. I am currently preparing a contribution for Sg16 discussing the problem. 
Will post to the list a link to the document when I've finished.

Christian

assingh@hss.hns.com wrote:

> 
> 
> 
> 
> 
> Hi List,
> 
> I have a doubt in context audit grammer.
> 
> Assume that there is an active context which is not emergency. Now a
> context audit request comes with only emergency token
> MEGACO/1 [10.10.1.1]:2100 Transaction=1100000 {Context = 1 { ContextAudit
> {Emergency} } }
> 
> As per the grammer
> Action reply should have error descriptor or command reply. In command
> reply we can send context properties whose grammer is
> contextProperties    = contextProperty *(COMMA contextProperty)
> contextProperty    = (topologyDescriptor / priority / EmergencyToken)
> Now here it is mandatory to send one of these tokens in context properties.
> It is not possible to send emergency token in this case as context is not
> emergency and the emergency token does not have a way to specify the value
> as TRUE or FALSE.
> 
> What should be returned in this case ? Is there a way to send an empty
> context audit reply.
> 
> Thanks in advance
> Ashish
> 
> www.hssworld.com
> 
> 
> "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
> (HSS) and is intended solely for the use of the individual to whom it is
> addressed. It may contain  privileged or confidential information and
> should not be circulated or used for any purpose other than for what it is
> intended. If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient, you are
> notified that you are strictly prohibited from using, copying, altering, or
> disclosing the contents of this message. HSS accepts no responsibility for
> loss or damage arising from the use of the information transmitted by this
> email including damage from virus."
> 
> 
> _______________________________________________
> 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-admin@ietf.org  Tue Dec 16 01:31:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18761
	for <megaco-archive@lists.ietf.org>; Tue, 16 Dec 2003 01:31:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW8jW-0000da-Ep; Tue, 16 Dec 2003 01:31:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW8jE-0000ck-4X
	for megaco@optimus.ietf.org; Tue, 16 Dec 2003 01:30:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18726
	for <megaco@ietf.org>; Tue, 16 Dec 2003 01:30:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW8jB-0002RG-00
	for megaco@ietf.org; Tue, 16 Dec 2003 01:30:41 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AW8jA-0002R9-00
	for megaco@ietf.org; Tue, 16 Dec 2003 01:30:40 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW8j8-0002Q0-00
	for megaco@ietf.org; Tue, 16 Dec 2003 01:30:39 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id hBG6RLiB019344;
	Tue, 16 Dec 2003 11:57:21 +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 hBG6SN725947;
	Tue, 16 Dec 2003 11:58:24 +0530 (IST)
From: megaco_maillist@hss.hns.com
Subject: Re: [Megaco] Descriptor processing on Termination OOS
To: Tom Taylor <taylor@nortelnetworks.com>
Cc: megaco@ietf.org
Date: Tue, 16 Dec 2003 11:53:15 +0530
Message-ID: <OFEFC5E96D.60325D78-ON65256DFD.0038E894@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 12/16/2003
 11:49:13
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=3.2 required=5.0 tests=NO_REAL_NAME,
	ROUND_THE_WORLD_LOCAL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>





Hi
      In my opinion keeping the descriptors alive and enabled for a
termination which is in Out of Service state
does not seems to be a valid behaviour of MG. For example if the card
containing the termination is jacked out
of the chasis then definately at the hardware level all the events and
signals get disabled.  There would be a major
disconnect wrt descriptors state if MGC does not audit the termination
since if  MGC were to audit the termination then
MG would be returning empty   descriptors in this particular case.  Now  in
this condition if the card is jacked-in and termination
is made in-service then the exact state of original descriptors no more
holds good and mgc needs to apply the descriptors again.

      Hence for a termination which is in Out-of-Service state MGC can
fairly assume that all descriptors are no more valid
and whenever the termination comes up will reapply the descriptors afresh.
This assumption holds true whether or not termination
is involved in a call.

Regards
Venkat





Tom Taylor <taylor@nortelnetworks.com>@ietf.org on 12/01/2003 11:52:03 PM

Sent by:    megaco-admin@ietf.org


To:    Sampath Komanduri <sampathk@cisco.com>
cc:    megaco@ietf.org

Subject:    Re: [Megaco] Descriptor processing on Termination OOS


The descriptors (aside from TerminationState) remain unchanged until
either the MGC changes them or the MG undergoes a cold restart.

Sampath Komanduri wrote:

> Hi all,
> Could someone pls. answer my question?
>
> Thanks,
> Sampath
>
>
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
> Sampath Komanduri
> Sent: Monday, November 24, 2003 5:46 PM
> To: megaco@ietf.org
> Subject: [Megaco] Descriptor processing on Termination OOS
>
>
> Hi,
> What should be the descriptors state when a termination is service
> changed to state OOS?
> Is it ok to remove all the descriptors that are currently applied on the
> termination or
> should MG keep the information of descriptors so that they can be
> re-applied if the termination comes to in-service state again.
>
> Thanks,
> Sampath
>
>
> _______________________________________________
> 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 exim@www1.ietf.org  Tue Dec 16 01:31:38 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18776
	for <megaco-archive@odin.ietf.org>; Tue, 16 Dec 2003 01:31:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW8jd-0000f6-K7
	for megaco-archive@odin.ietf.org; Tue, 16 Dec 2003 01:31:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBG6V9VS002536
	for megaco-archive@odin.ietf.org; Tue, 16 Dec 2003 01:31:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW8jd-0000ei-Bz
	for megaco-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 01:31:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18754
	for <megaco-web-archive@ietf.org>; Tue, 16 Dec 2003 01:31:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW8ja-0002Rg-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 01:31:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AW8jZ-0002RZ-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 01:31:05 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW8jZ-0002RW-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 01:31:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW8jW-0000da-Ep; Tue, 16 Dec 2003 01:31:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW8jE-0000ck-4X
	for megaco@optimus.ietf.org; Tue, 16 Dec 2003 01:30:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18726
	for <megaco@ietf.org>; Tue, 16 Dec 2003 01:30:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW8jB-0002RG-00
	for megaco@ietf.org; Tue, 16 Dec 2003 01:30:41 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AW8jA-0002R9-00
	for megaco@ietf.org; Tue, 16 Dec 2003 01:30:40 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW8j8-0002Q0-00
	for megaco@ietf.org; Tue, 16 Dec 2003 01:30:39 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id hBG6RLiB019344;
	Tue, 16 Dec 2003 11:57:21 +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 hBG6SN725947;
	Tue, 16 Dec 2003 11:58:24 +0530 (IST)
From: megaco_maillist@hss.hns.com
Subject: Re: [Megaco] Descriptor processing on Termination OOS
To: Tom Taylor <taylor@nortelnetworks.com>
Cc: megaco@ietf.org
Date: Tue, 16 Dec 2003 11:53:15 +0530
Message-ID: <OFEFC5E96D.60325D78-ON65256DFD.0038E894@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 12/16/2003
 11:49:13
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=3.2 required=5.0 tests=NO_REAL_NAME,
	ROUND_THE_WORLD_LOCAL autolearn=no version=2.60





Hi
      In my opinion keeping the descriptors alive and enabled for a
termination which is in Out of Service state
does not seems to be a valid behaviour of MG. For example if the card
containing the termination is jacked out
of the chasis then definately at the hardware level all the events and
signals get disabled.  There would be a major
disconnect wrt descriptors state if MGC does not audit the termination
since if  MGC were to audit the termination then
MG would be returning empty   descriptors in this particular case.  Now  in
this condition if the card is jacked-in and termination
is made in-service then the exact state of original descriptors no more
holds good and mgc needs to apply the descriptors again.

      Hence for a termination which is in Out-of-Service state MGC can
fairly assume that all descriptors are no more valid
and whenever the termination comes up will reapply the descriptors afresh.
This assumption holds true whether or not termination
is involved in a call.

Regards
Venkat





Tom Taylor <taylor@nortelnetworks.com>@ietf.org on 12/01/2003 11:52:03 PM

Sent by:    megaco-admin@ietf.org


To:    Sampath Komanduri <sampathk@cisco.com>
cc:    megaco@ietf.org

Subject:    Re: [Megaco] Descriptor processing on Termination OOS


The descriptors (aside from TerminationState) remain unchanged until
either the MGC changes them or the MG undergoes a cold restart.

Sampath Komanduri wrote:

> Hi all,
> Could someone pls. answer my question?
>
> Thanks,
> Sampath
>
>
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
> Sampath Komanduri
> Sent: Monday, November 24, 2003 5:46 PM
> To: megaco@ietf.org
> Subject: [Megaco] Descriptor processing on Termination OOS
>
>
> Hi,
> What should be the descriptors state when a termination is service
> changed to state OOS?
> Is it ok to remove all the descriptors that are currently applied on the
> termination or
> should MG keep the information of descriptors so that they can be
> re-applied if the termination comes to in-service state again.
>
> Thanks,
> Sampath
>
>
> _______________________________________________
> 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-admin@ietf.org  Tue Dec 16 03:05:32 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03764
	for <megaco-archive@lists.ietf.org>; Tue, 16 Dec 2003 03:05:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWACU-0005YK-5k; Tue, 16 Dec 2003 03:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWABb-0005V0-47
	for megaco@optimus.ietf.org; Tue, 16 Dec 2003 03:04:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03732
	for <megaco@ietf.org>; Tue, 16 Dec 2003 03:04:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWABX-0004R8-00
	for megaco@ietf.org; Tue, 16 Dec 2003 03:04:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWABW-0004R1-00
	for megaco@ietf.org; Tue, 16 Dec 2003 03:04:02 -0500
Received: from india-ironport-1.cisco.com ([64.104.129.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWABV-0004Qi-00
	for megaco@ietf.org; Tue, 16 Dec 2003 03:04:01 -0500
Received: from cisco.com (64.104.129.221)
  by india-ironport-1.cisco.com with ESMTP; 16 Dec 2003 13:44:40 +0530
Received: from samrat.cisco.com (samrat.cisco.com [192.135.241.21])
	by india-msg-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBGDUw0s019955;
	Tue, 16 Dec 2003 13:30:59 GMT
Received: from aniljw2k02 (dhcp-10-77-5-221.cisco.com [10.77.5.221])
	by samrat.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA10064;
	Tue, 16 Dec 2003 13:33:39 +0530 (IST)
Reply-To: <anilj@cisco.com>
From: "Anil Jangam \(anilj\)" <anilj@cisco.com>
To: <megaco_maillist@hss.hns.com>, "'Tom Taylor'" <taylor@nortelnetworks.com>
Cc: <megaco@ietf.org>
Subject: RE: [Megaco] Descriptor processing on Termination OOS
Date: Tue, 16 Dec 2003 13:33:27 +0530
Message-ID: <000001c3c3ab$1654dc70$dd054d0a@apac.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <OFEFC5E96D.60325D78-ON65256DFD.0038E894@hss.hns.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
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
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit



> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On 
> Behalf Of megaco_maillist@hss.hns.com
> Sent: Tuesday, December 16, 2003 11:53 AM
> To: Tom Taylor
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Descriptor processing on Termination OOS
> 
> 
> 
> 
> 
> 
> Hi
>       In my opinion keeping the descriptors alive and enabled 
> for a termination which is in Out of Service state does not 
> seems to be a valid behaviour of MG. For example if the card 
> containing the termination is jacked out of the chasis then 
> definately at the hardware level all the events and signals 
> get disabled.  There would be a major disconnect wrt 
> descriptors state if MGC does not audit the termination since 
> if  MGC were to audit the termination then
> MG would be returning empty   descriptors in this particular 
> case.  Now  in
> this condition if the card is jacked-in and termination
> is made in-service then the exact state of original 
> descriptors no more holds good and mgc needs to apply the 
> descriptors again.
> 
>       Hence for a termination which is in Out-of-Service 
> state MGC can fairly assume that all descriptors are no more 
> valid and whenever the termination comes up will reapply the 
> descriptors afresh. This assumption holds true whether or not 
> termination is involved in a call.

First thing, there is no provision for the MG to change the state of the
descriptor by its own. If we see the commands that can change the
descriptor state, these are commands which MGC initiate. 

In the SVC with SVCMethod = forced, its mentioned that MGC is going to
clean up the context, in which case it is to subtract the termination
from the cotext. At this point MGC can reset the descriptor state to the
default if necessary. Same logic can be applied when the SVCMethod is
graceful.
In the call flows as well, when the termination is coming back into the
service, normally a Modify is sent to MG initializing the term. 

So given this, IMO we don't have to make any assumption about the
descriptor state once its taken OOS.

> 
> Regards
> Venkat
> 
> 
> 
> 
> 
> Tom Taylor <taylor@nortelnetworks.com>@ietf.org on 12/01/2003 
> 11:52:03 PM
> 
> Sent by:    megaco-admin@ietf.org
> 
> 
> To:    Sampath Komanduri <sampathk@cisco.com>
> cc:    megaco@ietf.org
> 
> Subject:    Re: [Megaco] Descriptor processing on Termination OOS
> 
> 
> The descriptors (aside from TerminationState) remain 
> unchanged until either the MGC changes them or the MG 
> undergoes a cold restart.
> 
> Sampath Komanduri wrote:
> 
> > Hi all,
> > Could someone pls. answer my question?
> >
> > Thanks,
> > Sampath
> >
> >
> > -----Original Message-----
> > From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] 
> On Behalf 
> > Of Sampath Komanduri
> > Sent: Monday, November 24, 2003 5:46 PM
> > To: megaco@ietf.org
> > Subject: [Megaco] Descriptor processing on Termination OOS
> >
> >
> > Hi,
> > What should be the descriptors state when a termination is service 
> > changed to state OOS? Is it ok to remove all the 
> descriptors that are 
> > currently applied on the termination or
> > should MG keep the information of descriptors so that they can be
> > re-applied if the termination comes to in-service state again.
> >
> > Thanks,
> > Sampath
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
>  https://www1.ietf.org/mailman/listinfo/megaco
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


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


From exim@www1.ietf.org  Tue Dec 16 03:05:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03779
	for <megaco-archive@odin.ietf.org>; Tue, 16 Dec 2003 03:05:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWACZ-0005ZR-Ps
	for megaco-archive@odin.ietf.org; Tue, 16 Dec 2003 03:05:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBG857LS021412
	for megaco-archive@odin.ietf.org; Tue, 16 Dec 2003 03:05:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWACZ-0005ZD-Jz
	for megaco-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 03:05:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03758
	for <megaco-web-archive@ietf.org>; Tue, 16 Dec 2003 03:05:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWACV-0004Th-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 03:05:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWACU-0004Ta-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 03:05:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWACU-0004TX-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 03:05:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWACU-0005YK-5k; Tue, 16 Dec 2003 03:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWABb-0005V0-47
	for megaco@optimus.ietf.org; Tue, 16 Dec 2003 03:04:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03732
	for <megaco@ietf.org>; Tue, 16 Dec 2003 03:04:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWABX-0004R8-00
	for megaco@ietf.org; Tue, 16 Dec 2003 03:04:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWABW-0004R1-00
	for megaco@ietf.org; Tue, 16 Dec 2003 03:04:02 -0500
Received: from india-ironport-1.cisco.com ([64.104.129.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWABV-0004Qi-00
	for megaco@ietf.org; Tue, 16 Dec 2003 03:04:01 -0500
Received: from cisco.com (64.104.129.221)
  by india-ironport-1.cisco.com with ESMTP; 16 Dec 2003 13:44:40 +0530
Received: from samrat.cisco.com (samrat.cisco.com [192.135.241.21])
	by india-msg-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBGDUw0s019955;
	Tue, 16 Dec 2003 13:30:59 GMT
Received: from aniljw2k02 (dhcp-10-77-5-221.cisco.com [10.77.5.221])
	by samrat.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA10064;
	Tue, 16 Dec 2003 13:33:39 +0530 (IST)
Reply-To: <anilj@cisco.com>
From: "Anil Jangam \(anilj\)" <anilj@cisco.com>
To: <megaco_maillist@hss.hns.com>, "'Tom Taylor'" <taylor@nortelnetworks.com>
Cc: <megaco@ietf.org>
Subject: RE: [Megaco] Descriptor processing on Termination OOS
Date: Tue, 16 Dec 2003 13:33:27 +0530
Message-ID: <000001c3c3ab$1654dc70$dd054d0a@apac.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <OFEFC5E96D.60325D78-ON65256DFD.0038E894@hss.hns.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On 
> Behalf Of megaco_maillist@hss.hns.com
> Sent: Tuesday, December 16, 2003 11:53 AM
> To: Tom Taylor
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Descriptor processing on Termination OOS
> 
> 
> 
> 
> 
> 
> Hi
>       In my opinion keeping the descriptors alive and enabled 
> for a termination which is in Out of Service state does not 
> seems to be a valid behaviour of MG. For example if the card 
> containing the termination is jacked out of the chasis then 
> definately at the hardware level all the events and signals 
> get disabled.  There would be a major disconnect wrt 
> descriptors state if MGC does not audit the termination since 
> if  MGC were to audit the termination then
> MG would be returning empty   descriptors in this particular 
> case.  Now  in
> this condition if the card is jacked-in and termination
> is made in-service then the exact state of original 
> descriptors no more holds good and mgc needs to apply the 
> descriptors again.
> 
>       Hence for a termination which is in Out-of-Service 
> state MGC can fairly assume that all descriptors are no more 
> valid and whenever the termination comes up will reapply the 
> descriptors afresh. This assumption holds true whether or not 
> termination is involved in a call.

First thing, there is no provision for the MG to change the state of the
descriptor by its own. If we see the commands that can change the
descriptor state, these are commands which MGC initiate. 

In the SVC with SVCMethod = forced, its mentioned that MGC is going to
clean up the context, in which case it is to subtract the termination
from the cotext. At this point MGC can reset the descriptor state to the
default if necessary. Same logic can be applied when the SVCMethod is
graceful.
In the call flows as well, when the termination is coming back into the
service, normally a Modify is sent to MG initializing the term. 

So given this, IMO we don't have to make any assumption about the
descriptor state once its taken OOS.

> 
> Regards
> Venkat
> 
> 
> 
> 
> 
> Tom Taylor <taylor@nortelnetworks.com>@ietf.org on 12/01/2003 
> 11:52:03 PM
> 
> Sent by:    megaco-admin@ietf.org
> 
> 
> To:    Sampath Komanduri <sampathk@cisco.com>
> cc:    megaco@ietf.org
> 
> Subject:    Re: [Megaco] Descriptor processing on Termination OOS
> 
> 
> The descriptors (aside from TerminationState) remain 
> unchanged until either the MGC changes them or the MG 
> undergoes a cold restart.
> 
> Sampath Komanduri wrote:
> 
> > Hi all,
> > Could someone pls. answer my question?
> >
> > Thanks,
> > Sampath
> >
> >
> > -----Original Message-----
> > From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] 
> On Behalf 
> > Of Sampath Komanduri
> > Sent: Monday, November 24, 2003 5:46 PM
> > To: megaco@ietf.org
> > Subject: [Megaco] Descriptor processing on Termination OOS
> >
> >
> > Hi,
> > What should be the descriptors state when a termination is service 
> > changed to state OOS? Is it ok to remove all the 
> descriptors that are 
> > currently applied on the termination or
> > should MG keep the information of descriptors so that they can be
> > re-applied if the termination comes to in-service state again.
> >
> > Thanks,
> > Sampath
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
>  https://www1.ietf.org/mailman/listinfo/megaco
> 
> 
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 


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



From megaco-admin@ietf.org  Tue Dec 16 10:45:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19510
	for <megaco-archive@lists.ietf.org>; Tue, 16 Dec 2003 10:45:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWHNf-0006W9-CR; Tue, 16 Dec 2003 10:45:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWHN7-0006Ue-KP
	for megaco@optimus.ietf.org; Tue, 16 Dec 2003 10:44:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19377
	for <megaco@ietf.org>; Tue, 16 Dec 2003 10:44:25 -0500 (EST)
From: bvswamy@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWHN5-0005si-00
	for megaco@ietf.org; Tue, 16 Dec 2003 10:44:27 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWHN2-0005sP-00
	for megaco@ietf.org; Tue, 16 Dec 2003 10:44:26 -0500
Received: from [65.246.255.50] (helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWHFe-0004X8-00
	for megaco@ietf.org; Tue, 16 Dec 2003 10:36:46 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by manatick with esmtp (Exim 4.24)
	id 1AWGIm-0008Qk-8L
	for megaco@ietf.org; Tue, 16 Dec 2003 09:35:57 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id hBGEXZiB018899;
	Tue, 16 Dec 2003 20:04:00 +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 hBGEYPB19248;
	Tue, 16 Dec 2003 20:04:26 +0530 (IST)
Subject: RE: [Megaco] Descriptor processing on Termination OOS
To: <anilj@cisco.com>
Cc: megaco_maillist@hss.hns.com, "'Tom Taylor'" <taylor@nortelnetworks.com>,
        <megaco@ietf.org>
Date: Tue, 16 Dec 2003 19:33:23 +0530
Message-ID: <OF56421C64.D6889EAC-ON65256DFE.004CF79F@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 12/16/2003
 19:55:15
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=3.2 required=5.0 tests=NO_REAL_NAME,
	ROUND_THE_WORLD_LOCAL autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>





Hi
      Please find my comments embedded.[BVS].
Regards
Venkat





"Anil Jangam \(anilj\)" <anilj@cisco.com>@ietf.org on 12/16/2003 01:33:27
PM

Please respond to <anilj@cisco.com>

Sent by:    megaco-admin@ietf.org


To:    megaco_maillist@HSS, "'Tom Taylor'" <taylor@nortelnetworks.com>
cc:    <megaco@ietf.org>

Subject:    RE: [Megaco] Descriptor processing on Termination OOS




> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On
> Behalf Of megaco_maillist@hss.hns.com
> Sent: Tuesday, December 16, 2003 11:53 AM
> To: Tom Taylor
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Descriptor processing on Termination OOS
>
>
>
>
>
>
> Hi
>       In my opinion keeping the descriptors alive and enabled
> for a termination which is in Out of Service state does not
> seems to be a valid behaviour of MG. For example if the card
> containing the termination is jacked out of the chasis then
> definately at the hardware level all the events and signals
> get disabled.  There would be a major disconnect wrt
> descriptors state if MGC does not audit the termination since
> if  MGC were to audit the termination then
> MG would be returning empty   descriptors in this particular
> case.  Now  in
> this condition if the card is jacked-in and termination
> is made in-service then the exact state of original
> descriptors no more holds good and mgc needs to apply the
> descriptors again.
>
>       Hence for a termination which is in Out-of-Service
> state MGC can fairly assume that all descriptors are no more
> valid and whenever the termination comes up will reapply the
> descriptors afresh. This assumption holds true whether or not
> termination is involved in a call.

First thing, there is no provision for the MG to change the state of the
descriptor by its own. If we see the commands that can change the
descriptor state, these are commands which MGC initiate.

[BVS] I agree with you from the protocol perspective. But, if you analyse
the
actual scenario, service change (to out-of-service) for a termination would
mean disabling operations such as signals/ events/ streams. Further, this
would mean that MG does take some action on its own when it generates a
Service Change (or MGC sends a service change) on the termination.
If MG returns the descriptors in Audit response it would mean incorrect
representation of facts to MGC.

In the SVC with SVCMethod = forced, its mentioned that MGC is going to
clean up the context, in which case it is to subtract the termination
from the cotext. At this point MGC can reset the descriptor state to the
default if necessary. Same logic can be applied when the SVCMethod is
graceful.

[BVS] Cleaning up the context using subtract is OK for terminations in a
valid context. But, what about
the terminations which are already in the null context.


In the call flows as well, when the termination is coming back into the
service, normally a Modify is sent to MG initializing the term.


[BVS] Based upon our experience in the interop events, this MODIFY is
applicable to only
certain call scenarios (e.g. POTS call) and not for other scenarios (like
Trunkling).
Moreover, it is not used for clean up operations (like empty Signal
descriptor,
empty media descriptor etc.), but for the call setup (like event descriptor
with OffHook).


So given this, IMO we don't have to make any assumption about the
descriptor state once its taken OOS.

>
> Regards
> Venkat
>
>
>
>
>
> Tom Taylor <taylor@nortelnetworks.com>@ietf.org on 12/01/2003
> 11:52:03 PM
>
> Sent by:    megaco-admin@ietf.org
>
>
> To:    Sampath Komanduri <sampathk@cisco.com>
> cc:    megaco@ietf.org
>
> Subject:    Re: [Megaco] Descriptor processing on Termination OOS
>
>
> The descriptors (aside from TerminationState) remain
> unchanged until either the MGC changes them or the MG
> undergoes a cold restart.
>
> Sampath Komanduri wrote:
>
> > Hi all,
> > Could someone pls. answer my question?
> >
> > Thanks,
> > Sampath
> >
> >
> > -----Original Message-----
> > From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]
> On Behalf
> > Of Sampath Komanduri
> > Sent: Monday, November 24, 2003 5:46 PM
> > To: megaco@ietf.org
> > Subject: [Megaco] Descriptor processing on Termination OOS
> >
> >
> > Hi,
> > What should be the descriptors state when a termination is service
> > changed to state OOS? Is it ok to remove all the
> descriptors that are
> > currently applied on the termination or
> > should MG keep the information of descriptors so that they can be
> > re-applied if the termination comes to in-service state again.
> >
> > Thanks,
> > Sampath
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
>  https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>


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



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


From exim@www1.ietf.org  Tue Dec 16 10:45:40 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19542
	for <megaco-archive@odin.ietf.org>; Tue, 16 Dec 2003 10:45:40 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWHNq-0006YB-7g
	for megaco-archive@odin.ietf.org; Tue, 16 Dec 2003 10:45:14 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGFjEaB025175
	for megaco-archive@odin.ietf.org; Tue, 16 Dec 2003 10:45:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWHNq-0006Xy-4G
	for megaco-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 10:45:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19486
	for <megaco-web-archive@ietf.org>; Tue, 16 Dec 2003 10:45:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWHNn-00060R-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 10:45:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWHNi-0005zk-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 10:45:10 -0500
Received: from [65.246.255.50] (helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWHNh-0005zY-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 10:45:06 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by manatick with esmtp (Exim 4.24)
	id 1AWHNi-0003Gn-Jf
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 10:45:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWHNf-0006W9-CR; Tue, 16 Dec 2003 10:45:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWHN7-0006Ue-KP
	for megaco@optimus.ietf.org; Tue, 16 Dec 2003 10:44:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19377
	for <megaco@ietf.org>; Tue, 16 Dec 2003 10:44:25 -0500 (EST)
From: bvswamy@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWHN5-0005si-00
	for megaco@ietf.org; Tue, 16 Dec 2003 10:44:27 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWHN2-0005sP-00
	for megaco@ietf.org; Tue, 16 Dec 2003 10:44:26 -0500
Received: from [65.246.255.50] (helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWHFe-0004X8-00
	for megaco@ietf.org; Tue, 16 Dec 2003 10:36:46 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by manatick with esmtp (Exim 4.24)
	id 1AWGIm-0008Qk-8L
	for megaco@ietf.org; Tue, 16 Dec 2003 09:35:57 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id hBGEXZiB018899;
	Tue, 16 Dec 2003 20:04:00 +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 hBGEYPB19248;
	Tue, 16 Dec 2003 20:04:26 +0530 (IST)
Subject: RE: [Megaco] Descriptor processing on Termination OOS
To: <anilj@cisco.com>
Cc: megaco_maillist@hss.hns.com, "'Tom Taylor'" <taylor@nortelnetworks.com>,
        <megaco@ietf.org>
Date: Tue, 16 Dec 2003 19:33:23 +0530
Message-ID: <OF56421C64.D6889EAC-ON65256DFE.004CF79F@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 12/16/2003
 19:55:15
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=3.2 required=5.0 tests=NO_REAL_NAME,
	ROUND_THE_WORLD_LOCAL autolearn=no version=2.60





Hi
      Please find my comments embedded.[BVS].
Regards
Venkat





"Anil Jangam \(anilj\)" <anilj@cisco.com>@ietf.org on 12/16/2003 01:33:27
PM

Please respond to <anilj@cisco.com>

Sent by:    megaco-admin@ietf.org


To:    megaco_maillist@HSS, "'Tom Taylor'" <taylor@nortelnetworks.com>
cc:    <megaco@ietf.org>

Subject:    RE: [Megaco] Descriptor processing on Termination OOS




> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On
> Behalf Of megaco_maillist@hss.hns.com
> Sent: Tuesday, December 16, 2003 11:53 AM
> To: Tom Taylor
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Descriptor processing on Termination OOS
>
>
>
>
>
>
> Hi
>       In my opinion keeping the descriptors alive and enabled
> for a termination which is in Out of Service state does not
> seems to be a valid behaviour of MG. For example if the card
> containing the termination is jacked out of the chasis then
> definately at the hardware level all the events and signals
> get disabled.  There would be a major disconnect wrt
> descriptors state if MGC does not audit the termination since
> if  MGC were to audit the termination then
> MG would be returning empty   descriptors in this particular
> case.  Now  in
> this condition if the card is jacked-in and termination
> is made in-service then the exact state of original
> descriptors no more holds good and mgc needs to apply the
> descriptors again.
>
>       Hence for a termination which is in Out-of-Service
> state MGC can fairly assume that all descriptors are no more
> valid and whenever the termination comes up will reapply the
> descriptors afresh. This assumption holds true whether or not
> termination is involved in a call.

First thing, there is no provision for the MG to change the state of the
descriptor by its own. If we see the commands that can change the
descriptor state, these are commands which MGC initiate.

[BVS] I agree with you from the protocol perspective. But, if you analyse
the
actual scenario, service change (to out-of-service) for a termination would
mean disabling operations such as signals/ events/ streams. Further, this
would mean that MG does take some action on its own when it generates a
Service Change (or MGC sends a service change) on the termination.
If MG returns the descriptors in Audit response it would mean incorrect
representation of facts to MGC.

In the SVC with SVCMethod = forced, its mentioned that MGC is going to
clean up the context, in which case it is to subtract the termination
from the cotext. At this point MGC can reset the descriptor state to the
default if necessary. Same logic can be applied when the SVCMethod is
graceful.

[BVS] Cleaning up the context using subtract is OK for terminations in a
valid context. But, what about
the terminations which are already in the null context.


In the call flows as well, when the termination is coming back into the
service, normally a Modify is sent to MG initializing the term.


[BVS] Based upon our experience in the interop events, this MODIFY is
applicable to only
certain call scenarios (e.g. POTS call) and not for other scenarios (like
Trunkling).
Moreover, it is not used for clean up operations (like empty Signal
descriptor,
empty media descriptor etc.), but for the call setup (like event descriptor
with OffHook).


So given this, IMO we don't have to make any assumption about the
descriptor state once its taken OOS.

>
> Regards
> Venkat
>
>
>
>
>
> Tom Taylor <taylor@nortelnetworks.com>@ietf.org on 12/01/2003
> 11:52:03 PM
>
> Sent by:    megaco-admin@ietf.org
>
>
> To:    Sampath Komanduri <sampathk@cisco.com>
> cc:    megaco@ietf.org
>
> Subject:    Re: [Megaco] Descriptor processing on Termination OOS
>
>
> The descriptors (aside from TerminationState) remain
> unchanged until either the MGC changes them or the MG
> undergoes a cold restart.
>
> Sampath Komanduri wrote:
>
> > Hi all,
> > Could someone pls. answer my question?
> >
> > Thanks,
> > Sampath
> >
> >
> > -----Original Message-----
> > From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]
> On Behalf
> > Of Sampath Komanduri
> > Sent: Monday, November 24, 2003 5:46 PM
> > To: megaco@ietf.org
> > Subject: [Megaco] Descriptor processing on Termination OOS
> >
> >
> > Hi,
> > What should be the descriptors state when a termination is service
> > changed to state OOS? Is it ok to remove all the
> descriptors that are
> > currently applied on the termination or
> > should MG keep the information of descriptors so that they can be
> > re-applied if the termination comes to in-service state again.
> >
> > Thanks,
> > Sampath
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
>  https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>


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



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



From megaco-admin@ietf.org  Tue Dec 16 12:21:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24242
	for <megaco-archive@lists.ietf.org>; Tue, 16 Dec 2003 12:21:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWIsY-00046L-Lx; Tue, 16 Dec 2003 12:21:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWIsG-00045s-8C
	for megaco@optimus.ietf.org; Tue, 16 Dec 2003 12:20:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24227
	for <megaco@ietf.org>; Tue, 16 Dec 2003 12:20:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWIsB-000301-00
	for megaco@ietf.org; Tue, 16 Dec 2003 12:20:39 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWIs9-0002zt-00
	for megaco@ietf.org; Tue, 16 Dec 2003 12:20:39 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWIs8-0002ym-00
	for megaco@ietf.org; Tue, 16 Dec 2003 12:20:36 -0500
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 hBGHJfg18534;
	Tue, 16 Dec 2003 12:19:42 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y15Y29>; Tue, 16 Dec 2003 12:19:43 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D45D34C@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: bvswamy@hss.hns.com, anilj@cisco.com
Cc: megaco_maillist@hss.hns.com, "Tom-PT Taylor" <taylor@nortelnetworks.com>,
        megaco@ietf.org
Subject: RE: [Megaco] Descriptor processing on Termination OOS
Date: Tue, 16 Dec 2003 12:19:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C3F8.C8B49750"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3C3F8.C8B49750
Content-Type: text/plain

Comments inline [KJBII]

Kevin 

-----Original Message-----
From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] 
Sent: Tuesday, December 16, 2003 9:03 AM
To: anilj@cisco.com
Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH];
megaco@ietf.org
Subject: RE: [Megaco] Descriptor processing on Termination OOS





Hi
      Please find my comments embedded.[BVS].
Regards
Venkat





"Anil Jangam \(anilj\)" <anilj@cisco.com>@ietf.org on 12/16/2003 01:33:27 PM

Please respond to <anilj@cisco.com>

Sent by:    megaco-admin@ietf.org


To:    megaco_maillist@HSS, "'Tom Taylor'" <taylor@nortelnetworks.com>
cc:    <megaco@ietf.org>

Subject:    RE: [Megaco] Descriptor processing on Termination OOS




> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf 
> Of megaco_maillist@hss.hns.com
> Sent: Tuesday, December 16, 2003 11:53 AM
> To: Tom Taylor
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Descriptor processing on Termination OOS
>
>
>
>
>
>
> Hi
>       In my opinion keeping the descriptors alive and enabled for a 
> termination which is in Out of Service state does not seems to be a 
> valid behaviour of MG. For example if the card containing the 
> termination is jacked out of the chasis then definately at the 
> hardware level all the events and signals get disabled.  There would 
> be a major disconnect wrt descriptors state if MGC does not audit the 
> termination since if  MGC were to audit the termination then
> MG would be returning empty   descriptors in this particular
> case.  Now  in
> this condition if the card is jacked-in and termination is made 
> in-service then the exact state of original descriptors no more holds 
> good and mgc needs to apply the descriptors again.
>
>       Hence for a termination which is in Out-of-Service state MGC can 
> fairly assume that all descriptors are no more valid and whenever the 
> termination comes up will reapply the descriptors afresh. This 
> assumption holds true whether or not termination is involved in a 
> call.

First thing, there is no provision for the MG to change the state of the
descriptor by its own. If we see the commands that can change the descriptor
state, these are commands which MGC initiate.

[BVS] I agree with you from the protocol perspective. But, if you analyse
the actual scenario, service change (to out-of-service) for a termination
would mean disabling operations such as signals/ events/ streams. Further,
this would mean that MG does take some action on its own when it generates a
Service Change (or MGC sends a service change) on the termination.
If MG returns the descriptors in Audit response it would mean incorrect
representation of facts to MGC.

[KJBII] The MG may not take action on its own, whether we are talking about
a hardware failure or some other occurrence.  The text is explicit: the MG
may not reset those descriptors.  If the MGC wanted to audit, it may very
well be to collect diagnostic data.  If the MG wipes them out, then that
data is lost.

In the SVC with SVCMethod = forced, its mentioned that MGC is going to clean
up the context, in which case it is to subtract the termination from the
cotext. At this point MGC can reset the descriptor state to the default if
necessary. Same logic can be applied when the SVCMethod is graceful.

[BVS] Cleaning up the context using subtract is OK for terminations in a
valid context. But, what about the terminations which are already in the
null context.

[KJBII] What about them?  Modifies are allowed on OOS terminations.  The MGC
could very well send a modify to empty the descriptors.


In the call flows as well, when the termination is coming back into the
service, normally a Modify is sent to MG initializing the term.


[BVS] Based upon our experience in the interop events, this MODIFY is
applicable to only certain call scenarios (e.g. POTS call) and not for other
scenarios (like Trunkling).
Moreover, it is not used for clean up operations (like empty Signal
descriptor, empty media descriptor etc.), but for the call setup (like event
descriptor with OffHook).

[KJBII]  MGCs that do not reset the state of the descriptors upon return to
service will be subject to its own problems.  It seems to me that the MGC
would want to make sure the descriptors are in a particular state by
explicitly making them that way.  Further, I know of several implementations
that send empty descriptors in Modify commands.  Any assumption that they
are not used for normal call processing operations is deficient.


So given this, IMO we don't have to make any assumption about the descriptor
state once its taken OOS.

>
> Regards
> Venkat
>
>
>
>
>
> Tom Taylor <taylor@nortelnetworks.com>@ietf.org on 12/01/2003
> 11:52:03 PM
>
> Sent by:    megaco-admin@ietf.org
>
>
> To:    Sampath Komanduri <sampathk@cisco.com>
> cc:    megaco@ietf.org
>
> Subject:    Re: [Megaco] Descriptor processing on Termination OOS
>
>
> The descriptors (aside from TerminationState) remain unchanged until 
> either the MGC changes them or the MG undergoes a cold restart.
>
> Sampath Komanduri wrote:
>

------_=_NextPart_001_01C3C3F8.C8B49750
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [Megaco] Descriptor processing on Termination OOS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Comments inline [KJBII]</FONT>
</P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: bvswamy@hss.hns.com [<A =
HREF=3D"mailto:bvswamy@hss.hns.com">mailto:bvswamy@hss.hns.com</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, December 16, 2003 9:03 AM</FONT>
<BR><FONT SIZE=3D2>To: anilj@cisco.com</FONT>
<BR><FONT SIZE=3D2>Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT =
[CAR:5N00:EXCH]; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Megaco] Descriptor processing on =
Termination OOS</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Please find my =
comments embedded.[BVS].</FONT>
<BR><FONT SIZE=3D2>Regards</FONT>
<BR><FONT SIZE=3D2>Venkat</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&quot;Anil Jangam \(anilj\)&quot; =
&lt;anilj@cisco.com&gt;@ietf.org on 12/16/2003 01:33:27 PM</FONT>
</P>

<P><FONT SIZE=3D2>Please respond to &lt;anilj@cisco.com&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Sent by:&nbsp;&nbsp;&nbsp; =
megaco-admin@ietf.org</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp; megaco_maillist@HSS, &quot;'Tom =
Taylor'&quot; &lt;taylor@nortelnetworks.com&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp;&nbsp; &lt;megaco@ietf.org&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp; RE: [Megaco] Descriptor =
processing on Termination OOS</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: megaco-admin@ietf.org [<A =
HREF=3D"mailto:megaco-admin@ietf.org">mailto:megaco-admin@ietf.org</A>] =
On Behalf </FONT>
<BR><FONT SIZE=3D2>&gt; Of megaco_maillist@hss.hns.com</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, December 16, 2003 11:53 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Tom Taylor</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Megaco] Descriptor processing on =
Termination OOS</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Hi</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In my =
opinion keeping the descriptors alive and enabled for a </FONT>
<BR><FONT SIZE=3D2>&gt; termination which is in Out of Service state =
does not seems to be a </FONT>
<BR><FONT SIZE=3D2>&gt; valid behaviour of MG. For example if the card =
containing the </FONT>
<BR><FONT SIZE=3D2>&gt; termination is jacked out of the chasis then =
definately at the </FONT>
<BR><FONT SIZE=3D2>&gt; hardware level all the events and signals get =
disabled.&nbsp; There would </FONT>
<BR><FONT SIZE=3D2>&gt; be a major disconnect wrt descriptors state if =
MGC does not audit the </FONT>
<BR><FONT SIZE=3D2>&gt; termination since if&nbsp; MGC were to audit =
the termination then</FONT>
<BR><FONT SIZE=3D2>&gt; MG would be returning empty&nbsp;&nbsp; =
descriptors in this particular</FONT>
<BR><FONT SIZE=3D2>&gt; case.&nbsp; Now&nbsp; in</FONT>
<BR><FONT SIZE=3D2>&gt; this condition if the card is jacked-in and =
termination is made </FONT>
<BR><FONT SIZE=3D2>&gt; in-service then the exact state of original =
descriptors no more holds </FONT>
<BR><FONT SIZE=3D2>&gt; good and mgc needs to apply the descriptors =
again.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hence for a =
termination which is in Out-of-Service state MGC can </FONT>
<BR><FONT SIZE=3D2>&gt; fairly assume that all descriptors are no more =
valid and whenever the </FONT>
<BR><FONT SIZE=3D2>&gt; termination comes up will reapply the =
descriptors afresh. This </FONT>
<BR><FONT SIZE=3D2>&gt; assumption holds true whether or not =
termination is involved in a </FONT>
<BR><FONT SIZE=3D2>&gt; call.</FONT>
</P>

<P><FONT SIZE=3D2>First thing, there is no provision for the MG to =
change the state of the descriptor by its own. If we see the commands =
that can change the descriptor state, these are commands which MGC =
initiate.</FONT></P>

<P><FONT SIZE=3D2>[BVS] I agree with you from the protocol perspective. =
But, if you analyse the actual scenario, service change (to =
out-of-service) for a termination would mean disabling operations such =
as signals/ events/ streams. Further, this would mean that MG does take =
some action on its own when it generates a Service Change (or MGC sends =
a service change) on the termination.</FONT></P>

<P><FONT SIZE=3D2>If MG returns the descriptors in Audit response it =
would mean incorrect representation of facts to MGC.</FONT>
</P>

<P><FONT SIZE=3D2>[KJBII] The MG may not take action on its own, =
whether we are talking about a hardware failure or some other =
occurrence.&nbsp; The text is explicit: the MG may not reset those =
descriptors.&nbsp; If the MGC wanted to audit, it may very well be to =
collect diagnostic data.&nbsp; If the MG wipes them out, then that data =
is lost.</FONT></P>

<P><FONT SIZE=3D2>In the SVC with SVCMethod =3D forced, its mentioned =
that MGC is going to clean up the context, in which case it is to =
subtract the termination from the cotext. At this point MGC can reset =
the descriptor state to the default if necessary. Same logic can be =
applied when the SVCMethod is graceful.</FONT></P>

<P><FONT SIZE=3D2>[BVS] Cleaning up the context using subtract is OK =
for terminations in a valid context. But, what about the terminations =
which are already in the null context.</FONT></P>

<P><FONT SIZE=3D2>[KJBII] What about them?&nbsp; Modifies are allowed =
on OOS terminations.&nbsp; The MGC could very well send a modify to =
empty the descriptors.</FONT></P>
<BR>

<P><FONT SIZE=3D2>In the call flows as well, when the termination is =
coming back into the service, normally a Modify is sent to MG =
initializing the term.</FONT></P>
<BR>

<P><FONT SIZE=3D2>[BVS] Based upon our experience in the interop =
events, this MODIFY is applicable to only certain call scenarios (e.g. =
POTS call) and not for other scenarios (like Trunkling).</FONT></P>

<P><FONT SIZE=3D2>Moreover, it is not used for clean up operations =
(like empty Signal descriptor, empty media descriptor etc.), but for =
the call setup (like event descriptor with OffHook).</FONT></P>

<P><FONT SIZE=3D2>[KJBII]&nbsp; MGCs that do not reset the state of the =
descriptors upon return to service will be subject to its own =
problems.&nbsp; It seems to me that the MGC would want to make sure the =
descriptors are in a particular state by explicitly making them that =
way.&nbsp; Further, I know of several implementations that send empty =
descriptors in Modify commands.&nbsp; Any assumption that they are not =
used for normal call processing operations is deficient.</FONT></P>
<BR>

<P><FONT SIZE=3D2>So given this, IMO we don't have to make any =
assumption about the descriptor state once its taken OOS.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Regards</FONT>
<BR><FONT SIZE=3D2>&gt; Venkat</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Tom Taylor =
&lt;taylor@nortelnetworks.com&gt;@ietf.org on 12/01/2003</FONT>
<BR><FONT SIZE=3D2>&gt; 11:52:03 PM</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Sent by:&nbsp;&nbsp;&nbsp; =
megaco-admin@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp;&nbsp; Sampath Komanduri =
&lt;sampathk@cisco.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; cc:&nbsp;&nbsp;&nbsp; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp;&nbsp;&nbsp; Re: [Megaco] =
Descriptor processing on Termination OOS</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; The descriptors (aside from TerminationState) =
remain unchanged until </FONT>
<BR><FONT SIZE=3D2>&gt; either the MGC changes them or the MG undergoes =
a cold restart.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Sampath Komanduri wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3C3F8.C8B49750--

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


From exim@www1.ietf.org  Tue Dec 16 12:21:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24257
	for <megaco-archive@odin.ietf.org>; Tue, 16 Dec 2003 12:21:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWIsd-00047F-Ht
	for megaco-archive@odin.ietf.org; Tue, 16 Dec 2003 12:21:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGHL73X015815
	for megaco-archive@odin.ietf.org; Tue, 16 Dec 2003 12:21:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWIsd-000470-E1
	for megaco-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 12:21:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24236
	for <megaco-web-archive@ietf.org>; Tue, 16 Dec 2003 12:21:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWIsb-00030R-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 12:21:05 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWIsZ-00030K-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 12:21:05 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWIsZ-00030G-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 12:21:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWIsY-00046L-Lx; Tue, 16 Dec 2003 12:21:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWIsG-00045s-8C
	for megaco@optimus.ietf.org; Tue, 16 Dec 2003 12:20:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24227
	for <megaco@ietf.org>; Tue, 16 Dec 2003 12:20:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWIsB-000301-00
	for megaco@ietf.org; Tue, 16 Dec 2003 12:20:39 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWIs9-0002zt-00
	for megaco@ietf.org; Tue, 16 Dec 2003 12:20:39 -0500
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWIs8-0002ym-00
	for megaco@ietf.org; Tue, 16 Dec 2003 12:20:36 -0500
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 hBGHJfg18534;
	Tue, 16 Dec 2003 12:19:42 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y15Y29>; Tue, 16 Dec 2003 12:19:43 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D45D34C@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: bvswamy@hss.hns.com, anilj@cisco.com
Cc: megaco_maillist@hss.hns.com, "Tom-PT Taylor" <taylor@nortelnetworks.com>,
        megaco@ietf.org
Subject: RE: [Megaco] Descriptor processing on Termination OOS
Date: Tue, 16 Dec 2003 12:19:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C3F8.C8B49750"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60

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_01C3C3F8.C8B49750
Content-Type: text/plain

Comments inline [KJBII]

Kevin 

-----Original Message-----
From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] 
Sent: Tuesday, December 16, 2003 9:03 AM
To: anilj@cisco.com
Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH];
megaco@ietf.org
Subject: RE: [Megaco] Descriptor processing on Termination OOS





Hi
      Please find my comments embedded.[BVS].
Regards
Venkat





"Anil Jangam \(anilj\)" <anilj@cisco.com>@ietf.org on 12/16/2003 01:33:27 PM

Please respond to <anilj@cisco.com>

Sent by:    megaco-admin@ietf.org


To:    megaco_maillist@HSS, "'Tom Taylor'" <taylor@nortelnetworks.com>
cc:    <megaco@ietf.org>

Subject:    RE: [Megaco] Descriptor processing on Termination OOS




> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf 
> Of megaco_maillist@hss.hns.com
> Sent: Tuesday, December 16, 2003 11:53 AM
> To: Tom Taylor
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Descriptor processing on Termination OOS
>
>
>
>
>
>
> Hi
>       In my opinion keeping the descriptors alive and enabled for a 
> termination which is in Out of Service state does not seems to be a 
> valid behaviour of MG. For example if the card containing the 
> termination is jacked out of the chasis then definately at the 
> hardware level all the events and signals get disabled.  There would 
> be a major disconnect wrt descriptors state if MGC does not audit the 
> termination since if  MGC were to audit the termination then
> MG would be returning empty   descriptors in this particular
> case.  Now  in
> this condition if the card is jacked-in and termination is made 
> in-service then the exact state of original descriptors no more holds 
> good and mgc needs to apply the descriptors again.
>
>       Hence for a termination which is in Out-of-Service state MGC can 
> fairly assume that all descriptors are no more valid and whenever the 
> termination comes up will reapply the descriptors afresh. This 
> assumption holds true whether or not termination is involved in a 
> call.

First thing, there is no provision for the MG to change the state of the
descriptor by its own. If we see the commands that can change the descriptor
state, these are commands which MGC initiate.

[BVS] I agree with you from the protocol perspective. But, if you analyse
the actual scenario, service change (to out-of-service) for a termination
would mean disabling operations such as signals/ events/ streams. Further,
this would mean that MG does take some action on its own when it generates a
Service Change (or MGC sends a service change) on the termination.
If MG returns the descriptors in Audit response it would mean incorrect
representation of facts to MGC.

[KJBII] The MG may not take action on its own, whether we are talking about
a hardware failure or some other occurrence.  The text is explicit: the MG
may not reset those descriptors.  If the MGC wanted to audit, it may very
well be to collect diagnostic data.  If the MG wipes them out, then that
data is lost.

In the SVC with SVCMethod = forced, its mentioned that MGC is going to clean
up the context, in which case it is to subtract the termination from the
cotext. At this point MGC can reset the descriptor state to the default if
necessary. Same logic can be applied when the SVCMethod is graceful.

[BVS] Cleaning up the context using subtract is OK for terminations in a
valid context. But, what about the terminations which are already in the
null context.

[KJBII] What about them?  Modifies are allowed on OOS terminations.  The MGC
could very well send a modify to empty the descriptors.


In the call flows as well, when the termination is coming back into the
service, normally a Modify is sent to MG initializing the term.


[BVS] Based upon our experience in the interop events, this MODIFY is
applicable to only certain call scenarios (e.g. POTS call) and not for other
scenarios (like Trunkling).
Moreover, it is not used for clean up operations (like empty Signal
descriptor, empty media descriptor etc.), but for the call setup (like event
descriptor with OffHook).

[KJBII]  MGCs that do not reset the state of the descriptors upon return to
service will be subject to its own problems.  It seems to me that the MGC
would want to make sure the descriptors are in a particular state by
explicitly making them that way.  Further, I know of several implementations
that send empty descriptors in Modify commands.  Any assumption that they
are not used for normal call processing operations is deficient.


So given this, IMO we don't have to make any assumption about the descriptor
state once its taken OOS.

>
> Regards
> Venkat
>
>
>
>
>
> Tom Taylor <taylor@nortelnetworks.com>@ietf.org on 12/01/2003
> 11:52:03 PM
>
> Sent by:    megaco-admin@ietf.org
>
>
> To:    Sampath Komanduri <sampathk@cisco.com>
> cc:    megaco@ietf.org
>
> Subject:    Re: [Megaco] Descriptor processing on Termination OOS
>
>
> The descriptors (aside from TerminationState) remain unchanged until 
> either the MGC changes them or the MG undergoes a cold restart.
>
> Sampath Komanduri wrote:
>

------_=_NextPart_001_01C3C3F8.C8B49750
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [Megaco] Descriptor processing on Termination OOS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Comments inline [KJBII]</FONT>
</P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: bvswamy@hss.hns.com [<A =
HREF=3D"mailto:bvswamy@hss.hns.com">mailto:bvswamy@hss.hns.com</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, December 16, 2003 9:03 AM</FONT>
<BR><FONT SIZE=3D2>To: anilj@cisco.com</FONT>
<BR><FONT SIZE=3D2>Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT =
[CAR:5N00:EXCH]; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Megaco] Descriptor processing on =
Termination OOS</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Please find my =
comments embedded.[BVS].</FONT>
<BR><FONT SIZE=3D2>Regards</FONT>
<BR><FONT SIZE=3D2>Venkat</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&quot;Anil Jangam \(anilj\)&quot; =
&lt;anilj@cisco.com&gt;@ietf.org on 12/16/2003 01:33:27 PM</FONT>
</P>

<P><FONT SIZE=3D2>Please respond to &lt;anilj@cisco.com&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Sent by:&nbsp;&nbsp;&nbsp; =
megaco-admin@ietf.org</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp; megaco_maillist@HSS, &quot;'Tom =
Taylor'&quot; &lt;taylor@nortelnetworks.com&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp;&nbsp; &lt;megaco@ietf.org&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp; RE: [Megaco] Descriptor =
processing on Termination OOS</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: megaco-admin@ietf.org [<A =
HREF=3D"mailto:megaco-admin@ietf.org">mailto:megaco-admin@ietf.org</A>] =
On Behalf </FONT>
<BR><FONT SIZE=3D2>&gt; Of megaco_maillist@hss.hns.com</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, December 16, 2003 11:53 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Tom Taylor</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Megaco] Descriptor processing on =
Termination OOS</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Hi</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In my =
opinion keeping the descriptors alive and enabled for a </FONT>
<BR><FONT SIZE=3D2>&gt; termination which is in Out of Service state =
does not seems to be a </FONT>
<BR><FONT SIZE=3D2>&gt; valid behaviour of MG. For example if the card =
containing the </FONT>
<BR><FONT SIZE=3D2>&gt; termination is jacked out of the chasis then =
definately at the </FONT>
<BR><FONT SIZE=3D2>&gt; hardware level all the events and signals get =
disabled.&nbsp; There would </FONT>
<BR><FONT SIZE=3D2>&gt; be a major disconnect wrt descriptors state if =
MGC does not audit the </FONT>
<BR><FONT SIZE=3D2>&gt; termination since if&nbsp; MGC were to audit =
the termination then</FONT>
<BR><FONT SIZE=3D2>&gt; MG would be returning empty&nbsp;&nbsp; =
descriptors in this particular</FONT>
<BR><FONT SIZE=3D2>&gt; case.&nbsp; Now&nbsp; in</FONT>
<BR><FONT SIZE=3D2>&gt; this condition if the card is jacked-in and =
termination is made </FONT>
<BR><FONT SIZE=3D2>&gt; in-service then the exact state of original =
descriptors no more holds </FONT>
<BR><FONT SIZE=3D2>&gt; good and mgc needs to apply the descriptors =
again.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hence for a =
termination which is in Out-of-Service state MGC can </FONT>
<BR><FONT SIZE=3D2>&gt; fairly assume that all descriptors are no more =
valid and whenever the </FONT>
<BR><FONT SIZE=3D2>&gt; termination comes up will reapply the =
descriptors afresh. This </FONT>
<BR><FONT SIZE=3D2>&gt; assumption holds true whether or not =
termination is involved in a </FONT>
<BR><FONT SIZE=3D2>&gt; call.</FONT>
</P>

<P><FONT SIZE=3D2>First thing, there is no provision for the MG to =
change the state of the descriptor by its own. If we see the commands =
that can change the descriptor state, these are commands which MGC =
initiate.</FONT></P>

<P><FONT SIZE=3D2>[BVS] I agree with you from the protocol perspective. =
But, if you analyse the actual scenario, service change (to =
out-of-service) for a termination would mean disabling operations such =
as signals/ events/ streams. Further, this would mean that MG does take =
some action on its own when it generates a Service Change (or MGC sends =
a service change) on the termination.</FONT></P>

<P><FONT SIZE=3D2>If MG returns the descriptors in Audit response it =
would mean incorrect representation of facts to MGC.</FONT>
</P>

<P><FONT SIZE=3D2>[KJBII] The MG may not take action on its own, =
whether we are talking about a hardware failure or some other =
occurrence.&nbsp; The text is explicit: the MG may not reset those =
descriptors.&nbsp; If the MGC wanted to audit, it may very well be to =
collect diagnostic data.&nbsp; If the MG wipes them out, then that data =
is lost.</FONT></P>

<P><FONT SIZE=3D2>In the SVC with SVCMethod =3D forced, its mentioned =
that MGC is going to clean up the context, in which case it is to =
subtract the termination from the cotext. At this point MGC can reset =
the descriptor state to the default if necessary. Same logic can be =
applied when the SVCMethod is graceful.</FONT></P>

<P><FONT SIZE=3D2>[BVS] Cleaning up the context using subtract is OK =
for terminations in a valid context. But, what about the terminations =
which are already in the null context.</FONT></P>

<P><FONT SIZE=3D2>[KJBII] What about them?&nbsp; Modifies are allowed =
on OOS terminations.&nbsp; The MGC could very well send a modify to =
empty the descriptors.</FONT></P>
<BR>

<P><FONT SIZE=3D2>In the call flows as well, when the termination is =
coming back into the service, normally a Modify is sent to MG =
initializing the term.</FONT></P>
<BR>

<P><FONT SIZE=3D2>[BVS] Based upon our experience in the interop =
events, this MODIFY is applicable to only certain call scenarios (e.g. =
POTS call) and not for other scenarios (like Trunkling).</FONT></P>

<P><FONT SIZE=3D2>Moreover, it is not used for clean up operations =
(like empty Signal descriptor, empty media descriptor etc.), but for =
the call setup (like event descriptor with OffHook).</FONT></P>

<P><FONT SIZE=3D2>[KJBII]&nbsp; MGCs that do not reset the state of the =
descriptors upon return to service will be subject to its own =
problems.&nbsp; It seems to me that the MGC would want to make sure the =
descriptors are in a particular state by explicitly making them that =
way.&nbsp; Further, I know of several implementations that send empty =
descriptors in Modify commands.&nbsp; Any assumption that they are not =
used for normal call processing operations is deficient.</FONT></P>
<BR>

<P><FONT SIZE=3D2>So given this, IMO we don't have to make any =
assumption about the descriptor state once its taken OOS.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Regards</FONT>
<BR><FONT SIZE=3D2>&gt; Venkat</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Tom Taylor =
&lt;taylor@nortelnetworks.com&gt;@ietf.org on 12/01/2003</FONT>
<BR><FONT SIZE=3D2>&gt; 11:52:03 PM</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Sent by:&nbsp;&nbsp;&nbsp; =
megaco-admin@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp;&nbsp; Sampath Komanduri =
&lt;sampathk@cisco.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; cc:&nbsp;&nbsp;&nbsp; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp;&nbsp;&nbsp; Re: [Megaco] =
Descriptor processing on Termination OOS</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; The descriptors (aside from TerminationState) =
remain unchanged until </FONT>
<BR><FONT SIZE=3D2>&gt; either the MGC changes them or the MG undergoes =
a cold restart.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Sampath Komanduri wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3C3F8.C8B49750--

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



From megaco-admin@ietf.org  Tue Dec 16 18:40:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14884
	for <megaco-archive@lists.ietf.org>; Tue, 16 Dec 2003 18:40:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWOnN-0004og-Ib; Tue, 16 Dec 2003 18:40:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWO1s-0002GD-ES
	for megaco@optimus.ietf.org; Tue, 16 Dec 2003 17:51:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12012
	for <megaco@ietf.org>; Tue, 16 Dec 2003 17:50:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWO1p-00012i-00
	for megaco@ietf.org; Tue, 16 Dec 2003 17:50:57 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWO1o-00012b-00
	for megaco@ietf.org; Tue, 16 Dec 2003 17:50:57 -0500
Received: from bay7-f86.bay7.hotmail.com ([64.4.11.86] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWO1o-00011l-00
	for megaco@ietf.org; Tue, 16 Dec 2003 17:50:56 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 16 Dec 2003 14:50:27 -0800
Received: from 81.133.146.93 by by7fd.bay7.hotmail.msn.com with HTTP;
	Tue, 16 Dec 2003 22:50:26 GMT
X-Originating-IP: [81.133.146.93]
X-Originating-Email: [peterallenuk@hotmail.com]
X-Sender: peterallenuk@hotmail.com
From: "Peter Allen" <peterallenuk@hotmail.com>
To: megaco@ietf.org
Date: Tue, 16 Dec 2003 22:50:26 +0000
Mime-Version: 1.0
Content-Type: text/html
Message-ID: <BAY7-F86fdUKlKHFNzA0003d666@hotmail.com>
X-OriginalArrivalTime: 16 Dec 2003 22:50:27.0122 (UTC) FILETIME=[FF851920:01C3C426]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_20_30,HTML_FONTCOLOR_BLUE,
	HTML_FONTCOLOR_RED,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY 
	autolearn=no version=2.60
Subject: [Megaco] Port 2944
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

<html><div style='background-color:'><P>To whomever it may concern,</P>
<P>I was on the internet in the evening on&nbsp;16/12/03. I was browsing for directions to a place in London, when I recieved the "Blue Screen of Death", apart from it appeared to be in German, with several more options. Obviously my German isn't up to scratch, having never spoken the language, so I reset my computer.<BR><BR>When I re-connected to the internet, my firewall software (AtGuard) kept on throwing up a warning of "Inbound TCP network communication" being attempted. It could not tell me which application was trying to be accessed, however, it gave me a "Local Service", identifying it as "port 2944". I selected "Block this network communication for just this attempt", however, I recieved more and more messages with different IP addresses but the same port number. After 5 minutes of these messages, sometimes up to 3 times a second, I decided to find out what it was.</P>
<P>I went onto google.com, entering "port 2944". The results of the search led me to something called "megaco". Being unsure what this is, I searched into it further, finding the following URL:</P>
<P><FONT color=#0000ff><A href="http://www.ietf.org/html.charters/megaco-charter.html">http://www.ietf.org/html.charters/megaco-charter.html</A></FONT></P>
<P>Upon visiting this site, I recieved this e-mail address. If you know anything about what is going on, please e-mail me back with a possible answer.</P>
<P>Yours,</P>
<P>Peter Allen...</P>
<P>&nbsp;</P>
<DIV>
<DIV><FONT color=#ff0000 face="Arial Black, Geneva, Arial, Sans-serif"><EM>Cantus adduco gens gentis delenimentum frequento cogito abunde sanus...</EM></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Lucida Handwriting, Cursive" size=2>Music leads the people to what they think is right...</FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS" size=2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV></DIV></div><br clear=all><hr>Get a free connection, half-price modem and one month FREE, when you sign up for <a href="http://g.msn.com/8HMBENUK/2731??PS=">BT Broadband today!</a> </html>

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


From exim@www1.ietf.org  Tue Dec 16 18:40:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14913
	for <megaco-archive@odin.ietf.org>; Tue, 16 Dec 2003 18:40:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWOnS-0004pu-W6
	for megaco-archive@odin.ietf.org; Tue, 16 Dec 2003 18:40:11 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGNeAgu018582
	for megaco-archive@odin.ietf.org; Tue, 16 Dec 2003 18:40:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWOnR-0004pd-FA
	for megaco-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 18:40:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14877
	for <megaco-web-archive@ietf.org>; Tue, 16 Dec 2003 18:40:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWOnO-0002Y6-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 18:40:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWOnN-0002Xx-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 18:40:06 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWOnN-0002Xu-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 18:40:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWOnN-0004og-Ib; Tue, 16 Dec 2003 18:40:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWO1s-0002GD-ES
	for megaco@optimus.ietf.org; Tue, 16 Dec 2003 17:51:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12012
	for <megaco@ietf.org>; Tue, 16 Dec 2003 17:50:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWO1p-00012i-00
	for megaco@ietf.org; Tue, 16 Dec 2003 17:50:57 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWO1o-00012b-00
	for megaco@ietf.org; Tue, 16 Dec 2003 17:50:57 -0500
Received: from bay7-f86.bay7.hotmail.com ([64.4.11.86] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWO1o-00011l-00
	for megaco@ietf.org; Tue, 16 Dec 2003 17:50:56 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 16 Dec 2003 14:50:27 -0800
Received: from 81.133.146.93 by by7fd.bay7.hotmail.msn.com with HTTP;
	Tue, 16 Dec 2003 22:50:26 GMT
X-Originating-IP: [81.133.146.93]
X-Originating-Email: [peterallenuk@hotmail.com]
X-Sender: peterallenuk@hotmail.com
From: "Peter Allen" <peterallenuk@hotmail.com>
To: megaco@ietf.org
Date: Tue, 16 Dec 2003 22:50:26 +0000
Mime-Version: 1.0
Content-Type: text/html
Message-ID: <BAY7-F86fdUKlKHFNzA0003d666@hotmail.com>
X-OriginalArrivalTime: 16 Dec 2003 22:50:27.0122 (UTC) FILETIME=[FF851920:01C3C426]
Subject: [Megaco] Port 2944
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,HTML_20_30,
	HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_MESSAGE,
	MIME_HTML_NO_CHARSET,MIME_HTML_ONLY autolearn=no version=2.60

<html><div style='background-color:'><P>To whomever it may concern,</P>
<P>I was on the internet in the evening on&nbsp;16/12/03. I was browsing for directions to a place in London, when I recieved the "Blue Screen of Death", apart from it appeared to be in German, with several more options. Obviously my German isn't up to scratch, having never spoken the language, so I reset my computer.<BR><BR>When I re-connected to the internet, my firewall software (AtGuard) kept on throwing up a warning of "Inbound TCP network communication" being attempted. It could not tell me which application was trying to be accessed, however, it gave me a "Local Service", identifying it as "port 2944". I selected "Block this network communication for just this attempt", however, I recieved more and more messages with different IP addresses but the same port number. After 5 minutes of these messages, sometimes up to 3 times a second, I decided to find out what it was.</P>
<P>I went onto google.com, entering "port 2944". The results of the search led me to something called "megaco". Being unsure what this is, I searched into it further, finding the following URL:</P>
<P><FONT color=#0000ff><A href="http://www.ietf.org/html.charters/megaco-charter.html">http://www.ietf.org/html.charters/megaco-charter.html</A></FONT></P>
<P>Upon visiting this site, I recieved this e-mail address. If you know anything about what is going on, please e-mail me back with a possible answer.</P>
<P>Yours,</P>
<P>Peter Allen...</P>
<P>&nbsp;</P>
<DIV>
<DIV><FONT color=#ff0000 face="Arial Black, Geneva, Arial, Sans-serif"><EM>Cantus adduco gens gentis delenimentum frequento cogito abunde sanus...</EM></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Lucida Handwriting, Cursive" size=2>Music leads the people to what they think is right...</FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS" size=2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV></DIV></div><br clear=all><hr>Get a free connection, half-price modem and one month FREE, when you sign up for <a href="http://g.msn.com/8HMBENUK/2731??PS=">BT Broadband today!</a> </html>

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



From megaco-admin@ietf.org  Tue Dec 16 18:53:27 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15249
	for <megaco-archive@lists.ietf.org>; Tue, 16 Dec 2003 18:53:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWOzt-0005U0-4a; Tue, 16 Dec 2003 18:53:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWOyy-0005Ke-5h
	for megaco@optimus.ietf.org; Tue, 16 Dec 2003 18:52:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15177
	for <megaco@ietf.org>; Tue, 16 Dec 2003 18:51:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWOyv-0002mc-00
	for megaco@ietf.org; Tue, 16 Dec 2003 18:52:01 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWOyu-0002mV-00
	for megaco@ietf.org; Tue, 16 Dec 2003 18:52:00 -0500
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWOyt-0002mS-00
	for megaco@ietf.org; Tue, 16 Dec 2003 18:51:59 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBGNpR214138;
	Tue, 16 Dec 2003 18:51:27 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLYJPMMJ; Tue, 16 Dec 2003 18:51:27 -0500
Received: from nortelnetworks.com (acart1b9.ca.nortel.com [47.129.129.19]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLPWNCPH; Tue, 16 Dec 2003 18:51:27 -0500
Message-ID: <3FDF9A7E.9070303@nortelnetworks.com>
Date: Tue, 16 Dec 2003 18:51:26 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Allen <peterallenuk@hotmail.com>
CC: megaco@ietf.org
Subject: Re: [Megaco] Port 2944
References: <BAY7-F86fdUKlKHFNzA0003d666@hotmail.com>
In-Reply-To: <BAY7-F86fdUKlKHFNzA0003d666@hotmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

I've replied to Peter privately.  There's a shockingly misconfigured 
media gateway or controller out there somewhere, or else an inadequately 
protected one!

Peter Allen wrote:

> To whomever it may concern,
> 
> I was on the internet in the evening on 16/12/03. I was browsing for 
> directions to a place in London, when I recieved the "Blue Screen of 
> Death", apart from it appeared to be in German, with several more 
> options. Obviously my German isn't up to scratch, having never spoken 
> the language, so I reset my computer.
> 
> When I re-connected to the internet, my firewall software (AtGuard) kept 
> on throwing up a warning of "Inbound TCP network communication" being 
> attempted. It could not tell me which application was trying to be 
> accessed, however, it gave me a "Local Service", identifying it as "port 
> 2944". I selected "Block this network communication for just this 
> attempt", however, I recieved more and more messages with different IP 
> addresses but the same port number. After 5 minutes of these messages, 
> sometimes up to 3 times a second, I decided to find out what it was.
> 
> I went onto google.com, entering "port 2944". The results of the search 
> led me to something called "megaco". Being unsure what this is, I 
> searched into it further, finding the following URL:
> 
> http://www.ietf.org/html.charters/megaco-charter.html
> 
> Upon visiting this site, I recieved this e-mail address. If you know 
> anything about what is going on, please e-mail me back with a possible 
> answer.
> 
> Yours,
> 
> Peter Allen...
> 
>  
> 
> /Cantus adduco gens gentis delenimentum frequento cogito abunde sanus.../
>  
> Music leads the people to what they think is right...
>  
>  
> 
> ------------------------------------------------------------------------
> Get a free connection, half-price modem and one month FREE, when you 
> sign up for BT Broadband today! <http://g.msn.com/8HMBENUK/2731??PS=> 
> _______________________________________________ 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 exim@www1.ietf.org  Tue Dec 16 18:53:29 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15270
	for <megaco-archive@odin.ietf.org>; Tue, 16 Dec 2003 18:53:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWOzv-0005Vc-Ri
	for megaco-archive@odin.ietf.org; Tue, 16 Dec 2003 18:53:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGNr3Fs021170
	for megaco-archive@odin.ietf.org; Tue, 16 Dec 2003 18:53:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWOzv-0005VN-Nz
	for megaco-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 18:53:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15235
	for <megaco-web-archive@ietf.org>; Tue, 16 Dec 2003 18:52:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWOzs-0002pC-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 18:53:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWOzr-0002p4-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 18:53:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWOzr-0002p1-00
	for megaco-web-archive@ietf.org; Tue, 16 Dec 2003 18:52:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWOzt-0005U0-4a; Tue, 16 Dec 2003 18:53:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWOyy-0005Ke-5h
	for megaco@optimus.ietf.org; Tue, 16 Dec 2003 18:52:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15177
	for <megaco@ietf.org>; Tue, 16 Dec 2003 18:51:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWOyv-0002mc-00
	for megaco@ietf.org; Tue, 16 Dec 2003 18:52:01 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWOyu-0002mV-00
	for megaco@ietf.org; Tue, 16 Dec 2003 18:52:00 -0500
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWOyt-0002mS-00
	for megaco@ietf.org; Tue, 16 Dec 2003 18:51:59 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBGNpR214138;
	Tue, 16 Dec 2003 18:51:27 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLYJPMMJ; Tue, 16 Dec 2003 18:51:27 -0500
Received: from nortelnetworks.com (acart1b9.ca.nortel.com [47.129.129.19]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLPWNCPH; Tue, 16 Dec 2003 18:51:27 -0500
Message-ID: <3FDF9A7E.9070303@nortelnetworks.com>
Date: Tue, 16 Dec 2003 18:51:26 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Allen <peterallenuk@hotmail.com>
CC: megaco@ietf.org
Subject: Re: [Megaco] Port 2944
References: <BAY7-F86fdUKlKHFNzA0003d666@hotmail.com>
In-Reply-To: <BAY7-F86fdUKlKHFNzA0003d666@hotmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: 7bit

I've replied to Peter privately.  There's a shockingly misconfigured 
media gateway or controller out there somewhere, or else an inadequately 
protected one!

Peter Allen wrote:

> To whomever it may concern,
> 
> I was on the internet in the evening on 16/12/03. I was browsing for 
> directions to a place in London, when I recieved the "Blue Screen of 
> Death", apart from it appeared to be in German, with several more 
> options. Obviously my German isn't up to scratch, having never spoken 
> the language, so I reset my computer.
> 
> When I re-connected to the internet, my firewall software (AtGuard) kept 
> on throwing up a warning of "Inbound TCP network communication" being 
> attempted. It could not tell me which application was trying to be 
> accessed, however, it gave me a "Local Service", identifying it as "port 
> 2944". I selected "Block this network communication for just this 
> attempt", however, I recieved more and more messages with different IP 
> addresses but the same port number. After 5 minutes of these messages, 
> sometimes up to 3 times a second, I decided to find out what it was.
> 
> I went onto google.com, entering "port 2944". The results of the search 
> led me to something called "megaco". Being unsure what this is, I 
> searched into it further, finding the following URL:
> 
> http://www.ietf.org/html.charters/megaco-charter.html
> 
> Upon visiting this site, I recieved this e-mail address. If you know 
> anything about what is going on, please e-mail me back with a possible 
> answer.
> 
> Yours,
> 
> Peter Allen...
> 
>  
> 
> /Cantus adduco gens gentis delenimentum frequento cogito abunde sanus.../
>  
> Music leads the people to what they think is right...
>  
>  
> 
> ------------------------------------------------------------------------
> Get a free connection, half-price modem and one month FREE, when you 
> sign up for BT Broadband today! <http://g.msn.com/8HMBENUK/2731??PS=> 
> _______________________________________________ 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-admin@ietf.org  Wed Dec 17 02:17:37 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12395
	for <megaco-archive@lists.ietf.org>; Wed, 17 Dec 2003 02:17:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWVvb-000534-Ia; Wed, 17 Dec 2003 02:17:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWVv9-0004zt-Fu
	for megaco@optimus.ietf.org; Wed, 17 Dec 2003 02:16:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11531
	for <megaco@ietf.org>; Wed, 17 Dec 2003 02:16:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWVv5-00066m-00
	for megaco@ietf.org; Wed, 17 Dec 2003 02:16:31 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWVuz-00065t-00
	for megaco@ietf.org; Wed, 17 Dec 2003 02:16:31 -0500
Received: from [65.246.255.50] (helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWVuz-00065p-00
	for megaco@ietf.org; Wed, 17 Dec 2003 02:16:25 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by manatick with esmtp (Exim 4.24)
	id 1AWVuz-000353-Tp
	for megaco@ietf.org; Wed, 17 Dec 2003 02:16:27 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBGMxvv03587;
	Wed, 17 Dec 2003 09:59:57 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.184]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5LZZWB; Wed, 17 Dec 2003 10:01:37 +1100
Message-ID: <3FDF8F87.4040307@ericsson.com>
Date: Wed, 17 Dec 2003 10:04:39 +1100
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: Kevin Boyle <kboyle@nortelnetworks.com>, bvswamy@hss.hns.com,
        anilj@cisco.com
CC: megaco_maillist@hss.hns.com, Tom-PT Taylor <taylor@nortelnetworks.com>,
        megaco@ietf.org
Subject: Re: [Megaco] Descriptor processing on Termination OOS
References: <ABA227A15B80D511BD1A00508BF93A1C0D45D34C@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0D45D34C@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hello,

OOS Service by its nature must be reported by a ServiceChange, this can be 
through Forced which states: At a minimum, the Termination shall be subtracted 
from the Context. Graceful is similar that the MGC is expected to "clean up" the 
termination ultimately by subtracting the termination.

So for ephemeral terminations there's no discussion as they'll disappear the MGC 
won't be able to do anything to them. For physical terminations the following 
rule applies:

H.248.1 6.2.4 Termination properties and descriptors
...
If not provisioned otherwise, the properties in all descriptors except 
TerminationState and LocalControl default to empty/"no value" when a Termination 
is first created or returned to the null Context.
...

This text is very clear when a termination goes back to the NULL context which 
for TDM terminations is the result of going "out of service" the descriptors ARE 
changed.

I can remember that this behaviour caused quite a bit of discussion at the time 
(I think Tom drafted the text) and it was felt that this was the best behaviour 
because it left terminations in a known state both for the MG and MGC.

Regards, Christian

Kevin Boyle wrote:

> Comments inline [KJBII]
> 
> Kevin
> 
> -----Original Message-----
> From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com]
> Sent: Tuesday, December 16, 2003 9:03 AM
> To: anilj@cisco.com
> Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH]; 
> megaco@ietf.org
> Subject: RE: [Megaco] Descriptor processing on Termination OOS
> 
> 
> 
> 
> 
> Hi
>       Please find my comments embedded.[BVS].
> Regards
> Venkat
> 
> 
> 
> 
> 
> "Anil Jangam \(anilj\)" <anilj@cisco.com>@ietf.org on 12/16/2003 
> 01:33:27 PM
> 
> Please respond to <anilj@cisco.com>
> 
> Sent by:    megaco-admin@ietf.org
> 
> 
> To:    megaco_maillist@HSS, "'Tom Taylor'" <taylor@nortelnetworks.com>
> cc:    <megaco@ietf.org>
> 
> Subject:    RE: [Megaco] Descriptor processing on Termination OOS
> 
> 
> 
> 
>  > -----Original Message-----
>  > From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf
>  > Of megaco_maillist@hss.hns.com
>  > Sent: Tuesday, December 16, 2003 11:53 AM
>  > To: Tom Taylor
>  > Cc: megaco@ietf.org
>  > Subject: Re: [Megaco] Descriptor processing on Termination OOS
>  >
>  >
>  >
>  >
>  >
>  >
>  > Hi
>  >       In my opinion keeping the descriptors alive and enabled for a
>  > termination which is in Out of Service state does not seems to be a
>  > valid behaviour of MG. For example if the card containing the
>  > termination is jacked out of the chasis then definately at the
>  > hardware level all the events and signals get disabled.  There would
>  > be a major disconnect wrt descriptors state if MGC does not audit the
>  > termination since if  MGC were to audit the termination then
>  > MG would be returning empty   descriptors in this particular
>  > case.  Now  in
>  > this condition if the card is jacked-in and termination is made
>  > in-service then the exact state of original descriptors no more holds
>  > good and mgc needs to apply the descriptors again.
>  >
>  >       Hence for a termination which is in Out-of-Service state MGC can
>  > fairly assume that all descriptors are no more valid and whenever the
>  > termination comes up will reapply the descriptors afresh. This
>  > assumption holds true whether or not termination is involved in a
>  > call.
> 
> First thing, there is no provision for the MG to change the state of the 
> descriptor by its own. If we see the commands that can change the 
> descriptor state, these are commands which MGC initiate.
> 
> [BVS] I agree with you from the protocol perspective. But, if you 
> analyse the actual scenario, service change (to out-of-service) for a 
> termination would mean disabling operations such as signals/ events/ 
> streams. Further, this would mean that MG does take some action on its 
> own when it generates a Service Change (or MGC sends a service change) 
> on the termination.
> 
> If MG returns the descriptors in Audit response it would mean incorrect 
> representation of facts to MGC.
> 
> [KJBII] The MG may not take action on its own, whether we are talking 
> about a hardware failure or some other occurrence.  The text is 
> explicit: the MG may not reset those descriptors.  If the MGC wanted to 
> audit, it may very well be to collect diagnostic data.  If the MG wipes 
> them out, then that data is lost.
> 
> In the SVC with SVCMethod = forced, its mentioned that MGC is going to 
> clean up the context, in which case it is to subtract the termination 
> from the cotext. At this point MGC can reset the descriptor state to the 
> default if necessary. Same logic can be applied when the SVCMethod is 
> graceful.
> 
> [BVS] Cleaning up the context using subtract is OK for terminations in a 
> valid context. But, what about the terminations which are already in the 
> null context.
> 
> [KJBII] What about them?  Modifies are allowed on OOS terminations.  The 
> MGC could very well send a modify to empty the descriptors.
> 
> 
> In the call flows as well, when the termination is coming back into the 
> service, normally a Modify is sent to MG initializing the term.
> 
> 
> [BVS] Based upon our experience in the interop events, this MODIFY is 
> applicable to only certain call scenarios (e.g. POTS call) and not for 
> other scenarios (like Trunkling).
> 
> Moreover, it is not used for clean up operations (like empty Signal 
> descriptor, empty media descriptor etc.), but for the call setup (like 
> event descriptor with OffHook).
> 
> [KJBII]  MGCs that do not reset the state of the descriptors upon return 
> to service will be subject to its own problems.  It seems to me that the 
> MGC would want to make sure the descriptors are in a particular state by 
> explicitly making them that way.  Further, I know of several 
> implementations that send empty descriptors in Modify commands.  Any 
> assumption that they are not used for normal call processing operations 
> is deficient.
> 
> 
> So given this, IMO we don't have to make any assumption about the 
> descriptor state once its taken OOS.
> 
>  >
>  > Regards
>  > Venkat
>  >
>  >
>  >
>  >
>  >
>  > Tom Taylor <taylor@nortelnetworks.com>@ietf.org on 12/01/2003
>  > 11:52:03 PM
>  >
>  > Sent by:    megaco-admin@ietf.org
>  >
>  >
>  > To:    Sampath Komanduri <sampathk@cisco.com>
>  > cc:    megaco@ietf.org
>  >
>  > Subject:    Re: [Megaco] Descriptor processing on Termination OOS
>  >
>  >
>  > The descriptors (aside from TerminationState) remain unchanged until
>  > either the MGC changes them or the MG undergoes a cold restart.
>  >
>  > Sampath Komanduri wrote:
>  >
> 


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


From exim@www1.ietf.org  Wed Dec 17 02:17:41 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12441
	for <megaco-archive@odin.ietf.org>; Wed, 17 Dec 2003 02:17:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWVvl-000559-Dx
	for megaco-archive@odin.ietf.org; Wed, 17 Dec 2003 02:17:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBH7HDGR019535
	for megaco-archive@odin.ietf.org; Wed, 17 Dec 2003 02:17:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWVvk-000550-Oz
	for megaco-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 02:17:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12048
	for <megaco-web-archive@ietf.org>; Wed, 17 Dec 2003 02:17:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWVvf-00068B-00
	for megaco-web-archive@ietf.org; Wed, 17 Dec 2003 02:17:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWVve-000683-00
	for megaco-web-archive@ietf.org; Wed, 17 Dec 2003 02:17:07 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWVve-000680-00
	for megaco-web-archive@ietf.org; Wed, 17 Dec 2003 02:17:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWVvb-000534-Ia; Wed, 17 Dec 2003 02:17:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWVv9-0004zt-Fu
	for megaco@optimus.ietf.org; Wed, 17 Dec 2003 02:16:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11531
	for <megaco@ietf.org>; Wed, 17 Dec 2003 02:16:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWVv5-00066m-00
	for megaco@ietf.org; Wed, 17 Dec 2003 02:16:31 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWVuz-00065t-00
	for megaco@ietf.org; Wed, 17 Dec 2003 02:16:31 -0500
Received: from [65.246.255.50] (helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWVuz-00065p-00
	for megaco@ietf.org; Wed, 17 Dec 2003 02:16:25 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by manatick with esmtp (Exim 4.24)
	id 1AWVuz-000353-Tp
	for megaco@ietf.org; Wed, 17 Dec 2003 02:16:27 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBGMxvv03587;
	Wed, 17 Dec 2003 09:59:57 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.184]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5LZZWB; Wed, 17 Dec 2003 10:01:37 +1100
Message-ID: <3FDF8F87.4040307@ericsson.com>
Date: Wed, 17 Dec 2003 10:04:39 +1100
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: Kevin Boyle <kboyle@nortelnetworks.com>, bvswamy@hss.hns.com,
        anilj@cisco.com
CC: megaco_maillist@hss.hns.com, Tom-PT Taylor <taylor@nortelnetworks.com>,
        megaco@ietf.org
Subject: Re: [Megaco] Descriptor processing on Termination OOS
References: <ABA227A15B80D511BD1A00508BF93A1C0D45D34C@zrtpd0jq.us.nortel.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0D45D34C@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: 7bit

Hello,

OOS Service by its nature must be reported by a ServiceChange, this can be 
through Forced which states: At a minimum, the Termination shall be subtracted 
from the Context. Graceful is similar that the MGC is expected to "clean up" the 
termination ultimately by subtracting the termination.

So for ephemeral terminations there's no discussion as they'll disappear the MGC 
won't be able to do anything to them. For physical terminations the following 
rule applies:

H.248.1 6.2.4 Termination properties and descriptors
...
If not provisioned otherwise, the properties in all descriptors except 
TerminationState and LocalControl default to empty/"no value" when a Termination 
is first created or returned to the null Context.
...

This text is very clear when a termination goes back to the NULL context which 
for TDM terminations is the result of going "out of service" the descriptors ARE 
changed.

I can remember that this behaviour caused quite a bit of discussion at the time 
(I think Tom drafted the text) and it was felt that this was the best behaviour 
because it left terminations in a known state both for the MG and MGC.

Regards, Christian

Kevin Boyle wrote:

> Comments inline [KJBII]
> 
> Kevin
> 
> -----Original Message-----
> From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com]
> Sent: Tuesday, December 16, 2003 9:03 AM
> To: anilj@cisco.com
> Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH]; 
> megaco@ietf.org
> Subject: RE: [Megaco] Descriptor processing on Termination OOS
> 
> 
> 
> 
> 
> Hi
>       Please find my comments embedded.[BVS].
> Regards
> Venkat
> 
> 
> 
> 
> 
> "Anil Jangam \(anilj\)" <anilj@cisco.com>@ietf.org on 12/16/2003 
> 01:33:27 PM
> 
> Please respond to <anilj@cisco.com>
> 
> Sent by:    megaco-admin@ietf.org
> 
> 
> To:    megaco_maillist@HSS, "'Tom Taylor'" <taylor@nortelnetworks.com>
> cc:    <megaco@ietf.org>
> 
> Subject:    RE: [Megaco] Descriptor processing on Termination OOS
> 
> 
> 
> 
>  > -----Original Message-----
>  > From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf
>  > Of megaco_maillist@hss.hns.com
>  > Sent: Tuesday, December 16, 2003 11:53 AM
>  > To: Tom Taylor
>  > Cc: megaco@ietf.org
>  > Subject: Re: [Megaco] Descriptor processing on Termination OOS
>  >
>  >
>  >
>  >
>  >
>  >
>  > Hi
>  >       In my opinion keeping the descriptors alive and enabled for a
>  > termination which is in Out of Service state does not seems to be a
>  > valid behaviour of MG. For example if the card containing the
>  > termination is jacked out of the chasis then definately at the
>  > hardware level all the events and signals get disabled.  There would
>  > be a major disconnect wrt descriptors state if MGC does not audit the
>  > termination since if  MGC were to audit the termination then
>  > MG would be returning empty   descriptors in this particular
>  > case.  Now  in
>  > this condition if the card is jacked-in and termination is made
>  > in-service then the exact state of original descriptors no more holds
>  > good and mgc needs to apply the descriptors again.
>  >
>  >       Hence for a termination which is in Out-of-Service state MGC can
>  > fairly assume that all descriptors are no more valid and whenever the
>  > termination comes up will reapply the descriptors afresh. This
>  > assumption holds true whether or not termination is involved in a
>  > call.
> 
> First thing, there is no provision for the MG to change the state of the 
> descriptor by its own. If we see the commands that can change the 
> descriptor state, these are commands which MGC initiate.
> 
> [BVS] I agree with you from the protocol perspective. But, if you 
> analyse the actual scenario, service change (to out-of-service) for a 
> termination would mean disabling operations such as signals/ events/ 
> streams. Further, this would mean that MG does take some action on its 
> own when it generates a Service Change (or MGC sends a service change) 
> on the termination.
> 
> If MG returns the descriptors in Audit response it would mean incorrect 
> representation of facts to MGC.
> 
> [KJBII] The MG may not take action on its own, whether we are talking 
> about a hardware failure or some other occurrence.  The text is 
> explicit: the MG may not reset those descriptors.  If the MGC wanted to 
> audit, it may very well be to collect diagnostic data.  If the MG wipes 
> them out, then that data is lost.
> 
> In the SVC with SVCMethod = forced, its mentioned that MGC is going to 
> clean up the context, in which case it is to subtract the termination 
> from the cotext. At this point MGC can reset the descriptor state to the 
> default if necessary. Same logic can be applied when the SVCMethod is 
> graceful.
> 
> [BVS] Cleaning up the context using subtract is OK for terminations in a 
> valid context. But, what about the terminations which are already in the 
> null context.
> 
> [KJBII] What about them?  Modifies are allowed on OOS terminations.  The 
> MGC could very well send a modify to empty the descriptors.
> 
> 
> In the call flows as well, when the termination is coming back into the 
> service, normally a Modify is sent to MG initializing the term.
> 
> 
> [BVS] Based upon our experience in the interop events, this MODIFY is 
> applicable to only certain call scenarios (e.g. POTS call) and not for 
> other scenarios (like Trunkling).
> 
> Moreover, it is not used for clean up operations (like empty Signal 
> descriptor, empty media descriptor etc.), but for the call setup (like 
> event descriptor with OffHook).
> 
> [KJBII]  MGCs that do not reset the state of the descriptors upon return 
> to service will be subject to its own problems.  It seems to me that the 
> MGC would want to make sure the descriptors are in a particular state by 
> explicitly making them that way.  Further, I know of several 
> implementations that send empty descriptors in Modify commands.  Any 
> assumption that they are not used for normal call processing operations 
> is deficient.
> 
> 
> So given this, IMO we don't have to make any assumption about the 
> descriptor state once its taken OOS.
> 
>  >
>  > Regards
>  > Venkat
>  >
>  >
>  >
>  >
>  >
>  > Tom Taylor <taylor@nortelnetworks.com>@ietf.org on 12/01/2003
>  > 11:52:03 PM
>  >
>  > Sent by:    megaco-admin@ietf.org
>  >
>  >
>  > To:    Sampath Komanduri <sampathk@cisco.com>
>  > cc:    megaco@ietf.org
>  >
>  > Subject:    Re: [Megaco] Descriptor processing on Termination OOS
>  >
>  >
>  > The descriptors (aside from TerminationState) remain unchanged until
>  > either the MGC changes them or the MG undergoes a cold restart.
>  >
>  > Sampath Komanduri wrote:
>  >
> 


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



From megaco-admin@ietf.org  Wed Dec 17 11:22:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17873
	for <megaco-archive@lists.ietf.org>; Wed, 17 Dec 2003 11:22:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWeQy-0000ml-VG; Wed, 17 Dec 2003 11:22:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWeQu-0000mV-Kb
	for megaco@optimus.ietf.org; Wed, 17 Dec 2003 11:21:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17853
	for <megaco@ietf.org>; Wed, 17 Dec 2003 11:21:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWeQt-0004wP-00
	for megaco@ietf.org; Wed, 17 Dec 2003 11:21:55 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWeQq-0004wI-00
	for megaco@ietf.org; Wed, 17 Dec 2003 11:21:55 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWeQq-0004v2-00
	for megaco@ietf.org; Wed, 17 Dec 2003 11:21:52 -0500
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 hBHGJJJ24323;
	Wed, 17 Dec 2003 11:19:19 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y16MKJ>; Wed, 17 Dec 2003 11:19:20 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D4B39FC@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Christian Groves <Christian.Groves@ericsson.com>, bvswamy@hss.hns.com,
        anilj@cisco.com
Cc: megaco_maillist@hss.hns.com, "Tom-PT Taylor" <taylor@nortelnetworks.com>,
        megaco@ietf.org
Subject: RE: [Megaco] Descriptor processing on Termination OOS
Date: Wed, 17 Dec 2003 11:19:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C4B9.84C717E0"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3C4B9.84C717E0
Content-Type: text/plain

Right.  I just wanted to ensure that everyone understands that the reset of
the descriptors is a result of the SUBTRACT, and not a result of the
SERVICECHANGE.

Subtle, but important, difference.

Kevin 

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com] 
Sent: Tuesday, December 16, 2003 6:05 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; bvswamy@hss.hns.com; anilj@cisco.com
Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH];
megaco@ietf.org
Subject: Re: [Megaco] Descriptor processing on Termination OOS

Hello,

OOS Service by its nature must be reported by a ServiceChange, this can be
through Forced which states: At a minimum, the Termination shall be
subtracted from the Context. Graceful is similar that the MGC is expected to
"clean up" the termination ultimately by subtracting the termination.

So for ephemeral terminations there's no discussion as they'll disappear the
MGC won't be able to do anything to them. For physical terminations the
following rule applies:

H.248.1 6.2.4 Termination properties and descriptors ...
If not provisioned otherwise, the properties in all descriptors except
TerminationState and LocalControl default to empty/"no value" when a
Termination is first created or returned to the null Context.
...

This text is very clear when a termination goes back to the NULL context
which for TDM terminations is the result of going "out of service" the
descriptors ARE changed.

I can remember that this behaviour caused quite a bit of discussion at the
time (I think Tom drafted the text) and it was felt that this was the best
behaviour because it left terminations in a known state both for the MG and
MGC.

Regards, Christian

Kevin Boyle wrote:

> Comments inline [KJBII]
> 
> Kevin
> 
> -----Original Message-----
> From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com]
> Sent: Tuesday, December 16, 2003 9:03 AM
> To: anilj@cisco.com
> Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH]; 
> megaco@ietf.org
> Subject: RE: [Megaco] Descriptor processing on Termination OOS
> 
> 
> 
> 
> 
> Hi
>       Please find my comments embedded.[BVS].
> Regards
> Venkat
> 
> 
> 
> 
> 
> "Anil Jangam \(anilj\)" <anilj@cisco.com>@ietf.org on 12/16/2003
> 01:33:27 PM
> 
> Please respond to <anilj@cisco.com>
> 
> Sent by:    megaco-admin@ietf.org
> 
> 
> To:    megaco_maillist@HSS, "'Tom Taylor'" <taylor@nortelnetworks.com>
> cc:    <megaco@ietf.org>
> 
> Subject:    RE: [Megaco] Descriptor processing on Termination OOS
> 
> 
> 
> 
>  > -----Original Message-----
>  > From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On 
> Behalf  > Of megaco_maillist@hss.hns.com  > Sent: Tuesday, December 
> 16, 2003 11:53 AM  > To: Tom Taylor  > Cc: megaco@ietf.org  > Subject: 
> Re: [Megaco] Descriptor processing on Termination OOS  >  >  >  >  >  
> >  > Hi
>  >       In my opinion keeping the descriptors alive and enabled for a
>  > termination which is in Out of Service state does not seems to be a  
> > valid behaviour of MG. For example if the card containing the  > 
> termination is jacked out of the chasis then definately at the  > 
> hardware level all the events and signals get disabled.  There would  
> > be a major disconnect wrt descriptors state if MGC does not audit 
> the  > termination since if  MGC were to audit the termination then
>  > MG would be returning empty   descriptors in this particular
>  > case.  Now  in
>  > this condition if the card is jacked-in and termination is made  > 
> in-service then the exact state of original descriptors no more holds  
> > good and mgc needs to apply the descriptors again.
>  >
>  >       Hence for a termination which is in Out-of-Service state MGC can
>  > fairly assume that all descriptors are no more valid and whenever 
> the  > termination comes up will reapply the descriptors afresh. This  
> > assumption holds true whether or not termination is involved in a  > 
> call.
> 
> First thing, there is no provision for the MG to change the state of 
> the descriptor by its own. If we see the commands that can change the 
> descriptor state, these are commands which MGC initiate.
> 
> [BVS] I agree with you from the protocol perspective. But, if you 
> analyse the actual scenario, service change (to out-of-service) for a 
> termination would mean disabling operations such as signals/ events/ 
> streams. Further, this would mean that MG does take some action on its 
> own when it generates a Service Change (or MGC sends a service change) 
> on the termination.
> 
> If MG returns the descriptors in Audit response it would mean 
> incorrect representation of facts to MGC.
> 
> [KJBII] The MG may not take action on its own, whether we are talking 
> about a hardware failure or some other occurrence.  The text is
> explicit: the MG may not reset those descriptors.  If the MGC wanted 
> to audit, it may very well be to collect diagnostic data.  If the MG 
> wipes them out, then that data is lost.
> 
> In the SVC with SVCMethod = forced, its mentioned that MGC is going to 
> clean up the context, in which case it is to subtract the termination 
> from the cotext. At this point MGC can reset the descriptor state to 
> the default if necessary. Same logic can be applied when the SVCMethod 
> is graceful.
> 
> [BVS] Cleaning up the context using subtract is OK for terminations in 
> a valid context. But, what about the terminations which are already in 
> the null context.
> 
> [KJBII] What about them?  Modifies are allowed on OOS terminations.  
> The MGC could very well send a modify to empty the descriptors.
> 
> 
> In the call flows as well, when the termination is coming back into 
> the service, normally a Modify is sent to MG initializing the term.
> 
> 
> [BVS] Based upon our experience in the interop events, this MODIFY is 
> applicable to only certain call scenarios (e.g. POTS call) and not for 
> other scenarios (like Trunkling).
> 
> Moreover, it is not used for clean up operations (like empty Signal 
> descriptor, empty media descriptor etc.), but for the call setup (like 
> event descriptor with OffHook).
> 
> [KJBII]  MGCs that do not reset the state of the descriptors upon 
> return to service will be subject to its own problems.  It seems to me 
> that the MGC would want to make sure the descriptors are in a 
> particular state by explicitly making them that way.  Further, I know 
> of several implementations that send empty descriptors in Modify 
> commands.  Any assumption that they are not used for normal call 
> processing operations is deficient.
> 
> 
> So given this, IMO we don't have to make any assumption about the 
> descriptor state once its taken OOS.
> 
>  >
>  > Regards
>  > Venkat
>  >
>  >
>  >
>  >
>  >
>  > Tom Taylor <taylor@nortelnetworks.com>@ietf.org on 12/01/2003  > 
> 11:52:03 PM  >
>  > Sent by:    megaco-admin@ietf.org
>  >
>  >
>  > To:    Sampath Komanduri <sampathk@cisco.com>
>  > cc:    megaco@ietf.org
>  >
>  > Subject:    Re: [Megaco] Descriptor processing on Termination OOS
>  >
>  >
>  > The descriptors (aside from TerminationState) remain unchanged 
> until  > either the MGC changes them or the MG undergoes a cold restart.
>  >
>  > Sampath Komanduri wrote:
>  >
> 


------_=_NextPart_001_01C3C4B9.84C717E0
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [Megaco] Descriptor processing on Termination OOS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Right.&nbsp; I just wanted to ensure that everyone =
understands that the reset of the descriptors is a result of the =
SUBTRACT, and not a result of the SERVICECHANGE.</FONT></P>

<P><FONT SIZE=3D2>Subtle, but important, difference.</FONT>
</P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Christian Groves [<A =
HREF=3D"mailto:Christian.Groves@ericsson.com">mailto:Christian.Groves@er=
icsson.com</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, December 16, 2003 6:05 PM</FONT>
<BR><FONT SIZE=3D2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; =
bvswamy@hss.hns.com; anilj@cisco.com</FONT>
<BR><FONT SIZE=3D2>Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT =
[CAR:5N00:EXCH]; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Megaco] Descriptor processing on =
Termination OOS</FONT>
</P>

<P><FONT SIZE=3D2>Hello,</FONT>
</P>

<P><FONT SIZE=3D2>OOS Service by its nature must be reported by a =
ServiceChange, this can be through Forced which states: At a minimum, =
the Termination shall be subtracted from the Context. Graceful is =
similar that the MGC is expected to &quot;clean up&quot; the =
termination ultimately by subtracting the termination.</FONT></P>

<P><FONT SIZE=3D2>So for ephemeral terminations there's no discussion =
as they'll disappear the MGC won't be able to do anything to them. For =
physical terminations the following rule applies:</FONT></P>

<P><FONT SIZE=3D2>H.248.1 6.2.4 Termination properties and descriptors =
...</FONT>
<BR><FONT SIZE=3D2>If not provisioned otherwise, the properties in all =
descriptors except TerminationState and LocalControl default to =
empty/&quot;no value&quot; when a Termination is first created or =
returned to the null Context.</FONT></P>

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

<P><FONT SIZE=3D2>This text is very clear when a termination goes back =
to the NULL context which for TDM terminations is the result of going =
&quot;out of service&quot; the descriptors ARE changed.</FONT></P>

<P><FONT SIZE=3D2>I can remember that this behaviour caused quite a bit =
of discussion at the time (I think Tom drafted the text) and it was =
felt that this was the best behaviour because it left terminations in a =
known state both for the MG and MGC.</FONT></P>

<P><FONT SIZE=3D2>Regards, Christian</FONT>
</P>

<P><FONT SIZE=3D2>Kevin Boyle wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Comments inline [KJBII]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Kevin</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: bvswamy@hss.hns.com [<A =
HREF=3D"mailto:bvswamy@hss.hns.com">mailto:bvswamy@hss.hns.com</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, December 16, 2003 9:03 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: anilj@cisco.com</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT =
[CAR:5N00:EXCH]; </FONT>
<BR><FONT SIZE=3D2>&gt; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Megaco] Descriptor processing on =
Termination OOS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Please find =
my comments embedded.[BVS].</FONT>
<BR><FONT SIZE=3D2>&gt; Regards</FONT>
<BR><FONT SIZE=3D2>&gt; Venkat</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Anil Jangam \(anilj\)&quot; =
&lt;anilj@cisco.com&gt;@ietf.org on 12/16/2003</FONT>
<BR><FONT SIZE=3D2>&gt; 01:33:27 PM</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please respond to =
&lt;anilj@cisco.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sent by:&nbsp;&nbsp;&nbsp; =
megaco-admin@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp;&nbsp; megaco_maillist@HSS, =
&quot;'Tom Taylor'&quot; &lt;taylor@nortelnetworks.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; cc:&nbsp;&nbsp;&nbsp; =
&lt;megaco@ietf.org&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp;&nbsp;&nbsp; RE: [Megaco] =
Descriptor processing on Termination OOS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; From: megaco-admin@ietf.org [<A =
HREF=3D"mailto:megaco-admin@ietf.org">mailto:megaco-admin@ietf.org</A>] =
On </FONT>
<BR><FONT SIZE=3D2>&gt; Behalf&nbsp; &gt; Of =
megaco_maillist@hss.hns.com&nbsp; &gt; Sent: Tuesday, December </FONT>
<BR><FONT SIZE=3D2>&gt; 16, 2003 11:53 AM&nbsp; &gt; To: Tom =
Taylor&nbsp; &gt; Cc: megaco@ietf.org&nbsp; &gt; Subject: </FONT>
<BR><FONT SIZE=3D2>&gt; Re: [Megaco] Descriptor processing on =
Termination OOS&nbsp; &gt;&nbsp; &gt;&nbsp; &gt;&nbsp; &gt;&nbsp; =
&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Hi</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
In my opinion keeping the descriptors alive and enabled for a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; termination which is in Out of =
Service state does not seems to be a&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; valid behaviour of MG. For example if the =
card containing the&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; termination is jacked out of the chasis then =
definately at the&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; hardware level all the events and signals get =
disabled.&nbsp; There would&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; be a major disconnect wrt descriptors =
state if MGC does not audit </FONT>
<BR><FONT SIZE=3D2>&gt; the&nbsp; &gt; termination since if&nbsp; MGC =
were to audit the termination then</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; MG would be returning =
empty&nbsp;&nbsp; descriptors in this particular</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; case.&nbsp; Now&nbsp; in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; this condition if the card is =
jacked-in and termination is made&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; in-service then the exact state of original =
descriptors no more holds&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; good and mgc needs to apply the =
descriptors again.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Hence for a termination which is in Out-of-Service state MGC can</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; fairly assume that all descriptors =
are no more valid and whenever </FONT>
<BR><FONT SIZE=3D2>&gt; the&nbsp; &gt; termination comes up will =
reapply the descriptors afresh. This&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; assumption holds true whether or not =
termination is involved in a&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; call.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; First thing, there is no provision for the MG =
to change the state of </FONT>
<BR><FONT SIZE=3D2>&gt; the descriptor by its own. If we see the =
commands that can change the </FONT>
<BR><FONT SIZE=3D2>&gt; descriptor state, these are commands which MGC =
initiate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [BVS] I agree with you from the protocol =
perspective. But, if you </FONT>
<BR><FONT SIZE=3D2>&gt; analyse the actual scenario, service change (to =
out-of-service) for a </FONT>
<BR><FONT SIZE=3D2>&gt; termination would mean disabling operations =
such as signals/ events/ </FONT>
<BR><FONT SIZE=3D2>&gt; streams. Further, this would mean that MG does =
take some action on its </FONT>
<BR><FONT SIZE=3D2>&gt; own when it generates a Service Change (or MGC =
sends a service change) </FONT>
<BR><FONT SIZE=3D2>&gt; on the termination.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If MG returns the descriptors in Audit response =
it would mean </FONT>
<BR><FONT SIZE=3D2>&gt; incorrect representation of facts to =
MGC.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [KJBII] The MG may not take action on its own, =
whether we are talking </FONT>
<BR><FONT SIZE=3D2>&gt; about a hardware failure or some other =
occurrence.&nbsp; The text is</FONT>
<BR><FONT SIZE=3D2>&gt; explicit: the MG may not reset those =
descriptors.&nbsp; If the MGC wanted </FONT>
<BR><FONT SIZE=3D2>&gt; to audit, it may very well be to collect =
diagnostic data.&nbsp; If the MG </FONT>
<BR><FONT SIZE=3D2>&gt; wipes them out, then that data is lost.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In the SVC with SVCMethod =3D forced, its =
mentioned that MGC is going to </FONT>
<BR><FONT SIZE=3D2>&gt; clean up the context, in which case it is to =
subtract the termination </FONT>
<BR><FONT SIZE=3D2>&gt; from the cotext. At this point MGC can reset =
the descriptor state to </FONT>
<BR><FONT SIZE=3D2>&gt; the default if necessary. Same logic can be =
applied when the SVCMethod </FONT>
<BR><FONT SIZE=3D2>&gt; is graceful.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [BVS] Cleaning up the context using subtract is =
OK for terminations in </FONT>
<BR><FONT SIZE=3D2>&gt; a valid context. But, what about the =
terminations which are already in </FONT>
<BR><FONT SIZE=3D2>&gt; the null context.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [KJBII] What about them?&nbsp; Modifies are =
allowed on OOS terminations.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; The MGC could very well send a modify to empty =
the descriptors.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In the call flows as well, when the termination =
is coming back into </FONT>
<BR><FONT SIZE=3D2>&gt; the service, normally a Modify is sent to MG =
initializing the term.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [BVS] Based upon our experience in the interop =
events, this MODIFY is </FONT>
<BR><FONT SIZE=3D2>&gt; applicable to only certain call scenarios (e.g. =
POTS call) and not for </FONT>
<BR><FONT SIZE=3D2>&gt; other scenarios (like Trunkling).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Moreover, it is not used for clean up =
operations (like empty Signal </FONT>
<BR><FONT SIZE=3D2>&gt; descriptor, empty media descriptor etc.), but =
for the call setup (like </FONT>
<BR><FONT SIZE=3D2>&gt; event descriptor with OffHook).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [KJBII]&nbsp; MGCs that do not reset the state =
of the descriptors upon </FONT>
<BR><FONT SIZE=3D2>&gt; return to service will be subject to its own =
problems.&nbsp; It seems to me </FONT>
<BR><FONT SIZE=3D2>&gt; that the MGC would want to make sure the =
descriptors are in a </FONT>
<BR><FONT SIZE=3D2>&gt; particular state by explicitly making them that =
way.&nbsp; Further, I know </FONT>
<BR><FONT SIZE=3D2>&gt; of several implementations that send empty =
descriptors in Modify </FONT>
<BR><FONT SIZE=3D2>&gt; commands.&nbsp; Any assumption that they are =
not used for normal call </FONT>
<BR><FONT SIZE=3D2>&gt; processing operations is deficient.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So given this, IMO we don't have to make any =
assumption about the </FONT>
<BR><FONT SIZE=3D2>&gt; descriptor state once its taken OOS.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Regards</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Venkat</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Tom Taylor =
&lt;taylor@nortelnetworks.com&gt;@ietf.org on 12/01/2003&nbsp; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt; 11:52:03 PM&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Sent by:&nbsp;&nbsp;&nbsp; =
megaco-admin@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; To:&nbsp;&nbsp;&nbsp; Sampath =
Komanduri &lt;sampathk@cisco.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; cc:&nbsp;&nbsp;&nbsp; =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Subject:&nbsp;&nbsp;&nbsp; Re: =
[Megaco] Descriptor processing on Termination OOS</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; The descriptors (aside from =
TerminationState) remain unchanged </FONT>
<BR><FONT SIZE=3D2>&gt; until&nbsp; &gt; either the MGC changes them or =
the MG undergoes a cold restart.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Sampath Komanduri wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3C4B9.84C717E0--

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


From exim@www1.ietf.org  Wed Dec 17 11:22:38 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17890
	for <megaco-archive@odin.ietf.org>; Wed, 17 Dec 2003 11:22:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWeR7-0000o1-4M
	for megaco-archive@odin.ietf.org; Wed, 17 Dec 2003 11:22:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHGM9T9003097
	for megaco-archive@odin.ietf.org; Wed, 17 Dec 2003 11:22:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWeR7-0000nr-14
	for megaco-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 11:22:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17861
	for <megaco-web-archive@ietf.org>; Wed, 17 Dec 2003 11:22:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWeR6-0004wv-00
	for megaco-web-archive@ietf.org; Wed, 17 Dec 2003 11:22:08 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWeR3-0004wl-00
	for megaco-web-archive@ietf.org; Wed, 17 Dec 2003 11:22:07 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWeR3-0004wi-00
	for megaco-web-archive@ietf.org; Wed, 17 Dec 2003 11:22:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWeQy-0000ml-VG; Wed, 17 Dec 2003 11:22:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWeQu-0000mV-Kb
	for megaco@optimus.ietf.org; Wed, 17 Dec 2003 11:21:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17853
	for <megaco@ietf.org>; Wed, 17 Dec 2003 11:21:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWeQt-0004wP-00
	for megaco@ietf.org; Wed, 17 Dec 2003 11:21:55 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWeQq-0004wI-00
	for megaco@ietf.org; Wed, 17 Dec 2003 11:21:55 -0500
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWeQq-0004v2-00
	for megaco@ietf.org; Wed, 17 Dec 2003 11:21:52 -0500
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 hBHGJJJ24323;
	Wed, 17 Dec 2003 11:19:19 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <Y2Y16MKJ>; Wed, 17 Dec 2003 11:19:20 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0D4B39FC@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Christian Groves <Christian.Groves@ericsson.com>, bvswamy@hss.hns.com,
        anilj@cisco.com
Cc: megaco_maillist@hss.hns.com, "Tom-PT Taylor" <taylor@nortelnetworks.com>,
        megaco@ietf.org
Subject: RE: [Megaco] Descriptor processing on Termination OOS
Date: Wed, 17 Dec 2003 11:19:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C4B9.84C717E0"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60

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_01C3C4B9.84C717E0
Content-Type: text/plain

Right.  I just wanted to ensure that everyone understands that the reset of
the descriptors is a result of the SUBTRACT, and not a result of the
SERVICECHANGE.

Subtle, but important, difference.

Kevin 

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com] 
Sent: Tuesday, December 16, 2003 6:05 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; bvswamy@hss.hns.com; anilj@cisco.com
Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH];
megaco@ietf.org
Subject: Re: [Megaco] Descriptor processing on Termination OOS

Hello,

OOS Service by its nature must be reported by a ServiceChange, this can be
through Forced which states: At a minimum, the Termination shall be
subtracted from the Context. Graceful is similar that the MGC is expected to
"clean up" the termination ultimately by subtracting the termination.

So for ephemeral terminations there's no discussion as they'll disappear the
MGC won't be able to do anything to them. For physical terminations the
following rule applies:

H.248.1 6.2.4 Termination properties and descriptors ...
If not provisioned otherwise, the properties in all descriptors except
TerminationState and LocalControl default to empty/"no value" when a
Termination is first created or returned to the null Context.
...

This text is very clear when a termination goes back to the NULL context
which for TDM terminations is the result of going "out of service" the
descriptors ARE changed.

I can remember that this behaviour caused quite a bit of discussion at the
time (I think Tom drafted the text) and it was felt that this was the best
behaviour because it left terminations in a known state both for the MG and
MGC.

Regards, Christian

Kevin Boyle wrote:

> Comments inline [KJBII]
> 
> Kevin
> 
> -----Original Message-----
> From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com]
> Sent: Tuesday, December 16, 2003 9:03 AM
> To: anilj@cisco.com
> Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT [CAR:5N00:EXCH]; 
> megaco@ietf.org
> Subject: RE: [Megaco] Descriptor processing on Termination OOS
> 
> 
> 
> 
> 
> Hi
>       Please find my comments embedded.[BVS].
> Regards
> Venkat
> 
> 
> 
> 
> 
> "Anil Jangam \(anilj\)" <anilj@cisco.com>@ietf.org on 12/16/2003
> 01:33:27 PM
> 
> Please respond to <anilj@cisco.com>
> 
> Sent by:    megaco-admin@ietf.org
> 
> 
> To:    megaco_maillist@HSS, "'Tom Taylor'" <taylor@nortelnetworks.com>
> cc:    <megaco@ietf.org>
> 
> Subject:    RE: [Megaco] Descriptor processing on Termination OOS
> 
> 
> 
> 
>  > -----Original Message-----
>  > From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On 
> Behalf  > Of megaco_maillist@hss.hns.com  > Sent: Tuesday, December 
> 16, 2003 11:53 AM  > To: Tom Taylor  > Cc: megaco@ietf.org  > Subject: 
> Re: [Megaco] Descriptor processing on Termination OOS  >  >  >  >  >  
> >  > Hi
>  >       In my opinion keeping the descriptors alive and enabled for a
>  > termination which is in Out of Service state does not seems to be a  
> > valid behaviour of MG. For example if the card containing the  > 
> termination is jacked out of the chasis then definately at the  > 
> hardware level all the events and signals get disabled.  There would  
> > be a major disconnect wrt descriptors state if MGC does not audit 
> the  > termination since if  MGC were to audit the termination then
>  > MG would be returning empty   descriptors in this particular
>  > case.  Now  in
>  > this condition if the card is jacked-in and termination is made  > 
> in-service then the exact state of original descriptors no more holds  
> > good and mgc needs to apply the descriptors again.
>  >
>  >       Hence for a termination which is in Out-of-Service state MGC can
>  > fairly assume that all descriptors are no more valid and whenever 
> the  > termination comes up will reapply the descriptors afresh. This  
> > assumption holds true whether or not termination is involved in a  > 
> call.
> 
> First thing, there is no provision for the MG to change the state of 
> the descriptor by its own. If we see the commands that can change the 
> descriptor state, these are commands which MGC initiate.
> 
> [BVS] I agree with you from the protocol perspective. But, if you 
> analyse the actual scenario, service change (to out-of-service) for a 
> termination would mean disabling operations such as signals/ events/ 
> streams. Further, this would mean that MG does take some action on its 
> own when it generates a Service Change (or MGC sends a service change) 
> on the termination.
> 
> If MG returns the descriptors in Audit response it would mean 
> incorrect representation of facts to MGC.
> 
> [KJBII] The MG may not take action on its own, whether we are talking 
> about a hardware failure or some other occurrence.  The text is
> explicit: the MG may not reset those descriptors.  If the MGC wanted 
> to audit, it may very well be to collect diagnostic data.  If the MG 
> wipes them out, then that data is lost.
> 
> In the SVC with SVCMethod = forced, its mentioned that MGC is going to 
> clean up the context, in which case it is to subtract the termination 
> from the cotext. At this point MGC can reset the descriptor state to 
> the default if necessary. Same logic can be applied when the SVCMethod 
> is graceful.
> 
> [BVS] Cleaning up the context using subtract is OK for terminations in 
> a valid context. But, what about the terminations which are already in 
> the null context.
> 
> [KJBII] What about them?  Modifies are allowed on OOS terminations.  
> The MGC could very well send a modify to empty the descriptors.
> 
> 
> In the call flows as well, when the termination is coming back into 
> the service, normally a Modify is sent to MG initializing the term.
> 
> 
> [BVS] Based upon our experience in the interop events, this MODIFY is 
> applicable to only certain call scenarios (e.g. POTS call) and not for 
> other scenarios (like Trunkling).
> 
> Moreover, it is not used for clean up operations (like empty Signal 
> descriptor, empty media descriptor etc.), but for the call setup (like 
> event descriptor with OffHook).
> 
> [KJBII]  MGCs that do not reset the state of the descriptors upon 
> return to service will be subject to its own problems.  It seems to me 
> that the MGC would want to make sure the descriptors are in a 
> particular state by explicitly making them that way.  Further, I know 
> of several implementations that send empty descriptors in Modify 
> commands.  Any assumption that they are not used for normal call 
> processing operations is deficient.
> 
> 
> So given this, IMO we don't have to make any assumption about the 
> descriptor state once its taken OOS.
> 
>  >
>  > Regards
>  > Venkat
>  >
>  >
>  >
>  >
>  >
>  > Tom Taylor <taylor@nortelnetworks.com>@ietf.org on 12/01/2003  > 
> 11:52:03 PM  >
>  > Sent by:    megaco-admin@ietf.org
>  >
>  >
>  > To:    Sampath Komanduri <sampathk@cisco.com>
>  > cc:    megaco@ietf.org
>  >
>  > Subject:    Re: [Megaco] Descriptor processing on Termination OOS
>  >
>  >
>  > The descriptors (aside from TerminationState) remain unchanged 
> until  > either the MGC changes them or the MG undergoes a cold restart.
>  >
>  > Sampath Komanduri wrote:
>  >
> 


------_=_NextPart_001_01C3C4B9.84C717E0
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [Megaco] Descriptor processing on Termination OOS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Right.&nbsp; I just wanted to ensure that everyone =
understands that the reset of the descriptors is a result of the =
SUBTRACT, and not a result of the SERVICECHANGE.</FONT></P>

<P><FONT SIZE=3D2>Subtle, but important, difference.</FONT>
</P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Christian Groves [<A =
HREF=3D"mailto:Christian.Groves@ericsson.com">mailto:Christian.Groves@er=
icsson.com</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, December 16, 2003 6:05 PM</FONT>
<BR><FONT SIZE=3D2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; =
bvswamy@hss.hns.com; anilj@cisco.com</FONT>
<BR><FONT SIZE=3D2>Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT =
[CAR:5N00:EXCH]; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Megaco] Descriptor processing on =
Termination OOS</FONT>
</P>

<P><FONT SIZE=3D2>Hello,</FONT>
</P>

<P><FONT SIZE=3D2>OOS Service by its nature must be reported by a =
ServiceChange, this can be through Forced which states: At a minimum, =
the Termination shall be subtracted from the Context. Graceful is =
similar that the MGC is expected to &quot;clean up&quot; the =
termination ultimately by subtracting the termination.</FONT></P>

<P><FONT SIZE=3D2>So for ephemeral terminations there's no discussion =
as they'll disappear the MGC won't be able to do anything to them. For =
physical terminations the following rule applies:</FONT></P>

<P><FONT SIZE=3D2>H.248.1 6.2.4 Termination properties and descriptors =
...</FONT>
<BR><FONT SIZE=3D2>If not provisioned otherwise, the properties in all =
descriptors except TerminationState and LocalControl default to =
empty/&quot;no value&quot; when a Termination is first created or =
returned to the null Context.</FONT></P>

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

<P><FONT SIZE=3D2>This text is very clear when a termination goes back =
to the NULL context which for TDM terminations is the result of going =
&quot;out of service&quot; the descriptors ARE changed.</FONT></P>

<P><FONT SIZE=3D2>I can remember that this behaviour caused quite a bit =
of discussion at the time (I think Tom drafted the text) and it was =
felt that this was the best behaviour because it left terminations in a =
known state both for the MG and MGC.</FONT></P>

<P><FONT SIZE=3D2>Regards, Christian</FONT>
</P>

<P><FONT SIZE=3D2>Kevin Boyle wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Comments inline [KJBII]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Kevin</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: bvswamy@hss.hns.com [<A =
HREF=3D"mailto:bvswamy@hss.hns.com">mailto:bvswamy@hss.hns.com</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, December 16, 2003 9:03 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: anilj@cisco.com</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT =
[CAR:5N00:EXCH]; </FONT>
<BR><FONT SIZE=3D2>&gt; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Megaco] Descriptor processing on =
Termination OOS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Please find =
my comments embedded.[BVS].</FONT>
<BR><FONT SIZE=3D2>&gt; Regards</FONT>
<BR><FONT SIZE=3D2>&gt; Venkat</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Anil Jangam \(anilj\)&quot; =
&lt;anilj@cisco.com&gt;@ietf.org on 12/16/2003</FONT>
<BR><FONT SIZE=3D2>&gt; 01:33:27 PM</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please respond to =
&lt;anilj@cisco.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sent by:&nbsp;&nbsp;&nbsp; =
megaco-admin@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp;&nbsp; megaco_maillist@HSS, =
&quot;'Tom Taylor'&quot; &lt;taylor@nortelnetworks.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; cc:&nbsp;&nbsp;&nbsp; =
&lt;megaco@ietf.org&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp;&nbsp;&nbsp; RE: [Megaco] =
Descriptor processing on Termination OOS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; From: megaco-admin@ietf.org [<A =
HREF=3D"mailto:megaco-admin@ietf.org">mailto:megaco-admin@ietf.org</A>] =
On </FONT>
<BR><FONT SIZE=3D2>&gt; Behalf&nbsp; &gt; Of =
megaco_maillist@hss.hns.com&nbsp; &gt; Sent: Tuesday, December </FONT>
<BR><FONT SIZE=3D2>&gt; 16, 2003 11:53 AM&nbsp; &gt; To: Tom =
Taylor&nbsp; &gt; Cc: megaco@ietf.org&nbsp; &gt; Subject: </FONT>
<BR><FONT SIZE=3D2>&gt; Re: [Megaco] Descriptor processing on =
Termination OOS&nbsp; &gt;&nbsp; &gt;&nbsp; &gt;&nbsp; &gt;&nbsp; =
&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Hi</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
In my opinion keeping the descriptors alive and enabled for a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; termination which is in Out of =
Service state does not seems to be a&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; valid behaviour of MG. For example if the =
card containing the&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; termination is jacked out of the chasis then =
definately at the&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; hardware level all the events and signals get =
disabled.&nbsp; There would&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; be a major disconnect wrt descriptors =
state if MGC does not audit </FONT>
<BR><FONT SIZE=3D2>&gt; the&nbsp; &gt; termination since if&nbsp; MGC =
were to audit the termination then</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; MG would be returning =
empty&nbsp;&nbsp; descriptors in this particular</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; case.&nbsp; Now&nbsp; in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; this condition if the card is =
jacked-in and termination is made&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; in-service then the exact state of original =
descriptors no more holds&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; good and mgc needs to apply the =
descriptors again.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Hence for a termination which is in Out-of-Service state MGC can</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; fairly assume that all descriptors =
are no more valid and whenever </FONT>
<BR><FONT SIZE=3D2>&gt; the&nbsp; &gt; termination comes up will =
reapply the descriptors afresh. This&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; assumption holds true whether or not =
termination is involved in a&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; call.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; First thing, there is no provision for the MG =
to change the state of </FONT>
<BR><FONT SIZE=3D2>&gt; the descriptor by its own. If we see the =
commands that can change the </FONT>
<BR><FONT SIZE=3D2>&gt; descriptor state, these are commands which MGC =
initiate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [BVS] I agree with you from the protocol =
perspective. But, if you </FONT>
<BR><FONT SIZE=3D2>&gt; analyse the actual scenario, service change (to =
out-of-service) for a </FONT>
<BR><FONT SIZE=3D2>&gt; termination would mean disabling operations =
such as signals/ events/ </FONT>
<BR><FONT SIZE=3D2>&gt; streams. Further, this would mean that MG does =
take some action on its </FONT>
<BR><FONT SIZE=3D2>&gt; own when it generates a Service Change (or MGC =
sends a service change) </FONT>
<BR><FONT SIZE=3D2>&gt; on the termination.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If MG returns the descriptors in Audit response =
it would mean </FONT>
<BR><FONT SIZE=3D2>&gt; incorrect representation of facts to =
MGC.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [KJBII] The MG may not take action on its own, =
whether we are talking </FONT>
<BR><FONT SIZE=3D2>&gt; about a hardware failure or some other =
occurrence.&nbsp; The text is</FONT>
<BR><FONT SIZE=3D2>&gt; explicit: the MG may not reset those =
descriptors.&nbsp; If the MGC wanted </FONT>
<BR><FONT SIZE=3D2>&gt; to audit, it may very well be to collect =
diagnostic data.&nbsp; If the MG </FONT>
<BR><FONT SIZE=3D2>&gt; wipes them out, then that data is lost.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In the SVC with SVCMethod =3D forced, its =
mentioned that MGC is going to </FONT>
<BR><FONT SIZE=3D2>&gt; clean up the context, in which case it is to =
subtract the termination </FONT>
<BR><FONT SIZE=3D2>&gt; from the cotext. At this point MGC can reset =
the descriptor state to </FONT>
<BR><FONT SIZE=3D2>&gt; the default if necessary. Same logic can be =
applied when the SVCMethod </FONT>
<BR><FONT SIZE=3D2>&gt; is graceful.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [BVS] Cleaning up the context using subtract is =
OK for terminations in </FONT>
<BR><FONT SIZE=3D2>&gt; a valid context. But, what about the =
terminations which are already in </FONT>
<BR><FONT SIZE=3D2>&gt; the null context.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [KJBII] What about them?&nbsp; Modifies are =
allowed on OOS terminations.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; The MGC could very well send a modify to empty =
the descriptors.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In the call flows as well, when the termination =
is coming back into </FONT>
<BR><FONT SIZE=3D2>&gt; the service, normally a Modify is sent to MG =
initializing the term.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [BVS] Based upon our experience in the interop =
events, this MODIFY is </FONT>
<BR><FONT SIZE=3D2>&gt; applicable to only certain call scenarios (e.g. =
POTS call) and not for </FONT>
<BR><FONT SIZE=3D2>&gt; other scenarios (like Trunkling).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Moreover, it is not used for clean up =
operations (like empty Signal </FONT>
<BR><FONT SIZE=3D2>&gt; descriptor, empty media descriptor etc.), but =
for the call setup (like </FONT>
<BR><FONT SIZE=3D2>&gt; event descriptor with OffHook).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [KJBII]&nbsp; MGCs that do not reset the state =
of the descriptors upon </FONT>
<BR><FONT SIZE=3D2>&gt; return to service will be subject to its own =
problems.&nbsp; It seems to me </FONT>
<BR><FONT SIZE=3D2>&gt; that the MGC would want to make sure the =
descriptors are in a </FONT>
<BR><FONT SIZE=3D2>&gt; particular state by explicitly making them that =
way.&nbsp; Further, I know </FONT>
<BR><FONT SIZE=3D2>&gt; of several implementations that send empty =
descriptors in Modify </FONT>
<BR><FONT SIZE=3D2>&gt; commands.&nbsp; Any assumption that they are =
not used for normal call </FONT>
<BR><FONT SIZE=3D2>&gt; processing operations is deficient.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So given this, IMO we don't have to make any =
assumption about the </FONT>
<BR><FONT SIZE=3D2>&gt; descriptor state once its taken OOS.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Regards</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Venkat</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Tom Taylor =
&lt;taylor@nortelnetworks.com&gt;@ietf.org on 12/01/2003&nbsp; &gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt; 11:52:03 PM&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Sent by:&nbsp;&nbsp;&nbsp; =
megaco-admin@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; To:&nbsp;&nbsp;&nbsp; Sampath =
Komanduri &lt;sampathk@cisco.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; cc:&nbsp;&nbsp;&nbsp; =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Subject:&nbsp;&nbsp;&nbsp; Re: =
[Megaco] Descriptor processing on Termination OOS</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; The descriptors (aside from =
TerminationState) remain unchanged </FONT>
<BR><FONT SIZE=3D2>&gt; until&nbsp; &gt; either the MGC changes them or =
the MG undergoes a cold restart.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Sampath Komanduri wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3C4B9.84C717E0--

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



From megaco-admin@ietf.org  Thu Dec 18 16:33:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21995
	for <megaco-archive@lists.ietf.org>; Thu, 18 Dec 2003 16:33:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AX5lV-0001Ug-G9; Thu, 18 Dec 2003 16:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AX5lK-0001UP-NX
	for megaco@optimus.ietf.org; Thu, 18 Dec 2003 16:32:50 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21801
	for <megaco@ietf.org>; Thu, 18 Dec 2003 16:32:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AX5lI-0003Y3-00
	for megaco@ietf.org; Thu, 18 Dec 2003 16:32:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AX5l4-0003Uh-00
	for megaco@ietf.org; Thu, 18 Dec 2003 16:32:47 -0500
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AX5l3-0003Qr-00
	for megaco@ietf.org; Thu, 18 Dec 2003 16:32:33 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBILVmM07779
	for <megaco@ietf.org>; Thu, 18 Dec 2003 15:31:49 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA25212; Thu, 18 Dec 2003 16:31:19 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA25208; Thu, 18 Dec 2003 16:31:19 -0500 (EST)
Message-ID: <3FE21CA2.7020108@bell-labs.com>
Date: Thu, 18 Dec 2003 16:31:14 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] wildcarding question
References: <3FDE2122.8010703@bell-labs.com>
In-Reply-To: <3FDE2122.8010703@bell-labs.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Anyone have an opinion???

-troy


Troy Cauble wrote:

> 
> Regarding 6.6.1 in the IG.
> 
> Should
>     Context = 1 { Command=*{Descriptor/s}}
> 
> return
>     Context = 1 {Command=t1/1{Descriptor/s},
>                  Command=t2/1{Descriptor/s}}
> or
>     Context = 1 {Command=t1/1{Descriptor/s}}
>     Context = 1 {Command=t2/1{Descriptor/s}}
> 
> The text says "identical to repeating the command with each of the
> TerminationIDs", so I think the former is correct, but I'm not positive.
> 
> 
> 
> Also, regarding 6.6.4, wildcard responses:
> A wildcard resonse request happens at the command level.
> What if wildcard response commands and non-wildcard response commands
> exist in the same request context?
> 
>     Context = * { Command=*{Descriptor/s},
>                   W-Command=*{Descriptor/s},
>                   Command=*{Descriptor/s}}
> 
> -troy



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


From exim@www1.ietf.org  Thu Dec 18 16:33:47 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22014
	for <megaco-archive@odin.ietf.org>; Thu, 18 Dec 2003 16:33:46 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AX5ln-0001W4-1c
	for megaco-archive@odin.ietf.org; Thu, 18 Dec 2003 16:33:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBILXITb005819
	for megaco-archive@odin.ietf.org; Thu, 18 Dec 2003 16:33:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AX5lm-0001Vm-RK
	for megaco-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 16:33:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21933
	for <megaco-web-archive@ietf.org>; Thu, 18 Dec 2003 16:33:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AX5lk-0003c7-00
	for megaco-web-archive@ietf.org; Thu, 18 Dec 2003 16:33:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AX5lb-0003ap-00
	for megaco-web-archive@ietf.org; Thu, 18 Dec 2003 16:33:16 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AX5la-0003al-00
	for megaco-web-archive@ietf.org; Thu, 18 Dec 2003 16:33:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AX5lV-0001Ug-G9; Thu, 18 Dec 2003 16:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AX5lK-0001UP-NX
	for megaco@optimus.ietf.org; Thu, 18 Dec 2003 16:32:50 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21801
	for <megaco@ietf.org>; Thu, 18 Dec 2003 16:32:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AX5lI-0003Y3-00
	for megaco@ietf.org; Thu, 18 Dec 2003 16:32:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AX5l4-0003Uh-00
	for megaco@ietf.org; Thu, 18 Dec 2003 16:32:47 -0500
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AX5l3-0003Qr-00
	for megaco@ietf.org; Thu, 18 Dec 2003 16:32:33 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBILVmM07779
	for <megaco@ietf.org>; Thu, 18 Dec 2003 15:31:49 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA25212; Thu, 18 Dec 2003 16:31:19 -0500 (EST)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id QAA25208; Thu, 18 Dec 2003 16:31:19 -0500 (EST)
Message-ID: <3FE21CA2.7020108@bell-labs.com>
Date: Thu, 18 Dec 2003 16:31:14 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] wildcarding question
References: <3FDE2122.8010703@bell-labs.com>
In-Reply-To: <3FDE2122.8010703@bell-labs.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: 7bit

Anyone have an opinion???

-troy


Troy Cauble wrote:

> 
> Regarding 6.6.1 in the IG.
> 
> Should
>     Context = 1 { Command=*{Descriptor/s}}
> 
> return
>     Context = 1 {Command=t1/1{Descriptor/s},
>                  Command=t2/1{Descriptor/s}}
> or
>     Context = 1 {Command=t1/1{Descriptor/s}}
>     Context = 1 {Command=t2/1{Descriptor/s}}
> 
> The text says "identical to repeating the command with each of the
> TerminationIDs", so I think the former is correct, but I'm not positive.
> 
> 
> 
> Also, regarding 6.6.4, wildcard responses:
> A wildcard resonse request happens at the command level.
> What if wildcard response commands and non-wildcard response commands
> exist in the same request context?
> 
>     Context = * { Command=*{Descriptor/s},
>                   W-Command=*{Descriptor/s},
>                   Command=*{Descriptor/s}}
> 
> -troy



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



From megaco-admin@ietf.org  Thu Dec 18 16:38:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22272
	for <megaco-archive@lists.ietf.org>; Thu, 18 Dec 2003 16:38:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AX5qM-0001vc-2k; Thu, 18 Dec 2003 16:38:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AX5pd-0001kf-ES
	for megaco@optimus.ietf.org; Thu, 18 Dec 2003 16:37:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22246
	for <megaco@ietf.org>; Thu, 18 Dec 2003 16:37:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AX5pb-0003m0-00
	for megaco@ietf.org; Thu, 18 Dec 2003 16:37:15 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AX5pa-0003lt-00
	for megaco@ietf.org; Thu, 18 Dec 2003 16:37:15 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AX5pa-0003lq-00
	for megaco@ietf.org; Thu, 18 Dec 2003 16:37:14 -0500
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <XM89Q74Y>; Thu, 18 Dec 2003 16:37:14 -0500
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA03506256@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'Troy Cauble'" <troy@bell-labs.com>, MEGACO list <megaco@ietf.org>
Subject: RE: [Megaco] wildcarding question
Date: Thu, 18 Dec 2003 16:37:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
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
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

The former case, 1 context.

CArl

-----Original Message-----
From: Troy Cauble [mailto:troy@bell-labs.com]
Sent: Thursday, December 18, 2003 4:31 PM
To: MEGACO list
Subject: Re: [Megaco] wildcarding question


Anyone have an opinion???

-troy


Troy Cauble wrote:

> 
> Regarding 6.6.1 in the IG.
> 
> Should
>     Context = 1 { Command=*{Descriptor/s}}
> 
> return
>     Context = 1 {Command=t1/1{Descriptor/s},
>                  Command=t2/1{Descriptor/s}}
> or
>     Context = 1 {Command=t1/1{Descriptor/s}}
>     Context = 1 {Command=t2/1{Descriptor/s}}
> 
> The text says "identical to repeating the command with each of the
> TerminationIDs", so I think the former is correct, but I'm not positive.
> 
> 
> 
> Also, regarding 6.6.4, wildcard responses:
> A wildcard resonse request happens at the command level.
> What if wildcard response commands and non-wildcard response commands
> exist in the same request context?
> 
>     Context = * { Command=*{Descriptor/s},
>                   W-Command=*{Descriptor/s},
>                   Command=*{Descriptor/s}}
> 
> -troy



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

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


From exim@www1.ietf.org  Thu Dec 18 16:38:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22301
	for <megaco-archive@odin.ietf.org>; Thu, 18 Dec 2003 16:38:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AX5qO-0001xZ-Pi
	for megaco-archive@odin.ietf.org; Thu, 18 Dec 2003 16:38:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBILc4wM007522
	for megaco-archive@odin.ietf.org; Thu, 18 Dec 2003 16:38:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AX5qO-0001xF-Ev
	for megaco-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 16:38:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22266
	for <megaco-web-archive@ietf.org>; Thu, 18 Dec 2003 16:38:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AX5qM-0003mF-00
	for megaco-web-archive@ietf.org; Thu, 18 Dec 2003 16:38:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AX5qL-0003m7-00
	for megaco-web-archive@ietf.org; Thu, 18 Dec 2003 16:38:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AX5qL-0003m4-00
	for megaco-web-archive@ietf.org; Thu, 18 Dec 2003 16:38:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AX5qM-0001vc-2k; Thu, 18 Dec 2003 16:38:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AX5pd-0001kf-ES
	for megaco@optimus.ietf.org; Thu, 18 Dec 2003 16:37:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22246
	for <megaco@ietf.org>; Thu, 18 Dec 2003 16:37:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AX5pb-0003m0-00
	for megaco@ietf.org; Thu, 18 Dec 2003 16:37:15 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AX5pa-0003lt-00
	for megaco@ietf.org; Thu, 18 Dec 2003 16:37:15 -0500
Received: from pat.telica.com ([4.19.224.196] helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AX5pa-0003lq-00
	for megaco@ietf.org; Thu, 18 Dec 2003 16:37:14 -0500
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <XM89Q74Y>; Thu, 18 Dec 2003 16:37:14 -0500
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA03506256@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'Troy Cauble'" <troy@bell-labs.com>, MEGACO list <megaco@ietf.org>
Subject: RE: [Megaco] wildcarding question
Date: Thu, 18 Dec 2003 16:37:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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

The former case, 1 context.

CArl

-----Original Message-----
From: Troy Cauble [mailto:troy@bell-labs.com]
Sent: Thursday, December 18, 2003 4:31 PM
To: MEGACO list
Subject: Re: [Megaco] wildcarding question


Anyone have an opinion???

-troy


Troy Cauble wrote:

> 
> Regarding 6.6.1 in the IG.
> 
> Should
>     Context = 1 { Command=*{Descriptor/s}}
> 
> return
>     Context = 1 {Command=t1/1{Descriptor/s},
>                  Command=t2/1{Descriptor/s}}
> or
>     Context = 1 {Command=t1/1{Descriptor/s}}
>     Context = 1 {Command=t2/1{Descriptor/s}}
> 
> The text says "identical to repeating the command with each of the
> TerminationIDs", so I think the former is correct, but I'm not positive.
> 
> 
> 
> Also, regarding 6.6.4, wildcard responses:
> A wildcard resonse request happens at the command level.
> What if wildcard response commands and non-wildcard response commands
> exist in the same request context?
> 
>     Context = * { Command=*{Descriptor/s},
>                   W-Command=*{Descriptor/s},
>                   Command=*{Descriptor/s}}
> 
> -troy



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

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



From megaco-admin@ietf.org  Fri Dec 19 01:39:32 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13774
	for <megaco-archive@lists.ietf.org>; Fri, 19 Dec 2003 01:39:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXEHt-0000nL-SP; Fri, 19 Dec 2003 01:39:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXEHA-0000mB-3F
	for megaco@optimus.ietf.org; Fri, 19 Dec 2003 01:38:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13750
	for <megaco@ietf.org>; Fri, 19 Dec 2003 01:38:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXEH6-00072k-00
	for megaco@ietf.org; Fri, 19 Dec 2003 01:38:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXEH6-00072d-00
	for megaco@ietf.org; Fri, 19 Dec 2003 01:38:12 -0500
Received: from [203.197.168.150] (helo=mailscanout256k.tataelxsi.co.in)
	by ietf-mx with smtp (Exim 4.12)
	id 1AXEH5-00072a-00
	for megaco@ietf.org; Fri, 19 Dec 2003 01:38:11 -0500
Received: FROM vscaninternal.tataelxsi.co.in BY mailscanout256k.tataelxsi.co.in ; Fri Dec 19 12:10:32 2003 +0500
Received: FROM bsh BY vscaninternal.tataelxsi.co.in ; Fri Dec 19 12:09:05 2003 +0500
From: "Shridhara B" <bsh@tataelxsi.co.in>
To: <megaco@ietf.org>
Date: Fri, 19 Dec 2003 12:08:13 +0530
Message-ID: <02de01c3c5fa$ade02670$d528010a@telxsi.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_02DF_01C3C628.C7986270"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
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=HTML_50_60,HTML_MESSAGE 
	autolearn=no version=2.60
Subject: [Megaco] Query on Codec List Event in TFO Package
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

This is a multi-part message in MIME format.

------=_NextPart_000_02DF_01C3C628.C7986270
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

The TFO package defined in 3GPP TS 29.232 V5.6.0 has Codec List Event. The
EventId is given as follows: -
EventID: distant codec_list (0x0012).

But the event name should not contain the space characters like above. Hence
it should be either, EventID: distantcodec_list (0x0012) or EventID:
distant_codec_list (0x0012).

Could you please confirm which one of the above is correct?

Thanks
Shridhara.B


------=_NextPart_000_02DF_01C3C628.C7986270
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.00.3700.6699" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D269332506-19122003>All,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D269332506-19122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D269332506-19122003>The TFO=20
package defined in 3GPP TS 29.232 V5.6.0 has Codec List Event. The =
EventId is=20
given as follows: -</SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#800080 face=3DArial><SPAN=20
class=3D269332506-19122003>EventID: distant codec_list=20
(0x0012).</SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN=20
class=3D269332506-19122003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D269332506-19122003>But the event=20
name should not contain the space characters like above. Hence it should =
be=20
either, </SPAN></FONT></FONT><FONT size=3D2><FONT face=3DArial><SPAN=20
class=3D269332506-19122003><FONT color=3D#800080>EventID: =
distantcodec_list=20
(0x0012)</FONT> or <FONT color=3D#800080>EventID: distant_codec_list=20
(0x0012)</FONT>.</SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN=20
class=3D269332506-19122003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D269332506-19122003>Could you=20
please confirm which one of the above is =
correct?</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D269332506-19122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Shridhara.B</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_02DF_01C3C628.C7986270--


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


From exim@www1.ietf.org  Fri Dec 19 01:39:42 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13800
	for <megaco-archive@odin.ietf.org>; Fri, 19 Dec 2003 01:39:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXEHx-0000o3-Tw
	for megaco-archive@odin.ietf.org; Fri, 19 Dec 2003 01:39:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJ6d51F003099
	for megaco-archive@odin.ietf.org; Fri, 19 Dec 2003 01:39:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXEHx-0000nt-OU
	for megaco-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 01:39:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13757
	for <megaco-web-archive@ietf.org>; Fri, 19 Dec 2003 01:39:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXEHu-00072y-00
	for megaco-web-archive@ietf.org; Fri, 19 Dec 2003 01:39:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXEHt-00072r-00
	for megaco-web-archive@ietf.org; Fri, 19 Dec 2003 01:39:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXEHt-00072o-00
	for megaco-web-archive@ietf.org; Fri, 19 Dec 2003 01:39:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXEHt-0000nL-SP; Fri, 19 Dec 2003 01:39:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXEHA-0000mB-3F
	for megaco@optimus.ietf.org; Fri, 19 Dec 2003 01:38:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13750
	for <megaco@ietf.org>; Fri, 19 Dec 2003 01:38:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXEH6-00072k-00
	for megaco@ietf.org; Fri, 19 Dec 2003 01:38:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXEH6-00072d-00
	for megaco@ietf.org; Fri, 19 Dec 2003 01:38:12 -0500
Received: from [203.197.168.150] (helo=mailscanout256k.tataelxsi.co.in)
	by ietf-mx with smtp (Exim 4.12)
	id 1AXEH5-00072a-00
	for megaco@ietf.org; Fri, 19 Dec 2003 01:38:11 -0500
Received: FROM vscaninternal.tataelxsi.co.in BY mailscanout256k.tataelxsi.co.in ; Fri Dec 19 12:10:32 2003 +0500
Received: FROM bsh BY vscaninternal.tataelxsi.co.in ; Fri Dec 19 12:09:05 2003 +0500
From: "Shridhara B" <bsh@tataelxsi.co.in>
To: <megaco@ietf.org>
Date: Fri, 19 Dec 2003 12:08:13 +0530
Message-ID: <02de01c3c5fa$ade02670$d528010a@telxsi.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_02DF_01C3C628.C7986270"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
Subject: [Megaco] Query on Codec List Event in TFO Package
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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=HTML_50_60,HTML_MESSAGE 
	autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_02DF_01C3C628.C7986270
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

The TFO package defined in 3GPP TS 29.232 V5.6.0 has Codec List Event. The
EventId is given as follows: -
EventID: distant codec_list (0x0012).

But the event name should not contain the space characters like above. Hence
it should be either, EventID: distantcodec_list (0x0012) or EventID:
distant_codec_list (0x0012).

Could you please confirm which one of the above is correct?

Thanks
Shridhara.B


------=_NextPart_000_02DF_01C3C628.C7986270
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.00.3700.6699" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D269332506-19122003>All,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D269332506-19122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D269332506-19122003>The TFO=20
package defined in 3GPP TS 29.232 V5.6.0 has Codec List Event. The =
EventId is=20
given as follows: -</SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#800080 face=3DArial><SPAN=20
class=3D269332506-19122003>EventID: distant codec_list=20
(0x0012).</SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN=20
class=3D269332506-19122003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D269332506-19122003>But the event=20
name should not contain the space characters like above. Hence it should =
be=20
either, </SPAN></FONT></FONT><FONT size=3D2><FONT face=3DArial><SPAN=20
class=3D269332506-19122003><FONT color=3D#800080>EventID: =
distantcodec_list=20
(0x0012)</FONT> or <FONT color=3D#800080>EventID: distant_codec_list=20
(0x0012)</FONT>.</SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN=20
class=3D269332506-19122003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D269332506-19122003>Could you=20
please confirm which one of the above is =
correct?</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D269332506-19122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Shridhara.B</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_02DF_01C3C628.C7986270--


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



From megaco-admin@ietf.org  Fri Dec 19 07:59:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07413
	for <megaco-archive@lists.ietf.org>; Fri, 19 Dec 2003 07:59:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXKDd-0007Qp-Ih; Fri, 19 Dec 2003 07:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXKCy-0007QL-8r
	for megaco@optimus.ietf.org; Fri, 19 Dec 2003 07:58:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07394
	for <megaco@ietf.org>; Fri, 19 Dec 2003 07:58:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXKCx-0001ym-00
	for megaco@ietf.org; Fri, 19 Dec 2003 07:58:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXKCw-0001yf-00
	for megaco@ietf.org; Fri, 19 Dec 2003 07:58:18 -0500
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXKCv-0001wp-00
	for megaco@ietf.org; Fri, 19 Dec 2003 07:58:18 -0500
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBJCvjR29453
	for <megaco@ietf.org>; Fri, 19 Dec 2003 07:57:45 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLSTM8MM; Fri, 19 Dec 2003 07:57:46 -0500
Received: from nortelnetworks.com (acart1g0.ca.nortel.com [47.129.129.175]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLPWNDJJ; Fri, 19 Dec 2003 07:57:45 -0500
Message-ID: <3FE2F5C8.7010807@nortelnetworks.com>
Date: Fri, 19 Dec 2003 07:57:44 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco@ietf.org
Content-Type: text/plain; charset=koi8-r; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by zcars0m9.nortelnetworks.com id hBJCvjR29453
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 and CHOOSE
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: quoted-printable

Denis Osadchy has spotted an inaccuracy in section 7.2.1 as it relates=20
to wildcarding of terminationIDs.

-------- Original Message --------
Subject: Re[2]:
Date: Fri, 19 Dec 2003 12:09:52 +0600
From: =E4=C5=CE=C9=D3 =EF=D3=C1=C4=DE=C9=CA <osadchy@itsib.ru>
Reply-To: =E4=C5=CE=C9=D3 =EF=D3=C1=C4=DE=C9=CA <osadchy@itsib.ru>
To: Taylor, Tom-PT [CAR:5N00:EXCH]<taylor@americasm01.nt.com>
References: <88625468765.20031218165025@itsib.ru>
<3FE1BED4.1080508@nortelnetworks.com>

Hello Tom,
I'm fully agree. It will be more clearly.

Thursday, December 18, 2003 tou wrote:

TT> You are right that there is a contradiction.  However, I would
suggest a
TT> different way to fix the paragraph.

TT> Let me suggest a situation you might want to think about, and one
that I
TT> think is quite realistic: that you want the MG to choose a particular
TT> circuit from a group, where the terminationID consists of the circuit
TT> group name concatenated with the individual circuit name or number.
TT> Then what the Add command would have is a partially specified
TT> terminationID with the choose wildcard replacing the circuit
name/number
TT> portion.

TT> If you agree with this possible application, the paragraph should
TT> instead be fixed by changing the sentence to read:

TT> "For an existing termination, the TerminationID SHALL be specific or
TT> partially specified."

TT> Again, if you agree, we should forward this exchange of notes to the
TT> Megaco list.

TT> =E4=C5=CE=C9=D3 =EF=D3=C1=C4=DE=C9=CA wrote:

>> Hello, I have question: by protocol
>>=20
>> " 7.2.1   Add ... The TerminationID specifies the termination to be
>>  added to the Context.  The Termination is either created, or taken
>>  from the null Context.  For an existing Termination, the=20
>> TerminationID would be specific. For a Termination that does not
>> yet exist, the TerminationID is specified as CHOOSE  in the
>> command. ... "
>>=20
>> If terminationID is CHOOSE then it's request to add ephemeral=20
>> termination? If i'm right then in this text we shall use SHALL (not
>>  would)? "For an existing Termination, the TerminationID would be=20
>> specific."
>>=20
>>=20
>> Denis
>>=20
>>=20
>>=20
>>=20



=F7=D3=C5=C7=CF =CE=C1=C9=CC=D5=DE=DB=C5=C7=CF,
=E4=C5=CE=C9=D3 =EF=D3=C1=C4=DE=C9=CA                          mailto:osa=
dchy@itsib.ru





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


From exim@www1.ietf.org  Fri Dec 19 07:59:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07431
	for <megaco-archive@odin.ietf.org>; Fri, 19 Dec 2003 07:59:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXKDg-0007Rj-3P
	for megaco-archive@odin.ietf.org; Fri, 19 Dec 2003 07:59:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJCx43b028616
	for megaco-archive@odin.ietf.org; Fri, 19 Dec 2003 07:59:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXKDf-0007RT-VP
	for megaco-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 07:59:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07407
	for <megaco-web-archive@ietf.org>; Fri, 19 Dec 2003 07:59:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXKDf-000207-00
	for megaco-web-archive@ietf.org; Fri, 19 Dec 2003 07:59:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXKDe-0001zz-00
	for megaco-web-archive@ietf.org; Fri, 19 Dec 2003 07:59:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXKDd-0001zw-00
	for megaco-web-archive@ietf.org; Fri, 19 Dec 2003 07:59:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXKDd-0007Qp-Ih; Fri, 19 Dec 2003 07:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXKCy-0007QL-8r
	for megaco@optimus.ietf.org; Fri, 19 Dec 2003 07:58:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07394
	for <megaco@ietf.org>; Fri, 19 Dec 2003 07:58:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXKCx-0001ym-00
	for megaco@ietf.org; Fri, 19 Dec 2003 07:58:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXKCw-0001yf-00
	for megaco@ietf.org; Fri, 19 Dec 2003 07:58:18 -0500
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXKCv-0001wp-00
	for megaco@ietf.org; Fri, 19 Dec 2003 07:58:18 -0500
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBJCvjR29453
	for <megaco@ietf.org>; Fri, 19 Dec 2003 07:57:45 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLSTM8MM; Fri, 19 Dec 2003 07:57:46 -0500
Received: from nortelnetworks.com (acart1g0.ca.nortel.com [47.129.129.175]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLPWNDJJ; Fri, 19 Dec 2003 07:57:45 -0500
Message-ID: <3FE2F5C8.7010807@nortelnetworks.com>
Date: Fri, 19 Dec 2003 07:57:44 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco@ietf.org
Content-Type: text/plain; charset=koi8-r; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by zcars0m9.nortelnetworks.com id hBJCvjR29453
Content-Transfer-Encoding: quoted-printable
Subject: [Megaco] Add and CHOOSE
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: quoted-printable

Denis Osadchy has spotted an inaccuracy in section 7.2.1 as it relates=20
to wildcarding of terminationIDs.

-------- Original Message --------
Subject: Re[2]:
Date: Fri, 19 Dec 2003 12:09:52 +0600
From: =E4=C5=CE=C9=D3 =EF=D3=C1=C4=DE=C9=CA <osadchy@itsib.ru>
Reply-To: =E4=C5=CE=C9=D3 =EF=D3=C1=C4=DE=C9=CA <osadchy@itsib.ru>
To: Taylor, Tom-PT [CAR:5N00:EXCH]<taylor@americasm01.nt.com>
References: <88625468765.20031218165025@itsib.ru>
<3FE1BED4.1080508@nortelnetworks.com>

Hello Tom,
I'm fully agree. It will be more clearly.

Thursday, December 18, 2003 tou wrote:

TT> You are right that there is a contradiction.  However, I would
suggest a
TT> different way to fix the paragraph.

TT> Let me suggest a situation you might want to think about, and one
that I
TT> think is quite realistic: that you want the MG to choose a particular
TT> circuit from a group, where the terminationID consists of the circuit
TT> group name concatenated with the individual circuit name or number.
TT> Then what the Add command would have is a partially specified
TT> terminationID with the choose wildcard replacing the circuit
name/number
TT> portion.

TT> If you agree with this possible application, the paragraph should
TT> instead be fixed by changing the sentence to read:

TT> "For an existing termination, the TerminationID SHALL be specific or
TT> partially specified."

TT> Again, if you agree, we should forward this exchange of notes to the
TT> Megaco list.

TT> =E4=C5=CE=C9=D3 =EF=D3=C1=C4=DE=C9=CA wrote:

>> Hello, I have question: by protocol
>>=20
>> " 7.2.1   Add ... The TerminationID specifies the termination to be
>>  added to the Context.  The Termination is either created, or taken
>>  from the null Context.  For an existing Termination, the=20
>> TerminationID would be specific. For a Termination that does not
>> yet exist, the TerminationID is specified as CHOOSE  in the
>> command. ... "
>>=20
>> If terminationID is CHOOSE then it's request to add ephemeral=20
>> termination? If i'm right then in this text we shall use SHALL (not
>>  would)? "For an existing Termination, the TerminationID would be=20
>> specific."
>>=20
>>=20
>> Denis
>>=20
>>=20
>>=20
>>=20



=F7=D3=C5=C7=CF =CE=C1=C9=CC=D5=DE=DB=C5=C7=CF,
=E4=C5=CE=C9=D3 =EF=D3=C1=C4=DE=C9=CA                          mailto:osa=
dchy@itsib.ru





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



From megaco-admin@ietf.org  Fri Dec 19 12:32:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16972
	for <megaco-archive@lists.ietf.org>; Fri, 19 Dec 2003 12:32:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXOTp-0003B8-Q1; Fri, 19 Dec 2003 12:32:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXOT4-0003A3-Uy
	for megaco@optimus.ietf.org; Fri, 19 Dec 2003 12:31:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16926
	for <megaco@ietf.org>; Fri, 19 Dec 2003 12:31:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXOT3-0001rO-00
	for megaco@ietf.org; Fri, 19 Dec 2003 12:31:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXOT1-0001rC-00
	for megaco@ietf.org; Fri, 19 Dec 2003 12:31:13 -0500
Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXOT1-0001qm-00
	for megaco@ietf.org; Fri, 19 Dec 2003 12:31:11 -0500
Received: from [172.16.1.210] (helo=CCPU00204)
	by smtp.ccpu.com with smtp (Exim 4.24 #1 (Debian))
	id 1AXOSv-0000z3-QJ; Fri, 19 Dec 2003 09:31:05 -0800
From: "Rashim Anand" <ranand@ccpu.com>
To: "Shridhara B" <bsh@tataelxsi.co.in>, <megaco@ietf.org>
Subject: RE: [Megaco] Query on Codec List Event in TFO Package
Date: Fri, 19 Dec 2003 09:30:35 -0800
Message-ID: <LLEMKHPJAECAPBFPABPNMEILCDAA.ranand@ccpu.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0174_01C3C612.C16923F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
In-Reply-To: <02de01c3c5fa$ade02670$d528010a@telxsi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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=HTML_50_60,HTML_FONTCOLOR_BLUE,
	HTML_MESSAGE,LINES_OF_YELLING autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0174_01C3C612.C16923F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hello Shridhara,

This is indeed a mistake. Event Id is defined by the ABNF construct ItemID
which is further defined as NAME. The rule for NAME is given in the RFC as -

NAME                 = ALPHA *63(ALPHA / DIGIT / "_" )

Consequently, there can NOT be a space in Event Id.

Could the authors of this package please clarify?

Regards,
Rashim Anand


  -----Original Message-----
  From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Shridhara B
  Sent: Thursday, December 18, 2003 10:38 PM
  To: megaco@ietf.org
  Subject: [Megaco] Query on Codec List Event in TFO Package


  All,

  The TFO package defined in 3GPP TS 29.232 V5.6.0 has Codec List Event. The
EventId is given as follows: -
  EventID: distant codec_list (0x0012).

  But the event name should not contain the space characters like above.
Hence it should be either, EventID: distantcodec_list (0x0012) or EventID:
distant_codec_list (0x0012).

  Could you please confirm which one of the above is correct?

  Thanks
  Shridhara.B

------=_NextPart_000_0174_01C3C612.C16923F0
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.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hello=20
Shridhara,</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =
size=3D2>This=20
is indeed a mistake. Event Id is defined by the ABNF construct ItemID =
which is=20
further defined as NAME. The rule for NAME is given in the RFC as=20
-</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2>NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
=3D ALPHA *63(ALPHA / DIGIT / "_" )</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Consequently, there can NOT be a space in Event =
Id.</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =
size=3D2>Could=20
the authors of this package please clarify?</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =
size=3D2>Rashim=20
Anand</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
megaco-admin@ietf.org=20
  [mailto:megaco-admin@ietf.org]<B>On Behalf Of </B>Shridhara =
B<BR><B>Sent:</B>=20
  Thursday, December 18, 2003 10:38 PM<BR><B>To:</B>=20
  megaco@ietf.org<BR><B>Subject:</B> [Megaco] Query on Codec List Event =
in TFO=20
  Package<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D269332506-19122003>All,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D269332506-19122003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D269332506-19122003>The TFO=20
  package defined in 3GPP TS 29.232 V5.6.0 has Codec List Event. The =
EventId is=20
  given as follows: -</SPAN></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT face=3DArial color=3D#800080><SPAN=20
  class=3D269332506-19122003>EventID: distant codec_list=20
  (0x0012).</SPAN></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT face=3DArial><SPAN=20
  class=3D269332506-19122003></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D269332506-19122003>But the=20
  event name should not contain the space characters like above. Hence =
it should=20
  be either, </SPAN></FONT></FONT><FONT size=3D2><FONT =
face=3DArial><SPAN=20
  class=3D269332506-19122003><FONT color=3D#800080>EventID: =
distantcodec_list=20
  (0x0012)</FONT> or <FONT color=3D#800080>EventID: distant_codec_list=20
  (0x0012)</FONT>.</SPAN></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT face=3DArial><SPAN=20
  class=3D269332506-19122003></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D269332506-19122003>Could you=20
  please confirm which one of the above is =
correct?</SPAN></FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D269332506-19122003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Shridhara.B</FONT></DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0174_01C3C612.C16923F0--


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


From exim@www1.ietf.org  Fri Dec 19 12:32:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17015
	for <megaco-archive@odin.ietf.org>; Fri, 19 Dec 2003 12:32:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXOTt-0003Dk-Nx
	for megaco-archive@odin.ietf.org; Fri, 19 Dec 2003 12:32:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJHW5KT012374
	for megaco-archive@odin.ietf.org; Fri, 19 Dec 2003 12:32:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXOTt-0003DV-KL
	for megaco-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 12:32:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16961
	for <megaco-web-archive@ietf.org>; Fri, 19 Dec 2003 12:32:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXOTr-0001u4-00
	for megaco-web-archive@ietf.org; Fri, 19 Dec 2003 12:32:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXOTp-0001tj-00
	for megaco-web-archive@ietf.org; Fri, 19 Dec 2003 12:32:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXOTp-0001tg-00
	for megaco-web-archive@ietf.org; Fri, 19 Dec 2003 12:32:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXOTp-0003B8-Q1; Fri, 19 Dec 2003 12:32:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXOT4-0003A3-Uy
	for megaco@optimus.ietf.org; Fri, 19 Dec 2003 12:31:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16926
	for <megaco@ietf.org>; Fri, 19 Dec 2003 12:31:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXOT3-0001rO-00
	for megaco@ietf.org; Fri, 19 Dec 2003 12:31:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXOT1-0001rC-00
	for megaco@ietf.org; Fri, 19 Dec 2003 12:31:13 -0500
Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXOT1-0001qm-00
	for megaco@ietf.org; Fri, 19 Dec 2003 12:31:11 -0500
Received: from [172.16.1.210] (helo=CCPU00204)
	by smtp.ccpu.com with smtp (Exim 4.24 #1 (Debian))
	id 1AXOSv-0000z3-QJ; Fri, 19 Dec 2003 09:31:05 -0800
From: "Rashim Anand" <ranand@ccpu.com>
To: "Shridhara B" <bsh@tataelxsi.co.in>, <megaco@ietf.org>
Subject: RE: [Megaco] Query on Codec List Event in TFO Package
Date: Fri, 19 Dec 2003 09:30:35 -0800
Message-ID: <LLEMKHPJAECAPBFPABPNMEILCDAA.ranand@ccpu.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0174_01C3C612.C16923F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
In-Reply-To: <02de01c3c5fa$ade02670$d528010a@telxsi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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=HTML_50_60,HTML_FONTCOLOR_BLUE,
	HTML_MESSAGE,LINES_OF_YELLING autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_0174_01C3C612.C16923F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hello Shridhara,

This is indeed a mistake. Event Id is defined by the ABNF construct ItemID
which is further defined as NAME. The rule for NAME is given in the RFC as -

NAME                 = ALPHA *63(ALPHA / DIGIT / "_" )

Consequently, there can NOT be a space in Event Id.

Could the authors of this package please clarify?

Regards,
Rashim Anand


  -----Original Message-----
  From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Shridhara B
  Sent: Thursday, December 18, 2003 10:38 PM
  To: megaco@ietf.org
  Subject: [Megaco] Query on Codec List Event in TFO Package


  All,

  The TFO package defined in 3GPP TS 29.232 V5.6.0 has Codec List Event. The
EventId is given as follows: -
  EventID: distant codec_list (0x0012).

  But the event name should not contain the space characters like above.
Hence it should be either, EventID: distantcodec_list (0x0012) or EventID:
distant_codec_list (0x0012).

  Could you please confirm which one of the above is correct?

  Thanks
  Shridhara.B

------=_NextPart_000_0174_01C3C612.C16923F0
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.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hello=20
Shridhara,</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =
size=3D2>This=20
is indeed a mistake. Event Id is defined by the ABNF construct ItemID =
which is=20
further defined as NAME. The rule for NAME is given in the RFC as=20
-</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2>NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
=3D ALPHA *63(ALPHA / DIGIT / "_" )</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Consequently, there can NOT be a space in Event =
Id.</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =
size=3D2>Could=20
the authors of this package please clarify?</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =
size=3D2>Rashim=20
Anand</FONT></SPAN></DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D955102217-19122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
megaco-admin@ietf.org=20
  [mailto:megaco-admin@ietf.org]<B>On Behalf Of </B>Shridhara =
B<BR><B>Sent:</B>=20
  Thursday, December 18, 2003 10:38 PM<BR><B>To:</B>=20
  megaco@ietf.org<BR><B>Subject:</B> [Megaco] Query on Codec List Event =
in TFO=20
  Package<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D269332506-19122003>All,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D269332506-19122003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D269332506-19122003>The TFO=20
  package defined in 3GPP TS 29.232 V5.6.0 has Codec List Event. The =
EventId is=20
  given as follows: -</SPAN></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT face=3DArial color=3D#800080><SPAN=20
  class=3D269332506-19122003>EventID: distant codec_list=20
  (0x0012).</SPAN></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT face=3DArial><SPAN=20
  class=3D269332506-19122003></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D269332506-19122003>But the=20
  event name should not contain the space characters like above. Hence =
it should=20
  be either, </SPAN></FONT></FONT><FONT size=3D2><FONT =
face=3DArial><SPAN=20
  class=3D269332506-19122003><FONT color=3D#800080>EventID: =
distantcodec_list=20
  (0x0012)</FONT> or <FONT color=3D#800080>EventID: distant_codec_list=20
  (0x0012)</FONT>.</SPAN></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT face=3DArial><SPAN=20
  class=3D269332506-19122003></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D269332506-19122003>Could you=20
  please confirm which one of the above is =
correct?</SPAN></FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D269332506-19122003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Shridhara.B</FONT></DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0174_01C3C612.C16923F0--


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



From megaco-admin@ietf.org  Sat Dec 20 04:42:00 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03465
	for <megaco-archive@lists.ietf.org>; Sat, 20 Dec 2003 04:42:00 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXdbd-00065Z-Ad; Sat, 20 Dec 2003 04:41:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXday-00064g-HW
	for megaco@optimus.ietf.org; Sat, 20 Dec 2003 04:40:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03389
	for <megaco@ietf.org>; Sat, 20 Dec 2003 04:40:21 -0500 (EST)
From: gsachin@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXdav-0002xO-00
	for megaco@ietf.org; Sat, 20 Dec 2003 04:40:21 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXdau-0002xC-00
	for megaco@ietf.org; Sat, 20 Dec 2003 04:40:21 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXdat-0002q6-00
	for megaco@ietf.org; Sat, 20 Dec 2003 04:40:19 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id hBK9d1iB003004
	for <megaco@ietf.org>; Sat, 20 Dec 2003 15:09:03 +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 hBK9e5013038
	for <megaco@ietf.org>; Sat, 20 Dec 2003 15:10:05 +0530 (IST)
To: megaco@ietf.org
Date: Sat, 20 Dec 2003 15:03:14 +0530
Message-ID: <OF816488CC.03CE68F9-ON65256E02.00343318@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 12/20/2003
 15:00:49
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=3.4 required=5.0 tests=EXCUSE_16,NO_REAL_NAME,
	ROUND_THE_WORLD_LOCAL autolearn=no version=2.60
Subject: [Megaco] Query Related to Automatic Metering
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>





Hi List,


this is a query regarding Periodic report event 'pr' defined in AMET
package .the package procedure says that

"the detection of event pr shall not cause the termination of the
signal em or signal mbp, even if the KeppActive(KA) flag is not set for the
pr event"

what i feel is that the detection of the 'pr' event shall not cause the
termination of any of the signals.

pls tell me if this is a correct assumption?

if yes, then i think here the package procedures should have mandated
the use of KA flag with this event. Doing this will keep the protocol rules
intact.



Regards
Sachin Gupta

"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."


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


From exim@www1.ietf.org  Sat Dec 20 05:00:39 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04031
	for <megaco-archive@odin.ietf.org>; Sat, 20 Dec 2003 05:00:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXdu6-0006Te-Mi
	for megaco-archive@odin.ietf.org; Sat, 20 Dec 2003 05:00:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBKA0AlW024893
	for megaco-archive@odin.ietf.org; Sat, 20 Dec 2003 05:00:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXdu3-0006TI-Er
	for megaco-web-archive@optimus.ietf.org; Sat, 20 Dec 2003 05:00:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04025
	for <megaco-web-archive@ietf.org>; Sat, 20 Dec 2003 05:00:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXdu0-0003lA-00
	for megaco-web-archive@ietf.org; Sat, 20 Dec 2003 05:00:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXdtz-0003l3-00
	for megaco-web-archive@ietf.org; Sat, 20 Dec 2003 05:00:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXdtz-0003l0-00
	for megaco-web-archive@ietf.org; Sat, 20 Dec 2003 05:00:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXdty-0006SC-E1; Sat, 20 Dec 2003 05:00:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXdtc-0006Re-Gw
	for megaco@optimus.ietf.org; Sat, 20 Dec 2003 04:59:40 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04002
	for <megaco@ietf.org>; Sat, 20 Dec 2003 04:59:37 -0500 (EST)
From: gsachin@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXdtZ-0003kg-00
	for megaco@ietf.org; Sat, 20 Dec 2003 04:59:37 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXdtY-0003kZ-00
	for megaco@ietf.org; Sat, 20 Dec 2003 04:59:37 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXdtX-0003aR-00
	for megaco@ietf.org; Sat, 20 Dec 2003 04:59:36 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id hBK9uKiB003506
	for <megaco@ietf.org>; Sat, 20 Dec 2003 15:26:21 +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 hBK9vPJ14143
	for <megaco@ietf.org>; Sat, 20 Dec 2003 15:27:25 +0530 (IST)
To: megaco@ietf.org
Date: Sat, 20 Dec 2003 15:20:35 +0530
Message-ID: <OF9ED5E34B.B6E91BC6-ON65256E02.00357ADA@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 12/20/2003
 15:18:08
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: [Megaco] ICAS Package 'Call Duration' statistics
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=3.4 required=5.0 tests=EXCUSE_16,NO_REAL_NAME,
	ROUND_THE_WORLD_LOCAL autolearn=no version=2.60





hi List,

the 'Call Duration' statistics in the ICAS package is described as

***
6.4.1 Call Duration
StatisticID: cd (0x0001)
Description: Provides the cumulative duration the termination is in
active call context i.e. from the point of applying/receiving "Answered"
signal till the point of release ("Clear-forward" or "Clear-back")
initiation.
***

Can somebody pls specify what 'active call context' refers to?
Should this be related to the stream mode property also?


Also the NT package define 'duration' statistics. the description is as
follows

***
        Description: Provides duration of time the termination has been
        in the context.
***

How does both these statistics differ. A termination can support both these
statistics.


regards
Sachin Gupta

"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."


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



From exim@www1.ietf.org  Sat Dec 20 05:28:47 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03466
	for <megaco-archive@odin.ietf.org>; Sat, 20 Dec 2003 04:42:00 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXdbr-000671-Ef
	for megaco-archive@odin.ietf.org; Sat, 20 Dec 2003 04:41:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBK9fGuK023462
	for megaco-archive@odin.ietf.org; Sat, 20 Dec 2003 04:41:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXdbn-00066L-TJ
	for megaco-web-archive@optimus.ietf.org; Sat, 20 Dec 2003 04:41:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03441
	for <megaco-web-archive@ietf.org>; Sat, 20 Dec 2003 04:41:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXdbk-0002zo-00
	for megaco-web-archive@ietf.org; Sat, 20 Dec 2003 04:41:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXdbi-0002zX-00
	for megaco-web-archive@ietf.org; Sat, 20 Dec 2003 04:41:12 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXdbi-0002zT-00
	for megaco-web-archive@ietf.org; Sat, 20 Dec 2003 04:41:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXdbd-00065Z-Ad; Sat, 20 Dec 2003 04:41:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXday-00064g-HW
	for megaco@optimus.ietf.org; Sat, 20 Dec 2003 04:40:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03389
	for <megaco@ietf.org>; Sat, 20 Dec 2003 04:40:21 -0500 (EST)
From: gsachin@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXdav-0002xO-00
	for megaco@ietf.org; Sat, 20 Dec 2003 04:40:21 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXdau-0002xC-00
	for megaco@ietf.org; Sat, 20 Dec 2003 04:40:21 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXdat-0002q6-00
	for megaco@ietf.org; Sat, 20 Dec 2003 04:40:19 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id hBK9d1iB003004
	for <megaco@ietf.org>; Sat, 20 Dec 2003 15:09:03 +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 hBK9e5013038
	for <megaco@ietf.org>; Sat, 20 Dec 2003 15:10:05 +0530 (IST)
To: megaco@ietf.org
Date: Sat, 20 Dec 2003 15:03:14 +0530
Message-ID: <OF816488CC.03CE68F9-ON65256E02.00343318@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 12/20/2003
 15:00:49
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: [Megaco] Query Related to Automatic Metering
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=3.4 required=5.0 tests=EXCUSE_16,NO_REAL_NAME,
	ROUND_THE_WORLD_LOCAL autolearn=no version=2.60





Hi List,


this is a query regarding Periodic report event 'pr' defined in AMET
package .the package procedure says that

"the detection of event pr shall not cause the termination of the
signal em or signal mbp, even if the KeppActive(KA) flag is not set for the
pr event"

what i feel is that the detection of the 'pr' event shall not cause the
termination of any of the signals.

pls tell me if this is a correct assumption?

if yes, then i think here the package procedures should have mandated
the use of KA flag with this event. Doing this will keep the protocol rules
intact.



Regards
Sachin Gupta

"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."


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



From megaco-admin@ietf.org  Sat Dec 20 05:53:47 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04030
	for <megaco-archive@lists.ietf.org>; Sat, 20 Dec 2003 05:00:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXdty-0006SC-E1; Sat, 20 Dec 2003 05:00:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXdtc-0006Re-Gw
	for megaco@optimus.ietf.org; Sat, 20 Dec 2003 04:59:40 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04002
	for <megaco@ietf.org>; Sat, 20 Dec 2003 04:59:37 -0500 (EST)
From: gsachin@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXdtZ-0003kg-00
	for megaco@ietf.org; Sat, 20 Dec 2003 04:59:37 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXdtY-0003kZ-00
	for megaco@ietf.org; Sat, 20 Dec 2003 04:59:37 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXdtX-0003aR-00
	for megaco@ietf.org; Sat, 20 Dec 2003 04:59:36 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id hBK9uKiB003506
	for <megaco@ietf.org>; Sat, 20 Dec 2003 15:26:21 +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 hBK9vPJ14143
	for <megaco@ietf.org>; Sat, 20 Dec 2003 15:27:25 +0530 (IST)
To: megaco@ietf.org
Date: Sat, 20 Dec 2003 15:20:35 +0530
Message-ID: <OF9ED5E34B.B6E91BC6-ON65256E02.00357ADA@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 12/20/2003
 15:18:08
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=3.4 required=5.0 tests=EXCUSE_16,NO_REAL_NAME,
	ROUND_THE_WORLD_LOCAL autolearn=no version=2.60
Subject: [Megaco] ICAS Package 'Call Duration' statistics
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>





hi List,

the 'Call Duration' statistics in the ICAS package is described as

***
6.4.1 Call Duration
StatisticID: cd (0x0001)
Description: Provides the cumulative duration the termination is in
active call context i.e. from the point of applying/receiving "Answered"
signal till the point of release ("Clear-forward" or "Clear-back")
initiation.
***

Can somebody pls specify what 'active call context' refers to?
Should this be related to the stream mode property also?


Also the NT package define 'duration' statistics. the description is as
follows

***
        Description: Provides duration of time the termination has been
        in the context.
***

How does both these statistics differ. A termination can support both these
statistics.


regards
Sachin Gupta

"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."


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


From megaco-admin@ietf.org  Sun Dec 21 04:59:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19961
	for <megaco-archive@lists.ietf.org>; Sun, 21 Dec 2003 04:59:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AY0MZ-0000do-Aj; Sun, 21 Dec 2003 04:59:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AY0M9-0000dO-8c
	for megaco@optimus.ietf.org; Sun, 21 Dec 2003 04:58:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19902
	for <megaco@ietf.org>; Sun, 21 Dec 2003 04:58:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AY0M6-0002AN-00
	for megaco@ietf.org; Sun, 21 Dec 2003 04:58:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AY0M2-0002A3-00
	for megaco@ietf.org; Sun, 21 Dec 2003 04:58:33 -0500
Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1AY0M2-00029n-00
	for Megaco@ietf.org; Sun, 21 Dec 2003 04:58:30 -0500
Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1071946803; Sun Dec 21 12:02:48 2003
Received: by MAILSERVER with Internet Mail Service (5.5.2657.72)
	id <Y7JR67B1>; Sun, 21 Dec 2003 11:57:23 +0200
Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F38101654E@MAILSERVER>
From: Raphael Tryster <raphael@tdsoft.com>
To: "'Megaco@ietf.org'" <Megaco@ietf.org>
Subject: RE: [Megaco] ABNF TerminationId definition
Date: Sun, 21 Dec 2003 11:57:18 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C7A8.D185DCF0"
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=HTML_30_40,HTML_FONTCOLOR_BLUE,
	HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2 autolearn=no 
	version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

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_01C3C7A8.D185DCF0
Content-Type: text/plain;
	charset="iso-8859-1"

Trying again and adding some more questions; maybe someone will answer this
time.

TerminationID        = "ROOT" / pathNAME / "$" / "*" 
 
pathNAME        = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" ) ["@"
pathDomainName ] 

NAME = ALPHA *63(ALPHA / DIGIT / "_" ) 

1.	All the examples I have seen suggest that the unit of wildcarding is
delimited by slashes. "For example, if there were TerminationIDs of R13/3/1,
R13/3/2 and R13/3/3, the TerminationID R13/3/* would match all of them".
But the ABNF seems to allow "*" to appear just about anywhere.  From a
performance point of view, it is much more efficient to index termination
identifiers by easily recognizable logical units, e.g. term1/term2/term3,
than to allow wildcarding in arbitrary places, requiring searching for
matches.  Do actual implementations allow unrestricted freedom, or can one
make simplifying assumptions?

2.	Is it legitimate to use underscore "_" instead of slash "/" as a
logical delimiter?  Does anyone actually do this?  Is anything else a
legitimate delimiter?

3.	Would the above definition of pathNAME be any different if ALPHA was
substituted for NAME?  The existing definition seems to be ambiguous, as for
example, an identifier consisting entirely of alphabetic characters could be
parsed such that all characters are assigned to NAME, or the first assigned
to NAME and the rest in the repeating optional ALPHA, or anything in
between.

4.	"Terminations are referenced by a TerminationID, which is an
arbitrary schema chosen by the MG".  Does this mean that only an MGC has to
worry about what form the MGs it works with might choose for their
termination identifier, while an MG can impose whatever restrictions it
wants without concern that it will impede interoperability?  



Raphael Tryster

	-----Original Message-----
	From:	Raphael Tryster [SMTP:raphael@tdsoft.com]
	Sent:	Tuesday, 13 August 2002 16:02
	To:	'Megaco@ietf.org'
	Subject:	RE: [Megaco] ABNF TerminationId definition

	Here is something I found in the archive that nobody answered.  In
addition to Steven's questions, for which I would also be interested in the
answers, I am curious about the following:

	What is the purpose of the leading "*" in pathNAME?  Following it
with NAME seems to restrict wildcarding in strange ways.  For example:

	*abc@xyz.com <mailto:*abc@xyz.com>  is allowed. 
	abc/def@xyz.com <mailto:abc/def@xyz.xom>  is allowed. 
	abc/*@xyz.com <mailto:abc/*@xyz.com>  is allowed. 
	*/def@xyz.com <mailto:*/def@xyz.com>  is not allowed. 

	Can anyone explain the reasoning? 

	Raphael Tryster 

	-----Original Message----- 
	From:   Steven Weisz [SMTP:sweisz@mediatrix.com] 
	Sent:   Monday, 15 October, 2001 10:53 PM 
	To:     'Megaco@ietf.org' 
	Subject:        [Megaco] ABNF TerminationId definition 

	Hi List, 

	        I've taken a close look at the H.248 document and the latest
IG and 
	I noticed that the ABNF does not allow TerminationIds in the form 

	*@abc.com 

	OR 

	$@abc.com 

	If you look closely at the ABNF we have: 

	; Total length of pathNAME must not exceed 64 chars. 
	pathNAME             = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" /
"$" ) 
	                       ["@" pathDomainName ] 

	; ABNF allows two or more consecutive "." although it is meaningless

	; in a path domain name. 
	pathDomainName       = (ALPHA / DIGIT / "*" ) 
	                       *63(ALPHA / DIGIT / "-" / "*" / ".") 
	                       
	TerminationID        = "ROOT" / pathNAME / "$" / "*" 

	What I'm wondering, are *@abc.com and $@abc.com valid TerminationIds
and the 
	ABNF doesn't cover them or are they not allowed. 

	Thanks, 



	Steven 


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

------_=_NextPart_001_01C3C7A8.D185DCF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885=
9-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 5.5.2653.1=
2">
<TITLE>RE: [Megaco] ABNF TerminationId definition</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Trying again a</FONT><FONT SIZE=3D2 FACE=
=3D"Arial">nd adding some more questions</FONT><FONT SIZE=3D2 FACE=3D"Ari=
al">; maybe someone will answer this time.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">TerminationID&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; =3D &quot;ROOT&quot; / pathNAME / &quot;$&quot; / &quot;*=
&quot; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">pathNAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; =3D [&quot;*&quot;] NAME *(&quot;/&quot; / &quot;*&quot;/ ALP=
HA / DIGIT /&quot;_&quot; / &quot;$&quot; ) [&quot;@&quot; pathDomainName=
 ] </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">NAME =3D ALPHA *63(ALPHA / DIGIT / &quot=
;_&quot; ) </FONT>
</P>

<OL TYPE=3D1><LI><FONT SIZE=3D2 FACE=3D"Arial">All the examples I have se=
en suggest that the unit of wildcarding is delimited by slashes.</FONT><I=
> <FONT SIZE=3D2 FACE=3D"Arial">"</FONT></I><I><FONT SIZE=3D2 FACE=3D"Ari=
al">For example, if there were TerminationIDs of R13/3/1, R13/3/2 and R13=
/3/3, the TerminationID R13/3/* would match all of them</FONT></I><I><FON=
T SIZE=3D2 FACE=3D"Arial">"</FONT></I><I><FONT SIZE=3D2 FACE=3D"Arial">.<=
/FONT></I><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; But the ABNF seems to allo=
w "*" to appear just about anywhere.&nbsp; From a performance point of vi=
ew, it is much more efficient to index termination identifiers by easily =
recognizable logical units, e.g. term1/term2/term3, than to allow wildcar=
ding in arbitrary places, requiring searching for matches.&nbsp; Do actual implementations allow unrestricted freedom, or can one make si=
mplifying assumptions?</FONT></LI>
<BR>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Is it legitimate to use underscore "_" =
instead of slash "/" as a logical delimiter?&nbsp; Does anyone actually d=
o this?&nbsp; Is anything else a legitimate delimiter?</FONT></LI>
<BR>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Would the above definition of pathNAME =
be any different if ALPHA was substituted for NAME?&nbsp; The existing de=
finition seems to be ambiguous, as for example, an identifier consisting =
entirely of alphabetic characters could be parsed such that all character=
s are assigned to NAME, or the first assigned to NAME and the rest in the=
 repeating optional ALPHA, or anything in between.</FONT></LI>
<BR>
<LI><I><FONT SIZE=3D2 FACE=3D"Arial">"</FONT></I><I><FONT SIZE=3D2 FACE=3D=
"Arial">Terminations are referenced by a TerminationID, which is an arbit=
rary schema chosen by the MG</FONT></I><I><FONT SIZE=3D2 FACE=3D"Arial">"=
</FONT></I><I><FONT SIZE=3D2 FACE=3D"Arial">.</FONT></I><FONT SIZE=3D2 FA=
CE=3D"Arial">&nbsp; Does this mean that only an MGC has to worry about wh=
at form the MGs it works with might choose for their termination identifi=
er, while an MG can impose whatever restrictions it wants without concern=
 that it will impede interoperability?</FONT><I><FONT SIZE=3D2 FACE=3D"Ar=
ial">&nbsp; </FONT></I></LI>
<BR>
<BR>
<BR>
</OL>
<P><FONT SIZE=3D2 FACE=3D"Tahoma">Raphael Tryster</FONT>
</P>
<UL>
<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original Mess=
age-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; Raphael Tryster [S=
MTP:raphael@tdsoft.com]</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT S=
IZE=3D2 FACE=3D"Arial">Tuesday, 13 August 2002 16:02</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></=
B> <FONT SIZE=3D2 FACE=3D"Arial">'Megaco@ietf.org'</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 FACE=3D"Arial">RE: [Megaco] ABNF=
 TerminationId definition</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Here is something I found in the archive=
 that nobody answered.=A0 In addition to Steven's questions, for which I =
would also be interested in the answers, I am curious about the following=
:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What is the purpose of the leading &quot=
;*&quot; in pathNAME?=A0 Following it with NAME seems to restrict wildcar=
ding in strange ways.=A0 For example:</FONT></P>

<P><A HREF=3D"mailto:*abc@xyz.com"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FA=
CE=3D"Arial">*abc@xyz.com</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial"> is=
 allowed.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><A HREF=3D"mailto:abc/def@xyz.xom"><U><FONT COLOR=3D"#0000FF" SIZE=
=3D2 FACE=3D"Arial">abc/def@xyz.com</FONT></U></A><FONT SIZE=3D2 FACE=3D"=
Arial"> is allowed.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><A HREF=3D"mailto:abc/*@xyz.com"><U><FONT COLOR=3D"#0000FF" SIZE=3D=
2 FACE=3D"Arial">abc/*@xyz.com</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial=
"> is allowed.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><A HREF=3D"mailto:*/def@xyz.com"><U><FONT COLOR=3D"#0000FF" SIZE=3D=
2 FACE=3D"Arial">*/def@xyz.com</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial=
"> is not allowed.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Can anyone explain the reasoning?</FONT>=
<FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Tahoma">Raphael Tryster</FONT><FONT FACE=3D"Ari=
al"> </FONT>
</P>

<P><A NAME=3D"BM__MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original M=
essage-----</FONT></A><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">From:=A0=A0 Steven Weisz [SMTP:sw=
eisz@mediatrix.com]</FONT></B><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:=A0=A0</FONT></B><FONT FACE=3D=
"Arial"></FONT> <FONT SIZE=3D2 FACE=3D"Arial">Monday, 15 October, 2001 10=
:53 PM</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">To:=A0=A0=A0=A0</FONT></B><FONT F=
ACE=3D"Arial"></FONT> <FONT SIZE=3D2 FACE=3D"Arial">'Megaco@ietf.org'</FO=
NT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">Subject:=A0=A0=A0=A0=A0=A0=A0</FO=
NT></B><FONT FACE=3D"Arial"></FONT> <FONT SIZE=3D2 FACE=3D"Arial">[Megaco=
] ABNF TerminationId definition</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Hi List,</FONT><FONT FACE=3D"Arial=
"> </FONT>
</P>

<P><FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0</FONT> <FONT SIZE=3D2 FACE=3D=
"Courier New">I've taken a close look at the H.248 document and the lates=
t IG and</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">I noticed that the ABNF does n=
ot allow TerminationIds in the form</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">*@abc.com</FONT>=20
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">OR</FONT><FONT FACE=3D"Arial"> </F=
ONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">$@abc.com</FONT><FONT FACE=3D"Aria=
l"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">If you look closely at the ABNF we=
 have:</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">; Total length of pathNAME must no=
t exceed 64 chars.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">pathNAME=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 =3D [&quot;*&quot;] NAME *(&quot;/&quot; / &quot;*&quot;/ AL=
PHA / DIGIT /&quot;_&quot; / &quot;$&quot; )</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Courier New">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 [&quot;@&quot; pathDomainName ]</FONT><FONT F=
ACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">; ABNF allows two or more consecut=
ive &quot;.&quot; although it is meaningless</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Courier New">; in a path domain name.</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Courier New">pathDomainName=A0=A0=A0=A0=A0=A0 =3D =
(ALPHA / DIGIT / &quot;*&quot; )</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Courier New">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 *63(ALPHA / DIGIT / &quot;-&quot; / &quot;*&q=
uot; / &quot;.&quot;)</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Courier New">TerminationID=A0=A0=A0=A0=A0=A0=A0 =3D=
 &quot;ROOT&quot; / pathNAME / &quot;$&quot; / &quot;*&quot;</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">What I'm wondering, are *@abc.com =
and $@abc.com valid TerminationIds and the</FONT><FONT FACE=3D"Arial"><BR=
>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">ABNF doesn't cover them or are=
 they not allowed.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Thanks,</FONT><FONT FACE=3D"Arial"=
> </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Steven</FONT><FONT FACE=3D"Arial">=
 </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">__________________________________=
_____________</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">Megaco mailing list</FONT><FON=
T FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">Megaco@ietf.org</FONT><FONT FA=
CE=3D"Arial"><BR>
</FONT><A HREF=3D"http://www1.ietf.org/mailman/listinfo/megaco"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">http://www1.ietf.org/mail=
man/listinfo/megaco</FONT></U></A><FONT FACE=3D"Arial"> </FONT>
<BR>
</P>
</UL>
</BODY>
</HTML>

------_=_NextPart_001_01C3C7A8.D185DCF0--

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


From exim@www1.ietf.org  Sun Dec 21 04:59:40 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19977
	for <megaco-archive@odin.ietf.org>; Sun, 21 Dec 2003 04:59:40 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AY0Mj-0000en-3d
	for megaco-archive@odin.ietf.org; Sun, 21 Dec 2003 04:59:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBL9xDkG002525
	for megaco-archive@odin.ietf.org; Sun, 21 Dec 2003 04:59:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AY0Mh-0000ee-Fl
	for megaco-web-archive@optimus.ietf.org; Sun, 21 Dec 2003 04:59:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19954
	for <megaco-web-archive@ietf.org>; Sun, 21 Dec 2003 04:59:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AY0Me-0002Bj-00
	for megaco-web-archive@ietf.org; Sun, 21 Dec 2003 04:59:08 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AY0Mc-0002BZ-00
	for megaco-web-archive@ietf.org; Sun, 21 Dec 2003 04:59:07 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AY0Mc-0002BW-00
	for megaco-web-archive@ietf.org; Sun, 21 Dec 2003 04:59:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AY0MZ-0000do-Aj; Sun, 21 Dec 2003 04:59:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AY0M9-0000dO-8c
	for megaco@optimus.ietf.org; Sun, 21 Dec 2003 04:58:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19902
	for <megaco@ietf.org>; Sun, 21 Dec 2003 04:58:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AY0M6-0002AN-00
	for megaco@ietf.org; Sun, 21 Dec 2003 04:58:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AY0M2-0002A3-00
	for megaco@ietf.org; Sun, 21 Dec 2003 04:58:33 -0500
Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1AY0M2-00029n-00
	for Megaco@ietf.org; Sun, 21 Dec 2003 04:58:30 -0500
Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1071946803; Sun Dec 21 12:02:48 2003
Received: by MAILSERVER with Internet Mail Service (5.5.2657.72)
	id <Y7JR67B1>; Sun, 21 Dec 2003 11:57:23 +0200
Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F38101654E@MAILSERVER>
From: Raphael Tryster <raphael@tdsoft.com>
To: "'Megaco@ietf.org'" <Megaco@ietf.org>
Subject: RE: [Megaco] ABNF TerminationId definition
Date: Sun, 21 Dec 2003 11:57:18 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3C7A8.D185DCF0"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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=HTML_30_40,HTML_FONTCOLOR_BLUE,
	HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2 autolearn=no 
	version=2.60

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_01C3C7A8.D185DCF0
Content-Type: text/plain;
	charset="iso-8859-1"

Trying again and adding some more questions; maybe someone will answer this
time.

TerminationID        = "ROOT" / pathNAME / "$" / "*" 
 
pathNAME        = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" ) ["@"
pathDomainName ] 

NAME = ALPHA *63(ALPHA / DIGIT / "_" ) 

1.	All the examples I have seen suggest that the unit of wildcarding is
delimited by slashes. "For example, if there were TerminationIDs of R13/3/1,
R13/3/2 and R13/3/3, the TerminationID R13/3/* would match all of them".
But the ABNF seems to allow "*" to appear just about anywhere.  From a
performance point of view, it is much more efficient to index termination
identifiers by easily recognizable logical units, e.g. term1/term2/term3,
than to allow wildcarding in arbitrary places, requiring searching for
matches.  Do actual implementations allow unrestricted freedom, or can one
make simplifying assumptions?

2.	Is it legitimate to use underscore "_" instead of slash "/" as a
logical delimiter?  Does anyone actually do this?  Is anything else a
legitimate delimiter?

3.	Would the above definition of pathNAME be any different if ALPHA was
substituted for NAME?  The existing definition seems to be ambiguous, as for
example, an identifier consisting entirely of alphabetic characters could be
parsed such that all characters are assigned to NAME, or the first assigned
to NAME and the rest in the repeating optional ALPHA, or anything in
between.

4.	"Terminations are referenced by a TerminationID, which is an
arbitrary schema chosen by the MG".  Does this mean that only an MGC has to
worry about what form the MGs it works with might choose for their
termination identifier, while an MG can impose whatever restrictions it
wants without concern that it will impede interoperability?  



Raphael Tryster

	-----Original Message-----
	From:	Raphael Tryster [SMTP:raphael@tdsoft.com]
	Sent:	Tuesday, 13 August 2002 16:02
	To:	'Megaco@ietf.org'
	Subject:	RE: [Megaco] ABNF TerminationId definition

	Here is something I found in the archive that nobody answered.  In
addition to Steven's questions, for which I would also be interested in the
answers, I am curious about the following:

	What is the purpose of the leading "*" in pathNAME?  Following it
with NAME seems to restrict wildcarding in strange ways.  For example:

	*abc@xyz.com <mailto:*abc@xyz.com>  is allowed. 
	abc/def@xyz.com <mailto:abc/def@xyz.xom>  is allowed. 
	abc/*@xyz.com <mailto:abc/*@xyz.com>  is allowed. 
	*/def@xyz.com <mailto:*/def@xyz.com>  is not allowed. 

	Can anyone explain the reasoning? 

	Raphael Tryster 

	-----Original Message----- 
	From:   Steven Weisz [SMTP:sweisz@mediatrix.com] 
	Sent:   Monday, 15 October, 2001 10:53 PM 
	To:     'Megaco@ietf.org' 
	Subject:        [Megaco] ABNF TerminationId definition 

	Hi List, 

	        I've taken a close look at the H.248 document and the latest
IG and 
	I noticed that the ABNF does not allow TerminationIds in the form 

	*@abc.com 

	OR 

	$@abc.com 

	If you look closely at the ABNF we have: 

	; Total length of pathNAME must not exceed 64 chars. 
	pathNAME             = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" /
"$" ) 
	                       ["@" pathDomainName ] 

	; ABNF allows two or more consecutive "." although it is meaningless

	; in a path domain name. 
	pathDomainName       = (ALPHA / DIGIT / "*" ) 
	                       *63(ALPHA / DIGIT / "-" / "*" / ".") 
	                       
	TerminationID        = "ROOT" / pathNAME / "$" / "*" 

	What I'm wondering, are *@abc.com and $@abc.com valid TerminationIds
and the 
	ABNF doesn't cover them or are they not allowed. 

	Thanks, 



	Steven 


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

------_=_NextPart_001_01C3C7A8.D185DCF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885=
9-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 5.5.2653.1=
2">
<TITLE>RE: [Megaco] ABNF TerminationId definition</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Trying again a</FONT><FONT SIZE=3D2 FACE=
=3D"Arial">nd adding some more questions</FONT><FONT SIZE=3D2 FACE=3D"Ari=
al">; maybe someone will answer this time.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">TerminationID&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; =3D &quot;ROOT&quot; / pathNAME / &quot;$&quot; / &quot;*=
&quot; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">pathNAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; =3D [&quot;*&quot;] NAME *(&quot;/&quot; / &quot;*&quot;/ ALP=
HA / DIGIT /&quot;_&quot; / &quot;$&quot; ) [&quot;@&quot; pathDomainName=
 ] </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">NAME =3D ALPHA *63(ALPHA / DIGIT / &quot=
;_&quot; ) </FONT>
</P>

<OL TYPE=3D1><LI><FONT SIZE=3D2 FACE=3D"Arial">All the examples I have se=
en suggest that the unit of wildcarding is delimited by slashes.</FONT><I=
> <FONT SIZE=3D2 FACE=3D"Arial">"</FONT></I><I><FONT SIZE=3D2 FACE=3D"Ari=
al">For example, if there were TerminationIDs of R13/3/1, R13/3/2 and R13=
/3/3, the TerminationID R13/3/* would match all of them</FONT></I><I><FON=
T SIZE=3D2 FACE=3D"Arial">"</FONT></I><I><FONT SIZE=3D2 FACE=3D"Arial">.<=
/FONT></I><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; But the ABNF seems to allo=
w "*" to appear just about anywhere.&nbsp; From a performance point of vi=
ew, it is much more efficient to index termination identifiers by easily =
recognizable logical units, e.g. term1/term2/term3, than to allow wildcar=
ding in arbitrary places, requiring searching for matches.&nbsp; Do actual implementations allow unrestricted freedom, or can one make si=
mplifying assumptions?</FONT></LI>
<BR>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Is it legitimate to use underscore "_" =
instead of slash "/" as a logical delimiter?&nbsp; Does anyone actually d=
o this?&nbsp; Is anything else a legitimate delimiter?</FONT></LI>
<BR>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Would the above definition of pathNAME =
be any different if ALPHA was substituted for NAME?&nbsp; The existing de=
finition seems to be ambiguous, as for example, an identifier consisting =
entirely of alphabetic characters could be parsed such that all character=
s are assigned to NAME, or the first assigned to NAME and the rest in the=
 repeating optional ALPHA, or anything in between.</FONT></LI>
<BR>
<LI><I><FONT SIZE=3D2 FACE=3D"Arial">"</FONT></I><I><FONT SIZE=3D2 FACE=3D=
"Arial">Terminations are referenced by a TerminationID, which is an arbit=
rary schema chosen by the MG</FONT></I><I><FONT SIZE=3D2 FACE=3D"Arial">"=
</FONT></I><I><FONT SIZE=3D2 FACE=3D"Arial">.</FONT></I><FONT SIZE=3D2 FA=
CE=3D"Arial">&nbsp; Does this mean that only an MGC has to worry about wh=
at form the MGs it works with might choose for their termination identifi=
er, while an MG can impose whatever restrictions it wants without concern=
 that it will impede interoperability?</FONT><I><FONT SIZE=3D2 FACE=3D"Ar=
ial">&nbsp; </FONT></I></LI>
<BR>
<BR>
<BR>
</OL>
<P><FONT SIZE=3D2 FACE=3D"Tahoma">Raphael Tryster</FONT>
</P>
<UL>
<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original Mess=
age-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; Raphael Tryster [S=
MTP:raphael@tdsoft.com]</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT S=
IZE=3D2 FACE=3D"Arial">Tuesday, 13 August 2002 16:02</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></=
B> <FONT SIZE=3D2 FACE=3D"Arial">'Megaco@ietf.org'</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 FACE=3D"Arial">RE: [Megaco] ABNF=
 TerminationId definition</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Here is something I found in the archive=
 that nobody answered.=A0 In addition to Steven's questions, for which I =
would also be interested in the answers, I am curious about the following=
:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What is the purpose of the leading &quot=
;*&quot; in pathNAME?=A0 Following it with NAME seems to restrict wildcar=
ding in strange ways.=A0 For example:</FONT></P>

<P><A HREF=3D"mailto:*abc@xyz.com"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FA=
CE=3D"Arial">*abc@xyz.com</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial"> is=
 allowed.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><A HREF=3D"mailto:abc/def@xyz.xom"><U><FONT COLOR=3D"#0000FF" SIZE=
=3D2 FACE=3D"Arial">abc/def@xyz.com</FONT></U></A><FONT SIZE=3D2 FACE=3D"=
Arial"> is allowed.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><A HREF=3D"mailto:abc/*@xyz.com"><U><FONT COLOR=3D"#0000FF" SIZE=3D=
2 FACE=3D"Arial">abc/*@xyz.com</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial=
"> is allowed.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><A HREF=3D"mailto:*/def@xyz.com"><U><FONT COLOR=3D"#0000FF" SIZE=3D=
2 FACE=3D"Arial">*/def@xyz.com</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial=
"> is not allowed.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Can anyone explain the reasoning?</FONT>=
<FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Tahoma">Raphael Tryster</FONT><FONT FACE=3D"Ari=
al"> </FONT>
</P>

<P><A NAME=3D"BM__MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original M=
essage-----</FONT></A><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">From:=A0=A0 Steven Weisz [SMTP:sw=
eisz@mediatrix.com]</FONT></B><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:=A0=A0</FONT></B><FONT FACE=3D=
"Arial"></FONT> <FONT SIZE=3D2 FACE=3D"Arial">Monday, 15 October, 2001 10=
:53 PM</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">To:=A0=A0=A0=A0</FONT></B><FONT F=
ACE=3D"Arial"></FONT> <FONT SIZE=3D2 FACE=3D"Arial">'Megaco@ietf.org'</FO=
NT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">Subject:=A0=A0=A0=A0=A0=A0=A0</FO=
NT></B><FONT FACE=3D"Arial"></FONT> <FONT SIZE=3D2 FACE=3D"Arial">[Megaco=
] ABNF TerminationId definition</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Hi List,</FONT><FONT FACE=3D"Arial=
"> </FONT>
</P>

<P><FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0</FONT> <FONT SIZE=3D2 FACE=3D=
"Courier New">I've taken a close look at the H.248 document and the lates=
t IG and</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">I noticed that the ABNF does n=
ot allow TerminationIds in the form</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">*@abc.com</FONT>=20
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">OR</FONT><FONT FACE=3D"Arial"> </F=
ONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">$@abc.com</FONT><FONT FACE=3D"Aria=
l"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">If you look closely at the ABNF we=
 have:</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">; Total length of pathNAME must no=
t exceed 64 chars.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">pathNAME=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 =3D [&quot;*&quot;] NAME *(&quot;/&quot; / &quot;*&quot;/ AL=
PHA / DIGIT /&quot;_&quot; / &quot;$&quot; )</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Courier New">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 [&quot;@&quot; pathDomainName ]</FONT><FONT F=
ACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">; ABNF allows two or more consecut=
ive &quot;.&quot; although it is meaningless</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Courier New">; in a path domain name.</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Courier New">pathDomainName=A0=A0=A0=A0=A0=A0 =3D =
(ALPHA / DIGIT / &quot;*&quot; )</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Courier New">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 *63(ALPHA / DIGIT / &quot;-&quot; / &quot;*&q=
uot; / &quot;.&quot;)</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Courier New">TerminationID=A0=A0=A0=A0=A0=A0=A0 =3D=
 &quot;ROOT&quot; / pathNAME / &quot;$&quot; / &quot;*&quot;</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">What I'm wondering, are *@abc.com =
and $@abc.com valid TerminationIds and the</FONT><FONT FACE=3D"Arial"><BR=
>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">ABNF doesn't cover them or are=
 they not allowed.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Thanks,</FONT><FONT FACE=3D"Arial"=
> </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Steven</FONT><FONT FACE=3D"Arial">=
 </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">__________________________________=
_____________</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">Megaco mailing list</FONT><FON=
T FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Courier New">Megaco@ietf.org</FONT><FONT FA=
CE=3D"Arial"><BR>
</FONT><A HREF=3D"http://www1.ietf.org/mailman/listinfo/megaco"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">http://www1.ietf.org/mail=
man/listinfo/megaco</FONT></U></A><FONT FACE=3D"Arial"> </FONT>
<BR>
</P>
</UL>
</BODY>
</HTML>

------_=_NextPart_001_01C3C7A8.D185DCF0--

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



From megaco-admin@ietf.org  Sun Dec 21 18:05:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09219
	for <megaco-archive@lists.ietf.org>; Sun, 21 Dec 2003 18:05:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYCdD-0006Wd-8p; Sun, 21 Dec 2003 18:05:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYCci-0006UM-GB
	for megaco@optimus.ietf.org; Sun, 21 Dec 2003 18:04:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09049
	for <megaco@ietf.org>; Sun, 21 Dec 2003 18:04:28 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYCcf-0004XN-00
	for megaco@ietf.org; Sun, 21 Dec 2003 18:04:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYCcc-0004Wv-00
	for megaco@ietf.org; Sun, 21 Dec 2003 18:04:28 -0500
Received: from [65.246.255.50] (helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYCcb-0004Wo-00
	for Megaco@ietf.org; Sun, 21 Dec 2003 18:04:26 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by manatick with esmtp (Exim 4.24)
	id 1AYCcc-0006zw-C6
	for Megaco@ietf.org; Sun, 21 Dec 2003 18:04:26 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBLN0Uv25261;
	Mon, 22 Dec 2003 10:00:30 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.153]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5L7VWA; Mon, 22 Dec 2003 10:02:02 +1100
Message-ID: <3FE6270B.4060205@ericsson.com>
Date: Mon, 22 Dec 2003 10:04:43 +1100
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: Raphael Tryster <raphael@tdsoft.com>
CC: "'Megaco@ietf.org'" <Megaco@ietf.org>
Subject: Re: [Megaco] ABNF TerminationId definition
References: <9A64A99CD3F2BD4582BE4FB63FC1F38101654E@MAILSERVER>
In-Reply-To: <9A64A99CD3F2BD4582BE4FB63FC1F38101654E@MAILSERVER>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hello Raphael,

When the termination ID structure was thought of, I at least thought that the 
structure was meant to be heirarchical, that is you'd only ever wildcard the RHS 
of the structure. A "?" or "*" was for a particular instance/s of the heirarchy.

See my comments below.

Regards, Christian

Raphael Tryster wrote:

> Trying again and adding some more questions; maybe someone will answer 
> this time.
> 
> TerminationID        = "ROOT" / pathNAME / "$" / "*"
>  
> pathNAME        = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" ) 
> ["@" pathDomainName ]
> 
> NAME = ALPHA *63(ALPHA / DIGIT / "_" )
> 
>    1. All the examples I have seen suggest that the unit of wildcarding
>       is delimited by slashes. "For example, if there were
>       TerminationIDs of R13/3/1, R13/3/2 and R13/3/3, the TerminationID
>       R13/3/* would match all of them".  But the ABNF seems to allow "*"
>       to appear just about anywhere.  From a performance point of view,
>       it is much more efficient to index termination identifiers by
>       easily recognizable logical units, e.g. term1/term2/term3, than to
>       allow wildcarding in arbitrary places, requiring searching for
>       matches.  Do actual implementations allow unrestricted freedom, or
>       can one make simplifying assumptions?

[CHG] See my intro comment.

> 
>    2. Is it legitimate to use underscore "_" instead of slash "/" as a
>       logical delimiter?  Does anyone actually do this?  Is anything
>       else a legitimate delimiter?

[CHG] Slash "/" is the only logical delimiter to use at least in the text version.

> 
>    3. Would the above definition of pathNAME be any different if ALPHA
>       was substituted for NAME?  The existing definition seems to be
>       ambiguous, as for example, an identifier consisting entirely of
>       alphabetic characters could be parsed such that all characters are
>       assigned to NAME, or the first assigned to NAME and the rest in
>       the repeating optional ALPHA, or anything in between.

[CHG] Yes??

> 
>    4. "Terminations are referenced by a TerminationID, which is an
>       arbitrary schema chosen by the MG".  Does this mean that only an
>       MGC has to worry about what form the MGs it works with might
>       choose for their termination identifier, while an MG can impose
>       whatever restrictions it wants without concern that it will impede
>       interoperability? 

[CHG] This statement was added because it was seen that as the MG owned the 
hardware which related to particular terminations that it would impose a certain 
structure. The MGC would have to use this structure.

> 
> 
> 
> Raphael Tryster
> 
>       -----Original Message-----
>       From:   Raphael Tryster [SMTP:raphael@tdsoft.com]
>       Sent:   Tuesday, 13 August 2002 16:02
>       To:     'Megaco@ietf.org'
>       Subject:        RE: [Megaco] ABNF TerminationId definition
> 
>       Here is something I found in the archive that nobody answered.  In
>       addition to Steven's questions, for which I would also be
>       interested in the answers, I am curious about the following:
> 
>       What is the purpose of the leading "*" in pathNAME?  Following it
>       with NAME seems to restrict wildcarding in strange ways.  For example:
> 
>       *abc@xyz.com <mailto:*abc@xyz.com> is allowed.
>       abc/def@xyz.com <mailto:abc/def@xyz.xom> is allowed.
>       abc/*@xyz.com <mailto:abc/*@xyz.com> is allowed.
>       */def@xyz.com <mailto:*/def@xyz.com> is not allowed.
> 
>       Can anyone explain the reasoning?
> 
>       Raphael Tryster
> 
>       -----Original Message-----
>       From:   Steven Weisz [SMTP:sweisz@mediatrix.com]
>       Sent:   Monday, 15 October, 2001 10:53 PM
>       To:     'Megaco@ietf.org'
>       Subject:        [Megaco] ABNF TerminationId definition
> 
>       Hi List,
> 
>               I've taken a close look at the H.248 document and the
>       latest IG and
>       I noticed that the ABNF does not allow TerminationIds in the form
> 
>       *@abc.com
> 
>       OR
> 
>       $@abc.com
> 
>       If you look closely at the ABNF we have:
> 
>       ; Total length of pathNAME must not exceed 64 chars.
>       pathNAME             = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_"
>       / "$" )
>                              ["@" pathDomainName ]
> 
>       ; ABNF allows two or more consecutive "." although it is meaningless
>       ; in a path domain name.
>       pathDomainName       = (ALPHA / DIGIT / "*" )
>                              *63(ALPHA / DIGIT / "-" / "*" / ".")
>                             
>       TerminationID        = "ROOT" / pathNAME / "$" / "*"
> 
>       What I'm wondering, are *@abc.com and $@abc.com valid
>       TerminationIds and the
>       ABNF doesn't cover them or are they not allowed.
> 
>       Thanks,
> 
> 
> 
>       Steven
> 
> 
>       _______________________________________________
>       Megaco mailing list
>       Megaco@ietf.org
>       http://www1.ietf.org/mailman/listinfo/megaco
> 


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


From exim@www1.ietf.org  Sun Dec 21 18:05:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09239
	for <megaco-archive@odin.ietf.org>; Sun, 21 Dec 2003 18:05:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYCdH-0006Xm-SE
	for megaco-archive@odin.ietf.org; Sun, 21 Dec 2003 18:05:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBLN57GY025151
	for megaco-archive@odin.ietf.org; Sun, 21 Dec 2003 18:05:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYCdH-0006Xa-Mz
	for megaco-web-archive@optimus.ietf.org; Sun, 21 Dec 2003 18:05:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09158
	for <megaco-web-archive@ietf.org>; Sun, 21 Dec 2003 18:05:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYCdE-0004cv-00
	for megaco-web-archive@ietf.org; Sun, 21 Dec 2003 18:05:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYCdD-0004cn-00
	for megaco-web-archive@ietf.org; Sun, 21 Dec 2003 18:05:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYCdD-0004ck-00
	for megaco-web-archive@ietf.org; Sun, 21 Dec 2003 18:05:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYCdD-0006Wd-8p; Sun, 21 Dec 2003 18:05:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYCci-0006UM-GB
	for megaco@optimus.ietf.org; Sun, 21 Dec 2003 18:04:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09049
	for <megaco@ietf.org>; Sun, 21 Dec 2003 18:04:28 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYCcf-0004XN-00
	for megaco@ietf.org; Sun, 21 Dec 2003 18:04:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYCcc-0004Wv-00
	for megaco@ietf.org; Sun, 21 Dec 2003 18:04:28 -0500
Received: from [65.246.255.50] (helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYCcb-0004Wo-00
	for Megaco@ietf.org; Sun, 21 Dec 2003 18:04:26 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by manatick with esmtp (Exim 4.24)
	id 1AYCcc-0006zw-C6
	for Megaco@ietf.org; Sun, 21 Dec 2003 18:04:26 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBLN0Uv25261;
	Mon, 22 Dec 2003 10:00:30 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.153]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5L7VWA; Mon, 22 Dec 2003 10:02:02 +1100
Message-ID: <3FE6270B.4060205@ericsson.com>
Date: Mon, 22 Dec 2003 10:04:43 +1100
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: Raphael Tryster <raphael@tdsoft.com>
CC: "'Megaco@ietf.org'" <Megaco@ietf.org>
Subject: Re: [Megaco] ABNF TerminationId definition
References: <9A64A99CD3F2BD4582BE4FB63FC1F38101654E@MAILSERVER>
In-Reply-To: <9A64A99CD3F2BD4582BE4FB63FC1F38101654E@MAILSERVER>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Raphael,

When the termination ID structure was thought of, I at least thought that the 
structure was meant to be heirarchical, that is you'd only ever wildcard the RHS 
of the structure. A "?" or "*" was for a particular instance/s of the heirarchy.

See my comments below.

Regards, Christian

Raphael Tryster wrote:

> Trying again and adding some more questions; maybe someone will answer 
> this time.
> 
> TerminationID        = "ROOT" / pathNAME / "$" / "*"
>  
> pathNAME        = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" ) 
> ["@" pathDomainName ]
> 
> NAME = ALPHA *63(ALPHA / DIGIT / "_" )
> 
>    1. All the examples I have seen suggest that the unit of wildcarding
>       is delimited by slashes. "For example, if there were
>       TerminationIDs of R13/3/1, R13/3/2 and R13/3/3, the TerminationID
>       R13/3/* would match all of them".  But the ABNF seems to allow "*"
>       to appear just about anywhere.  From a performance point of view,
>       it is much more efficient to index termination identifiers by
>       easily recognizable logical units, e.g. term1/term2/term3, than to
>       allow wildcarding in arbitrary places, requiring searching for
>       matches.  Do actual implementations allow unrestricted freedom, or
>       can one make simplifying assumptions?

[CHG] See my intro comment.

> 
>    2. Is it legitimate to use underscore "_" instead of slash "/" as a
>       logical delimiter?  Does anyone actually do this?  Is anything
>       else a legitimate delimiter?

[CHG] Slash "/" is the only logical delimiter to use at least in the text version.

> 
>    3. Would the above definition of pathNAME be any different if ALPHA
>       was substituted for NAME?  The existing definition seems to be
>       ambiguous, as for example, an identifier consisting entirely of
>       alphabetic characters could be parsed such that all characters are
>       assigned to NAME, or the first assigned to NAME and the rest in
>       the repeating optional ALPHA, or anything in between.

[CHG] Yes??

> 
>    4. "Terminations are referenced by a TerminationID, which is an
>       arbitrary schema chosen by the MG".  Does this mean that only an
>       MGC has to worry about what form the MGs it works with might
>       choose for their termination identifier, while an MG can impose
>       whatever restrictions it wants without concern that it will impede
>       interoperability? 

[CHG] This statement was added because it was seen that as the MG owned the 
hardware which related to particular terminations that it would impose a certain 
structure. The MGC would have to use this structure.

> 
> 
> 
> Raphael Tryster
> 
>       -----Original Message-----
>       From:   Raphael Tryster [SMTP:raphael@tdsoft.com]
>       Sent:   Tuesday, 13 August 2002 16:02
>       To:     'Megaco@ietf.org'
>       Subject:        RE: [Megaco] ABNF TerminationId definition
> 
>       Here is something I found in the archive that nobody answered.  In
>       addition to Steven's questions, for which I would also be
>       interested in the answers, I am curious about the following:
> 
>       What is the purpose of the leading "*" in pathNAME?  Following it
>       with NAME seems to restrict wildcarding in strange ways.  For example:
> 
>       *abc@xyz.com <mailto:*abc@xyz.com> is allowed.
>       abc/def@xyz.com <mailto:abc/def@xyz.xom> is allowed.
>       abc/*@xyz.com <mailto:abc/*@xyz.com> is allowed.
>       */def@xyz.com <mailto:*/def@xyz.com> is not allowed.
> 
>       Can anyone explain the reasoning?
> 
>       Raphael Tryster
> 
>       -----Original Message-----
>       From:   Steven Weisz [SMTP:sweisz@mediatrix.com]
>       Sent:   Monday, 15 October, 2001 10:53 PM
>       To:     'Megaco@ietf.org'
>       Subject:        [Megaco] ABNF TerminationId definition
> 
>       Hi List,
> 
>               I've taken a close look at the H.248 document and the
>       latest IG and
>       I noticed that the ABNF does not allow TerminationIds in the form
> 
>       *@abc.com
> 
>       OR
> 
>       $@abc.com
> 
>       If you look closely at the ABNF we have:
> 
>       ; Total length of pathNAME must not exceed 64 chars.
>       pathNAME             = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_"
>       / "$" )
>                              ["@" pathDomainName ]
> 
>       ; ABNF allows two or more consecutive "." although it is meaningless
>       ; in a path domain name.
>       pathDomainName       = (ALPHA / DIGIT / "*" )
>                              *63(ALPHA / DIGIT / "-" / "*" / ".")
>                             
>       TerminationID        = "ROOT" / pathNAME / "$" / "*"
> 
>       What I'm wondering, are *@abc.com and $@abc.com valid
>       TerminationIds and the
>       ABNF doesn't cover them or are they not allowed.
> 
>       Thanks,
> 
> 
> 
>       Steven
> 
> 
>       _______________________________________________
>       Megaco mailing list
>       Megaco@ietf.org
>       http://www1.ietf.org/mailman/listinfo/megaco
> 


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



From megaco-admin@ietf.org  Sun Dec 21 19:02:28 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11803
	for <megaco-archive@lists.ietf.org>; Sun, 21 Dec 2003 19:02:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYDWL-000866-Nr; Sun, 21 Dec 2003 19:02:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYDVW-00085V-LY
	for megaco@optimus.ietf.org; Sun, 21 Dec 2003 19:01:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11769
	for <megaco@ietf.org>; Sun, 21 Dec 2003 19:01:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYDVT-0005mN-00
	for megaco@ietf.org; Sun, 21 Dec 2003 19:01:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYDVS-0005mG-00
	for megaco@ietf.org; Sun, 21 Dec 2003 19:01:07 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYDVQ-0005lZ-00
	for megaco@ietf.org; Sun, 21 Dec 2003 19:01:06 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBLMjGv12755;
	Mon, 22 Dec 2003 09:45:18 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.153]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5L7VFR; Mon, 22 Dec 2003 09:46:49 +1100
Message-ID: <3FE62379.4020809@ericsson.com>
Date: Mon, 22 Dec 2003 09:49:29 +1100
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: Rashim Anand <ranand@ccpu.com>
CC: Shridhara B <bsh@tataelxsi.co.in>, megaco@ietf.org
Subject: Re: [Megaco] Query on Codec List Event in TFO Package
References: <LLEMKHPJAECAPBFPABPNMEILCDAA.ranand@ccpu.com>
In-Reply-To: <LLEMKHPJAECAPBFPABPNMEILCDAA.ranand@ccpu.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hello,

I think the original author is on holiday for a couple of weeks. I would assume 
that "distant_codec_list" is correct.

Regards, Christian

Rashim Anand wrote:

> Hello Shridhara,
>  
> This is indeed a mistake. Event Id is defined by the ABNF construct 
> ItemID which is further defined as NAME. The rule for NAME is given in 
> the RFC as -
>  
> NAME                 = ALPHA *63(ALPHA / DIGIT / "_" )
>  
> Consequently, there can NOT be a space in Event Id.
>  
> Could the authors of this package please clarify?
>  
> Regards,
> Rashim Anand
>  
>  
> 
>     -----Original Message-----
>     From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf
>     Of Shridhara B
>     Sent: Thursday, December 18, 2003 10:38 PM
>     To: megaco@ietf.org
>     Subject: [Megaco] Query on Codec List Event in TFO Package
> 
>     All,
>      
>     The TFO package defined in 3GPP TS 29.232 V5.6.0 has Codec List
>     Event. The EventId is given as follows: -
>     EventID: distant codec_list (0x0012).
>      
>     But the event name should not contain the space characters like
>     above. Hence it should be either, EventID: distantcodec_list
>     (0x0012) or EventID: distant_codec_list (0x0012).
>      
>     Could you please confirm which one of the above is correct?
>      
>     Thanks
>     Shridhara.B
>      


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


From exim@www1.ietf.org  Sun Dec 21 19:02:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11820
	for <megaco-archive@odin.ietf.org>; Sun, 21 Dec 2003 19:02:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYDWO-00087U-Ob
	for megaco-archive@odin.ietf.org; Sun, 21 Dec 2003 19:02:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBM0245x031209
	for megaco-archive@odin.ietf.org; Sun, 21 Dec 2003 19:02:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYDWO-00087I-Jq
	for megaco-web-archive@optimus.ietf.org; Sun, 21 Dec 2003 19:02:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11786
	for <megaco-web-archive@ietf.org>; Sun, 21 Dec 2003 19:01:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYDWL-0005o8-00
	for megaco-web-archive@ietf.org; Sun, 21 Dec 2003 19:02:01 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYDWK-0005o0-00
	for megaco-web-archive@ietf.org; Sun, 21 Dec 2003 19:02:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYDWK-0005nw-00
	for megaco-web-archive@ietf.org; Sun, 21 Dec 2003 19:02:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYDWL-000866-Nr; Sun, 21 Dec 2003 19:02:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYDVW-00085V-LY
	for megaco@optimus.ietf.org; Sun, 21 Dec 2003 19:01:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11769
	for <megaco@ietf.org>; Sun, 21 Dec 2003 19:01:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYDVT-0005mN-00
	for megaco@ietf.org; Sun, 21 Dec 2003 19:01:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYDVS-0005mG-00
	for megaco@ietf.org; Sun, 21 Dec 2003 19:01:07 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYDVQ-0005lZ-00
	for megaco@ietf.org; Sun, 21 Dec 2003 19:01:06 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBLMjGv12755;
	Mon, 22 Dec 2003 09:45:18 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.153]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5L7VFR; Mon, 22 Dec 2003 09:46:49 +1100
Message-ID: <3FE62379.4020809@ericsson.com>
Date: Mon, 22 Dec 2003 09:49:29 +1100
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: Rashim Anand <ranand@ccpu.com>
CC: Shridhara B <bsh@tataelxsi.co.in>, megaco@ietf.org
Subject: Re: [Megaco] Query on Codec List Event in TFO Package
References: <LLEMKHPJAECAPBFPABPNMEILCDAA.ranand@ccpu.com>
In-Reply-To: <LLEMKHPJAECAPBFPABPNMEILCDAA.ranand@ccpu.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello,

I think the original author is on holiday for a couple of weeks. I would assume 
that "distant_codec_list" is correct.

Regards, Christian

Rashim Anand wrote:

> Hello Shridhara,
>  
> This is indeed a mistake. Event Id is defined by the ABNF construct 
> ItemID which is further defined as NAME. The rule for NAME is given in 
> the RFC as -
>  
> NAME                 = ALPHA *63(ALPHA / DIGIT / "_" )
>  
> Consequently, there can NOT be a space in Event Id.
>  
> Could the authors of this package please clarify?
>  
> Regards,
> Rashim Anand
>  
>  
> 
>     -----Original Message-----
>     From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf
>     Of Shridhara B
>     Sent: Thursday, December 18, 2003 10:38 PM
>     To: megaco@ietf.org
>     Subject: [Megaco] Query on Codec List Event in TFO Package
> 
>     All,
>      
>     The TFO package defined in 3GPP TS 29.232 V5.6.0 has Codec List
>     Event. The EventId is given as follows: -
>     EventID: distant codec_list (0x0012).
>      
>     But the event name should not contain the space characters like
>     above. Hence it should be either, EventID: distantcodec_list
>     (0x0012) or EventID: distant_codec_list (0x0012).
>      
>     Could you please confirm which one of the above is correct?
>      
>     Thanks
>     Shridhara.B
>      


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



From megaco-admin@ietf.org  Sun Dec 21 20:51:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14708
	for <megaco-archive@lists.ietf.org>; Sun, 21 Dec 2003 20:51:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYFDp-0002dA-CE; Sun, 21 Dec 2003 20:51:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYFDc-0002c7-UD
	for megaco@optimus.ietf.org; Sun, 21 Dec 2003 20:50:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14579
	for <megaco@ietf.org>; Sun, 21 Dec 2003 20:50:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYFDa-0000gU-00
	for megaco@ietf.org; Sun, 21 Dec 2003 20:50:46 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYFDZ-0000gF-00
	for megaco@ietf.org; Sun, 21 Dec 2003 20:50:46 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYFDY-0000fu-00
	for megaco@ietf.org; Sun, 21 Dec 2003 20:50:44 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBM0hsv22119;
	Mon, 22 Dec 2003 11:43:55 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.153]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5L7XWA; Mon, 22 Dec 2003 11:45:28 +1100
Message-ID: <3FE63F48.9060606@ericsson.com>
Date: Mon, 22 Dec 2003 11:48:08 +1100
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: Troy Cauble <troy@bell-labs.com>
CC: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] wildcarding question
References: <3FDE2122.8010703@bell-labs.com>
In-Reply-To: <3FDE2122.8010703@bell-labs.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hello Troy,

Please see my comments below.

Regards, Christian

Troy Cauble wrote:

> 
> Regarding 6.6.1 in the IG.
> 
> The example would have been more informative if it matched two or more
> terminations.
> 
> Should
>     Context = 1 { Command=*{Descriptor/s}}
> 
> return
>     Context = 1 {Command=t1/1{Descriptor/s},
>                  Command=t2/1{Descriptor/s}}
> or
>     Context = 1 {Command=t1/1{Descriptor/s}}
>     Context = 1 {Command=t2/1{Descriptor/s}}
> 
> The text says "identical to repeating the command with each of the
> TerminationIDs", so I think the former is correct, but I'm not positive.
> 
[CHG] I believe the former is correct.
> 
> 
> Also, regarding 6.6.4, wildcard responses:
> A wildcard resonse request happens at the command level.
> What if wildcard response commands and non-wildcard response commands
> exist in the same request context?
> 
>     Context = * { Command=*{Descriptor/s},
>                   W-Command=*{Descriptor/s},
>                   Command=*{Descriptor/s}}

[CHG] Each command would be handled would be handled normally. The non-W 
commands would have all the instances returned and the W-command would only have 
one return with *.

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


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


From exim@www1.ietf.org  Sun Dec 21 20:51:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14726
	for <megaco-archive@odin.ietf.org>; Sun, 21 Dec 2003 20:51:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYFDv-0002em-AW
	for megaco-archive@odin.ietf.org; Sun, 21 Dec 2003 20:51:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBM1p7rc010209
	for megaco-archive@odin.ietf.org; Sun, 21 Dec 2003 20:51:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYFDv-0002ea-5F
	for megaco-web-archive@optimus.ietf.org; Sun, 21 Dec 2003 20:51:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14685
	for <megaco-web-archive@ietf.org>; Sun, 21 Dec 2003 20:51:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYFDs-0000jp-00
	for megaco-web-archive@ietf.org; Sun, 21 Dec 2003 20:51:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYFDp-0000jH-00
	for megaco-web-archive@ietf.org; Sun, 21 Dec 2003 20:51:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYFDp-0000jE-00
	for megaco-web-archive@ietf.org; Sun, 21 Dec 2003 20:51:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYFDp-0002dA-CE; Sun, 21 Dec 2003 20:51:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYFDc-0002c7-UD
	for megaco@optimus.ietf.org; Sun, 21 Dec 2003 20:50:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14579
	for <megaco@ietf.org>; Sun, 21 Dec 2003 20:50:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYFDa-0000gU-00
	for megaco@ietf.org; Sun, 21 Dec 2003 20:50:46 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYFDZ-0000gF-00
	for megaco@ietf.org; Sun, 21 Dec 2003 20:50:46 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYFDY-0000fu-00
	for megaco@ietf.org; Sun, 21 Dec 2003 20:50:44 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBM0hsv22119;
	Mon, 22 Dec 2003 11:43:55 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.153]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5L7XWA; Mon, 22 Dec 2003 11:45:28 +1100
Message-ID: <3FE63F48.9060606@ericsson.com>
Date: Mon, 22 Dec 2003 11:48:08 +1100
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: Troy Cauble <troy@bell-labs.com>
CC: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] wildcarding question
References: <3FDE2122.8010703@bell-labs.com>
In-Reply-To: <3FDE2122.8010703@bell-labs.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Troy,

Please see my comments below.

Regards, Christian

Troy Cauble wrote:

> 
> Regarding 6.6.1 in the IG.
> 
> The example would have been more informative if it matched two or more
> terminations.
> 
> Should
>     Context = 1 { Command=*{Descriptor/s}}
> 
> return
>     Context = 1 {Command=t1/1{Descriptor/s},
>                  Command=t2/1{Descriptor/s}}
> or
>     Context = 1 {Command=t1/1{Descriptor/s}}
>     Context = 1 {Command=t2/1{Descriptor/s}}
> 
> The text says "identical to repeating the command with each of the
> TerminationIDs", so I think the former is correct, but I'm not positive.
> 
[CHG] I believe the former is correct.
> 
> 
> Also, regarding 6.6.4, wildcard responses:
> A wildcard resonse request happens at the command level.
> What if wildcard response commands and non-wildcard response commands
> exist in the same request context?
> 
>     Context = * { Command=*{Descriptor/s},
>                   W-Command=*{Descriptor/s},
>                   Command=*{Descriptor/s}}

[CHG] Each command would be handled would be handled normally. The non-W 
commands would have all the instances returned and the W-command would only have 
one return with *.

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


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



From megaco-admin@ietf.org  Mon Dec 22 09:36:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18307
	for <megaco-archive@lists.ietf.org>; Mon, 22 Dec 2003 09:36:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYRAA-00035P-JB; Mon, 22 Dec 2003 09:36:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYR9y-00034s-Br
	for megaco@optimus.ietf.org; Mon, 22 Dec 2003 09:35:50 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18248
	for <megaco@ietf.org>; Mon, 22 Dec 2003 09:35:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYR9w-00053z-00
	for megaco@ietf.org; Mon, 22 Dec 2003 09:35:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYR9v-00053s-00
	for megaco@ietf.org; Mon, 22 Dec 2003 09:35:48 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYR9v-00052q-00
	for megaco@ietf.org; Mon, 22 Dec 2003 09:35:47 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBMEZCe14799
	for <megaco@ietf.org>; Mon, 22 Dec 2003 08:35:13 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA16343; Mon, 22 Dec 2003 09:35:10 -0500 (EST)
Cc: MEGACO list <megaco@ietf.org>
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA16334; Mon, 22 Dec 2003 09:35:08 -0500 (EST)
Message-ID: <3FE7011A.7070007@bell-labs.com>
Date: Mon, 22 Dec 2003 09:35:06 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christian Groves <Christian.Groves@ericsson.com>
Original-CC: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] wildcarding question
References: <3FDE2122.8010703@bell-labs.com> <3FE63F48.9060606@ericsson.com>
In-Reply-To: <3FE63F48.9060606@ericsson.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Christian Groves wrote:

> Troy Cauble wrote:

>> Also, regarding 6.6.4, wildcard responses:
>> A wildcard resonse request happens at the command level.
>> What if wildcard response commands and non-wildcard response commands
>> exist in the same request context?
>>
>>     Context = * { Command=*{Descriptor/s},
>>                   W-Command=*{Descriptor/s},
>>                   Command=*{Descriptor/s}}
> 
> 
> [CHG] Each command would be handled would be handled normally. The non-W 
> commands would have all the instances returned and the W-command would 
> only have one return with *.
> 


Yeah, but the first and third commands should return specified contexts,
while the second should return Context=*.  So do we end up with....

Context = 1 { Command1=x1/1 { },
	      Command1=x2/1 { }},
Context = 2 { Command1=x3/1 { }},
Context = * { Command2=* { }),
Context = 1 { Command3=x1/1 { },
               Command3=x2/1 { }},
Context = 2 { Command3=x3/1 { }}

-troy




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


From exim@www1.ietf.org  Mon Dec 22 09:36:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18329
	for <megaco-archive@odin.ietf.org>; Mon, 22 Dec 2003 09:36:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYRAF-00036r-Bp
	for megaco-archive@odin.ietf.org; Mon, 22 Dec 2003 09:36:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMEa7Og011947
	for megaco-archive@odin.ietf.org; Mon, 22 Dec 2003 09:36:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYRAD-000364-Ra
	for megaco-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 09:36:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18265
	for <megaco-web-archive@ietf.org>; Mon, 22 Dec 2003 09:36:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYRAB-00054d-00
	for megaco-web-archive@ietf.org; Mon, 22 Dec 2003 09:36:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYRAA-00054V-00
	for megaco-web-archive@ietf.org; Mon, 22 Dec 2003 09:36:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYRAA-00054S-00
	for megaco-web-archive@ietf.org; Mon, 22 Dec 2003 09:36:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYRAA-00035P-JB; Mon, 22 Dec 2003 09:36:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYR9y-00034s-Br
	for megaco@optimus.ietf.org; Mon, 22 Dec 2003 09:35:50 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18248
	for <megaco@ietf.org>; Mon, 22 Dec 2003 09:35:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYR9w-00053z-00
	for megaco@ietf.org; Mon, 22 Dec 2003 09:35:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYR9v-00053s-00
	for megaco@ietf.org; Mon, 22 Dec 2003 09:35:48 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYR9v-00052q-00
	for megaco@ietf.org; Mon, 22 Dec 2003 09:35:47 -0500
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBMEZCe14799
	for <megaco@ietf.org>; Mon, 22 Dec 2003 08:35:13 -0600 (CST)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA16343; Mon, 22 Dec 2003 09:35:10 -0500 (EST)
Cc: MEGACO list <megaco@ietf.org>
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id JAA16334; Mon, 22 Dec 2003 09:35:08 -0500 (EST)
Message-ID: <3FE7011A.7070007@bell-labs.com>
Date: Mon, 22 Dec 2003 09:35:06 -0500
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christian Groves <Christian.Groves@ericsson.com>
Original-CC: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] wildcarding question
References: <3FDE2122.8010703@bell-labs.com> <3FE63F48.9060606@ericsson.com>
In-Reply-To: <3FE63F48.9060606@ericsson.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: 7bit

Christian Groves wrote:

> Troy Cauble wrote:

>> Also, regarding 6.6.4, wildcard responses:
>> A wildcard resonse request happens at the command level.
>> What if wildcard response commands and non-wildcard response commands
>> exist in the same request context?
>>
>>     Context = * { Command=*{Descriptor/s},
>>                   W-Command=*{Descriptor/s},
>>                   Command=*{Descriptor/s}}
> 
> 
> [CHG] Each command would be handled would be handled normally. The non-W 
> commands would have all the instances returned and the W-command would 
> only have one return with *.
> 


Yeah, but the first and third commands should return specified contexts,
while the second should return Context=*.  So do we end up with....

Context = 1 { Command1=x1/1 { },
	      Command1=x2/1 { }},
Context = 2 { Command1=x3/1 { }},
Context = * { Command2=* { }),
Context = 1 { Command3=x1/1 { },
               Command3=x2/1 { }},
Context = 2 { Command3=x3/1 { }}

-troy




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



From megaco-admin@ietf.org  Mon Dec 22 11:53:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24944
	for <megaco-archive@lists.ietf.org>; Mon, 22 Dec 2003 11:53:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYTIk-0008Sz-3g; Mon, 22 Dec 2003 11:53:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYTId-0008Sj-KR
	for megaco@optimus.ietf.org; Mon, 22 Dec 2003 11:53:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24888
	for <megaco@ietf.org>; Mon, 22 Dec 2003 11:52:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYTIX-0001x1-00
	for megaco@ietf.org; Mon, 22 Dec 2003 11:52:49 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYTI7-0001wY-00
	for megaco@ietf.org; Mon, 22 Dec 2003 11:52:24 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYTI6-0001v8-00
	for Megaco@ietf.org; Mon, 22 Dec 2003 11:52:22 -0500
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBMGpYO11882;
	Mon, 22 Dec 2003 11:51:34 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZL7N8R3Y; Mon, 22 Dec 2003 11:51:35 -0500
Received: from nortelnetworks.com (acart1de.ca.nortel.com [47.129.129.90]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLPWN1CD; Mon, 22 Dec 2003 11:51:35 -0500
Message-ID: <3FE72115.2010401@nortelnetworks.com>
Date: Mon, 22 Dec 2003 11:51:33 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christian Groves <Christian.Groves@ericsson.com>
CC: Raphael Tryster <raphael@tdsoft.com>,
        "'Megaco@ietf.org'" <Megaco@ietf.org>
Subject: Re: [Megaco] ABNF TerminationId definition
References: <9A64A99CD3F2BD4582BE4FB63FC1F38101654E@MAILSERVER> <3FE6270B.4060205@ericsson.com>
In-Reply-To: <3FE6270B.4060205@ericsson.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

The points Raphael raises are now related to implementations, and I am 
not really in a position to comment in that respect.  However, in the 
original development of the protocol, the question came up as to where 
in the string the wildcard could appear and I suggested at the time that 
it could appear anywhere.  I have since regretted that rather 
theoretical stance as an unnecessary generalization of the protocol. 
Christian's view is probably the one that meets practical needs, but it 
is, as I said at the beginning, now a matter of what people have 
implemented.

The matter of terminationID structures was never agreed for 
Megaco/H.248.  I was always doctrinaire on the side of saying that the 
terminationIDs were a matter solely between the MG and MGC.  This came 
from my legacy switching background, which involves a lot of 
configuration of network elements.  It also reflected experience with 
the differing naming conventions reflecting differing vendor 
architectures.  The SGCP-IPDC-MGCP tradition from the beginning has been 
to pre-define naming conventions, regardless of actual equipment 
architecture.

On the circuit side, there is also a distinction between physical 
circuit identities (something along the lines of a 
frame-card-port-timeslot number hierarchy), and logical identities (in 
North American terminology, trunk group name and trunk number within the 
group).  The logical identity is the basis for call routing in the MGC. 
  The most likely arrangement is that the MGC is configured with data 
indicating the relationship between physical terminationIDs and logical 
circuit identities, but other arrangements with more data in the MG are 
possible.

This distinction between call routing entities and physical sets of 
terminations limits the usefulness of wildcarding in the Add command. 
In normal practice, one can find that individual transmission facilities 
are divided between multiple trunk groups (because trunk groups have a 
number of attributes besides simply which offices they link), nad that 
individual trunk groups are spread over multiple transmission facilities 
(for reliability).  That means that for wildcarding, assuming a 
physically-based termination naming system in the MG, the MGC has to 
select the transmission facility and then specify a range of timeslots 
(as they translate into terminationID terms) as the eleigible entities.

So how does this reflect on Ralph's questions?  I believe the answers 
are a matter of agreed practice.  The protocol itself does not impose 
limits on what set of characters a wildcard represents, or what 
delimiters if any are used in a naming path.  If we could come to common 
agreements, it would probably be of benefit to MG vendors, less so to 
MGC vendors, because they have to be configured with the correspondence 
between terminationIDs and call routes in any event.

In particular, my answer to the Ralph's fourth question is to say that I 
see no impact on interoperability for the MG to choose an arbitrary 
naming scheme.

Christian Groves wrote:
> Hello Raphael,
> 
> When the termination ID structure was thought of, I at least thought 
> that the structure was meant to be heirarchical, that is you'd only ever 
> wildcard the RHS of the structure. A "?" or "*" was for a particular 
> instance/s of the heirarchy.
> 
> See my comments below.
> 
> Regards, Christian
> 
> Raphael Tryster wrote:
> 
>> Trying again and adding some more questions; maybe someone will answer 
>> this time.
>>
>> TerminationID        = "ROOT" / pathNAME / "$" / "*"
>>  
>> pathNAME        = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" ) 
>> ["@" pathDomainName ]
>>
>> NAME = ALPHA *63(ALPHA / DIGIT / "_" )
>>
>>    1. All the examples I have seen suggest that the unit of wildcarding
>>       is delimited by slashes. "For example, if there were
>>       TerminationIDs of R13/3/1, R13/3/2 and R13/3/3, the TerminationID
>>       R13/3/* would match all of them".  But the ABNF seems to allow "*"
>>       to appear just about anywhere.  From a performance point of view,
>>       it is much more efficient to index termination identifiers by
>>       easily recognizable logical units, e.g. term1/term2/term3, than to
>>       allow wildcarding in arbitrary places, requiring searching for
>>       matches.  Do actual implementations allow unrestricted freedom, or
>>       can one make simplifying assumptions?
> 
> 
> [CHG] See my intro comment.
> 
>>
>>    2. Is it legitimate to use underscore "_" instead of slash "/" as a
>>       logical delimiter?  Does anyone actually do this?  Is anything
>>       else a legitimate delimiter?
> 
> 
> [CHG] Slash "/" is the only logical delimiter to use at least in the 
> text version.
> 
>>
>>    3. Would the above definition of pathNAME be any different if ALPHA
>>       was substituted for NAME?  The existing definition seems to be
>>       ambiguous, as for example, an identifier consisting entirely of
>>       alphabetic characters could be parsed such that all characters are
>>       assigned to NAME, or the first assigned to NAME and the rest in
>>       the repeating optional ALPHA, or anything in between.
> 
> 
> [CHG] Yes??
> 
>>
>>    4. "Terminations are referenced by a TerminationID, which is an
>>       arbitrary schema chosen by the MG".  Does this mean that only an
>>       MGC has to worry about what form the MGs it works with might
>>       choose for their termination identifier, while an MG can impose
>>       whatever restrictions it wants without concern that it will impede
>>       interoperability? 
> 
> 
> [CHG] This statement was added because it was seen that as the MG owned 
> the hardware which related to particular terminations that it would 
> impose a certain structure. The MGC would have to use this structure.
> 
>>
>>
>>
>> Raphael Tryster
>>
>>       -----Original Message-----
>>       From:   Raphael Tryster [SMTP:raphael@tdsoft.com]
>>       Sent:   Tuesday, 13 August 2002 16:02
>>       To:     'Megaco@ietf.org'
>>       Subject:        RE: [Megaco] ABNF TerminationId definition
>>
>>       Here is something I found in the archive that nobody answered.  In
>>       addition to Steven's questions, for which I would also be
>>       interested in the answers, I am curious about the following:
>>
>>       What is the purpose of the leading "*" in pathNAME?  Following it
>>       with NAME seems to restrict wildcarding in strange ways.  For 
>> example:
>>
>>       *abc@xyz.com <mailto:*abc@xyz.com> is allowed.
>>       abc/def@xyz.com <mailto:abc/def@xyz.xom> is allowed.
>>       abc/*@xyz.com <mailto:abc/*@xyz.com> is allowed.
>>       */def@xyz.com <mailto:*/def@xyz.com> is not allowed.
>>
>>       Can anyone explain the reasoning?
>>
>>       Raphael Tryster
>>
>>       -----Original Message-----
>>       From:   Steven Weisz [SMTP:sweisz@mediatrix.com]
>>       Sent:   Monday, 15 October, 2001 10:53 PM
>>       To:     'Megaco@ietf.org'
>>       Subject:        [Megaco] ABNF TerminationId definition
>>
>>       Hi List,
>>
>>               I've taken a close look at the H.248 document and the
>>       latest IG and
>>       I noticed that the ABNF does not allow TerminationIds in the form
>>
>>       *@abc.com
>>
>>       OR
>>
>>       $@abc.com
>>
>>       If you look closely at the ABNF we have:
>>
>>       ; Total length of pathNAME must not exceed 64 chars.
>>       pathNAME             = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_"
>>       / "$" )
>>                              ["@" pathDomainName ]
>>
>>       ; ABNF allows two or more consecutive "." although it is 
>> meaningless
>>       ; in a path domain name.
>>       pathDomainName       = (ALPHA / DIGIT / "*" )
>>                              *63(ALPHA / DIGIT / "-" / "*" / ".")
>>                                   TerminationID        = "ROOT" / 
>> pathNAME / "$" / "*"
>>
>>       What I'm wondering, are *@abc.com and $@abc.com valid
>>       TerminationIds and the
>>       ABNF doesn't cover them or are they not allowed.
>>
>>       Thanks,
>>
>>
>>
>>       Steven
>>
>>
>>       _______________________________________________
>>       Megaco mailing list
>>       Megaco@ietf.org
>>       http://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 exim@www1.ietf.org  Mon Dec 22 11:53:45 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24993
	for <megaco-archive@odin.ietf.org>; Mon, 22 Dec 2003 11:53:45 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYTJ0-0008Ue-1L
	for megaco-archive@odin.ietf.org; Mon, 22 Dec 2003 11:53:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMGrIie032642
	for megaco-archive@odin.ietf.org; Mon, 22 Dec 2003 11:53:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYTIz-0008UP-U2
	for megaco-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 11:53:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24913
	for <megaco-web-archive@ietf.org>; Mon, 22 Dec 2003 11:53:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYTIy-0001zj-00
	for megaco-web-archive@ietf.org; Mon, 22 Dec 2003 11:53:16 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYTIt-0001zC-00
	for megaco-web-archive@ietf.org; Mon, 22 Dec 2003 11:53:13 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYTIs-0001yd-00
	for megaco-web-archive@ietf.org; Mon, 22 Dec 2003 11:53:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYTIk-0008Sz-3g; Mon, 22 Dec 2003 11:53:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYTId-0008Sj-KR
	for megaco@optimus.ietf.org; Mon, 22 Dec 2003 11:53:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24888
	for <megaco@ietf.org>; Mon, 22 Dec 2003 11:52:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYTIX-0001x1-00
	for megaco@ietf.org; Mon, 22 Dec 2003 11:52:49 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYTI7-0001wY-00
	for megaco@ietf.org; Mon, 22 Dec 2003 11:52:24 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYTI6-0001v8-00
	for Megaco@ietf.org; Mon, 22 Dec 2003 11:52:22 -0500
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBMGpYO11882;
	Mon, 22 Dec 2003 11:51:34 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZL7N8R3Y; Mon, 22 Dec 2003 11:51:35 -0500
Received: from nortelnetworks.com (acart1de.ca.nortel.com [47.129.129.90]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLPWN1CD; Mon, 22 Dec 2003 11:51:35 -0500
Message-ID: <3FE72115.2010401@nortelnetworks.com>
Date: Mon, 22 Dec 2003 11:51:33 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christian Groves <Christian.Groves@ericsson.com>
CC: Raphael Tryster <raphael@tdsoft.com>,
        "'Megaco@ietf.org'" <Megaco@ietf.org>
Subject: Re: [Megaco] ABNF TerminationId definition
References: <9A64A99CD3F2BD4582BE4FB63FC1F38101654E@MAILSERVER> <3FE6270B.4060205@ericsson.com>
In-Reply-To: <3FE6270B.4060205@ericsson.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: 7bit

The points Raphael raises are now related to implementations, and I am 
not really in a position to comment in that respect.  However, in the 
original development of the protocol, the question came up as to where 
in the string the wildcard could appear and I suggested at the time that 
it could appear anywhere.  I have since regretted that rather 
theoretical stance as an unnecessary generalization of the protocol. 
Christian's view is probably the one that meets practical needs, but it 
is, as I said at the beginning, now a matter of what people have 
implemented.

The matter of terminationID structures was never agreed for 
Megaco/H.248.  I was always doctrinaire on the side of saying that the 
terminationIDs were a matter solely between the MG and MGC.  This came 
from my legacy switching background, which involves a lot of 
configuration of network elements.  It also reflected experience with 
the differing naming conventions reflecting differing vendor 
architectures.  The SGCP-IPDC-MGCP tradition from the beginning has been 
to pre-define naming conventions, regardless of actual equipment 
architecture.

On the circuit side, there is also a distinction between physical 
circuit identities (something along the lines of a 
frame-card-port-timeslot number hierarchy), and logical identities (in 
North American terminology, trunk group name and trunk number within the 
group).  The logical identity is the basis for call routing in the MGC. 
  The most likely arrangement is that the MGC is configured with data 
indicating the relationship between physical terminationIDs and logical 
circuit identities, but other arrangements with more data in the MG are 
possible.

This distinction between call routing entities and physical sets of 
terminations limits the usefulness of wildcarding in the Add command. 
In normal practice, one can find that individual transmission facilities 
are divided between multiple trunk groups (because trunk groups have a 
number of attributes besides simply which offices they link), nad that 
individual trunk groups are spread over multiple transmission facilities 
(for reliability).  That means that for wildcarding, assuming a 
physically-based termination naming system in the MG, the MGC has to 
select the transmission facility and then specify a range of timeslots 
(as they translate into terminationID terms) as the eleigible entities.

So how does this reflect on Ralph's questions?  I believe the answers 
are a matter of agreed practice.  The protocol itself does not impose 
limits on what set of characters a wildcard represents, or what 
delimiters if any are used in a naming path.  If we could come to common 
agreements, it would probably be of benefit to MG vendors, less so to 
MGC vendors, because they have to be configured with the correspondence 
between terminationIDs and call routes in any event.

In particular, my answer to the Ralph's fourth question is to say that I 
see no impact on interoperability for the MG to choose an arbitrary 
naming scheme.

Christian Groves wrote:
> Hello Raphael,
> 
> When the termination ID structure was thought of, I at least thought 
> that the structure was meant to be heirarchical, that is you'd only ever 
> wildcard the RHS of the structure. A "?" or "*" was for a particular 
> instance/s of the heirarchy.
> 
> See my comments below.
> 
> Regards, Christian
> 
> Raphael Tryster wrote:
> 
>> Trying again and adding some more questions; maybe someone will answer 
>> this time.
>>
>> TerminationID        = "ROOT" / pathNAME / "$" / "*"
>>  
>> pathNAME        = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" ) 
>> ["@" pathDomainName ]
>>
>> NAME = ALPHA *63(ALPHA / DIGIT / "_" )
>>
>>    1. All the examples I have seen suggest that the unit of wildcarding
>>       is delimited by slashes. "For example, if there were
>>       TerminationIDs of R13/3/1, R13/3/2 and R13/3/3, the TerminationID
>>       R13/3/* would match all of them".  But the ABNF seems to allow "*"
>>       to appear just about anywhere.  From a performance point of view,
>>       it is much more efficient to index termination identifiers by
>>       easily recognizable logical units, e.g. term1/term2/term3, than to
>>       allow wildcarding in arbitrary places, requiring searching for
>>       matches.  Do actual implementations allow unrestricted freedom, or
>>       can one make simplifying assumptions?
> 
> 
> [CHG] See my intro comment.
> 
>>
>>    2. Is it legitimate to use underscore "_" instead of slash "/" as a
>>       logical delimiter?  Does anyone actually do this?  Is anything
>>       else a legitimate delimiter?
> 
> 
> [CHG] Slash "/" is the only logical delimiter to use at least in the 
> text version.
> 
>>
>>    3. Would the above definition of pathNAME be any different if ALPHA
>>       was substituted for NAME?  The existing definition seems to be
>>       ambiguous, as for example, an identifier consisting entirely of
>>       alphabetic characters could be parsed such that all characters are
>>       assigned to NAME, or the first assigned to NAME and the rest in
>>       the repeating optional ALPHA, or anything in between.
> 
> 
> [CHG] Yes??
> 
>>
>>    4. "Terminations are referenced by a TerminationID, which is an
>>       arbitrary schema chosen by the MG".  Does this mean that only an
>>       MGC has to worry about what form the MGs it works with might
>>       choose for their termination identifier, while an MG can impose
>>       whatever restrictions it wants without concern that it will impede
>>       interoperability? 
> 
> 
> [CHG] This statement was added because it was seen that as the MG owned 
> the hardware which related to particular terminations that it would 
> impose a certain structure. The MGC would have to use this structure.
> 
>>
>>
>>
>> Raphael Tryster
>>
>>       -----Original Message-----
>>       From:   Raphael Tryster [SMTP:raphael@tdsoft.com]
>>       Sent:   Tuesday, 13 August 2002 16:02
>>       To:     'Megaco@ietf.org'
>>       Subject:        RE: [Megaco] ABNF TerminationId definition
>>
>>       Here is something I found in the archive that nobody answered.  In
>>       addition to Steven's questions, for which I would also be
>>       interested in the answers, I am curious about the following:
>>
>>       What is the purpose of the leading "*" in pathNAME?  Following it
>>       with NAME seems to restrict wildcarding in strange ways.  For 
>> example:
>>
>>       *abc@xyz.com <mailto:*abc@xyz.com> is allowed.
>>       abc/def@xyz.com <mailto:abc/def@xyz.xom> is allowed.
>>       abc/*@xyz.com <mailto:abc/*@xyz.com> is allowed.
>>       */def@xyz.com <mailto:*/def@xyz.com> is not allowed.
>>
>>       Can anyone explain the reasoning?
>>
>>       Raphael Tryster
>>
>>       -----Original Message-----
>>       From:   Steven Weisz [SMTP:sweisz@mediatrix.com]
>>       Sent:   Monday, 15 October, 2001 10:53 PM
>>       To:     'Megaco@ietf.org'
>>       Subject:        [Megaco] ABNF TerminationId definition
>>
>>       Hi List,
>>
>>               I've taken a close look at the H.248 document and the
>>       latest IG and
>>       I noticed that the ABNF does not allow TerminationIds in the form
>>
>>       *@abc.com
>>
>>       OR
>>
>>       $@abc.com
>>
>>       If you look closely at the ABNF we have:
>>
>>       ; Total length of pathNAME must not exceed 64 chars.
>>       pathNAME             = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_"
>>       / "$" )
>>                              ["@" pathDomainName ]
>>
>>       ; ABNF allows two or more consecutive "." although it is 
>> meaningless
>>       ; in a path domain name.
>>       pathDomainName       = (ALPHA / DIGIT / "*" )
>>                              *63(ALPHA / DIGIT / "-" / "*" / ".")
>>                                   TerminationID        = "ROOT" / 
>> pathNAME / "$" / "*"
>>
>>       What I'm wondering, are *@abc.com and $@abc.com valid
>>       TerminationIds and the
>>       ABNF doesn't cover them or are they not allowed.
>>
>>       Thanks,
>>
>>
>>
>>       Steven
>>
>>
>>       _______________________________________________
>>       Megaco mailing list
>>       Megaco@ietf.org
>>       http://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-admin@ietf.org  Mon Dec 22 11:54:28 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25087
	for <megaco-archive@lists.ietf.org>; Mon, 22 Dec 2003 11:54:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYTJh-00006l-3Z; Mon, 22 Dec 2003 11:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYTJD-0008V2-6m
	for megaco@optimus.ietf.org; Mon, 22 Dec 2003 11:53:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24937
	for <megaco@ietf.org>; Mon, 22 Dec 2003 11:53:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYTJB-000237-00
	for megaco@ietf.org; Mon, 22 Dec 2003 11:53:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYTJ2-000217-00
	for megaco@ietf.org; Mon, 22 Dec 2003 11:53:29 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYTJ1-0001xg-00
	for megaco@ietf.org; Mon, 22 Dec 2003 11:53:19 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBMGqYO11978;
	Mon, 22 Dec 2003 11:52:34 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZMGMPVTB; Mon, 22 Dec 2003 11:52:34 -0500
Received: from nortelnetworks.com (acart1de.ca.nortel.com [47.129.129.90]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLPWN1CF; Mon, 22 Dec 2003 11:52:34 -0500
Message-ID: <3FE72151.8050301@nortelnetworks.com>
Date: Mon, 22 Dec 2003 11:52:33 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: gsachin@hss.hns.com
CC: megaco@ietf.org
Subject: Re: [Megaco] Query Related to Automatic Metering
References: <OF816488CC.03CE68F9-ON65256E02.00343318@hss.hns.com>
In-Reply-To: <OF816488CC.03CE68F9-ON65256E02.00343318@hss.hns.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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,EXCUSE_16 autolearn=no 
	version=2.60
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

I think you make a good point.  It's desirable to keep the protocol 
intact, rather than define exceptions within individual packages.

gsachin@hss.hns.com wrote:

> 
> 
> 
> Hi List,
> 
> 
> this is a query regarding Periodic report event 'pr' defined in AMET
> package .the package procedure says that
> 
> "the detection of event pr shall not cause the termination of the
> signal em or signal mbp, even if the KeppActive(KA) flag is not set for the
> pr event"
> 
> what i feel is that the detection of the 'pr' event shall not cause the
> termination of any of the signals.
> 
> pls tell me if this is a correct assumption?
> 
> if yes, then i think here the package procedures should have mandated
> the use of KA flag with this event. Doing this will keep the protocol rules
> intact.
> 
> 
> 
> Regards
> Sachin Gupta
> 
> "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
> (HSS) and is intended solely for the use of the individual to whom it is
> addressed. It may contain  privileged or confidential information and
> should not be circulated or used for any purpose other than for what it is
> intended. If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient, you are
> notified that you are strictly prohibited from using, copying, altering, or
> disclosing the contents of this message. HSS accepts no responsibility for
> loss or damage arising from the use of the information transmitted by this
> email including damage from virus."
> 
> 
> _______________________________________________
> 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 exim@www1.ietf.org  Mon Dec 22 11:54:37 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25118
	for <megaco-archive@odin.ietf.org>; Mon, 22 Dec 2003 11:54:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYTJq-0000A6-1a
	for megaco-archive@odin.ietf.org; Mon, 22 Dec 2003 11:54:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMGsAZj000616
	for megaco-archive@odin.ietf.org; Mon, 22 Dec 2003 11:54:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYTJp-00009j-Sk
	for megaco-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 11:54:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25054
	for <megaco-web-archive@ietf.org>; Mon, 22 Dec 2003 11:54:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYTJn-00029y-00
	for megaco-web-archive@ietf.org; Mon, 22 Dec 2003 11:54:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYTJh-00028p-00
	for megaco-web-archive@ietf.org; Mon, 22 Dec 2003 11:54:06 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYTJg-00028h-00
	for megaco-web-archive@ietf.org; Mon, 22 Dec 2003 11:54:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYTJh-00006l-3Z; Mon, 22 Dec 2003 11:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYTJD-0008V2-6m
	for megaco@optimus.ietf.org; Mon, 22 Dec 2003 11:53:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24937
	for <megaco@ietf.org>; Mon, 22 Dec 2003 11:53:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYTJB-000237-00
	for megaco@ietf.org; Mon, 22 Dec 2003 11:53:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYTJ2-000217-00
	for megaco@ietf.org; Mon, 22 Dec 2003 11:53:29 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYTJ1-0001xg-00
	for megaco@ietf.org; Mon, 22 Dec 2003 11:53:19 -0500
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBMGqYO11978;
	Mon, 22 Dec 2003 11:52:34 -0500 (EST)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZMGMPVTB; Mon, 22 Dec 2003 11:52:34 -0500
Received: from nortelnetworks.com (acart1de.ca.nortel.com [47.129.129.90]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XLPWN1CF; Mon, 22 Dec 2003 11:52:34 -0500
Message-ID: <3FE72151.8050301@nortelnetworks.com>
Date: Mon, 22 Dec 2003 11:52:33 -0500
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: gsachin@hss.hns.com
CC: megaco@ietf.org
Subject: Re: [Megaco] Query Related to Automatic Metering
References: <OF816488CC.03CE68F9-ON65256E02.00343318@hss.hns.com>
In-Reply-To: <OF816488CC.03CE68F9-ON65256E02.00343318@hss.hns.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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,EXCUSE_16 autolearn=no 
	version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I think you make a good point.  It's desirable to keep the protocol 
intact, rather than define exceptions within individual packages.

gsachin@hss.hns.com wrote:

> 
> 
> 
> Hi List,
> 
> 
> this is a query regarding Periodic report event 'pr' defined in AMET
> package .the package procedure says that
> 
> "the detection of event pr shall not cause the termination of the
> signal em or signal mbp, even if the KeppActive(KA) flag is not set for the
> pr event"
> 
> what i feel is that the detection of the 'pr' event shall not cause the
> termination of any of the signals.
> 
> pls tell me if this is a correct assumption?
> 
> if yes, then i think here the package procedures should have mandated
> the use of KA flag with this event. Doing this will keep the protocol rules
> intact.
> 
> 
> 
> Regards
> Sachin Gupta
> 
> "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
> (HSS) and is intended solely for the use of the individual to whom it is
> addressed. It may contain  privileged or confidential information and
> should not be circulated or used for any purpose other than for what it is
> intended. If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient, you are
> notified that you are strictly prohibited from using, copying, altering, or
> disclosing the contents of this message. HSS accepts no responsibility for
> loss or damage arising from the use of the information transmitted by this
> email including damage from virus."
> 
> 
> _______________________________________________
> 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-admin@ietf.org  Mon Dec 22 21:19:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21546
	for <megaco-archive@lists.ietf.org>; Mon, 22 Dec 2003 21:19:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYc8T-0002P6-4O; Mon, 22 Dec 2003 21:19:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYc8G-0002O1-Ln
	for megaco@optimus.ietf.org; Mon, 22 Dec 2003 21:18:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21514
	for <megaco@ietf.org>; Mon, 22 Dec 2003 21:18:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYc8D-0002wl-01
	for megaco@ietf.org; Mon, 22 Dec 2003 21:18:46 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYc6t-0002vL-00
	for megaco@ietf.org; Mon, 22 Dec 2003 21:17:23 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYc6s-0002ud-00
	for megaco@ietf.org; Mon, 22 Dec 2003 21:17:22 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBMNESv03971;
	Tue, 23 Dec 2003 10:14:28 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.223]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5L8J8P; Tue, 23 Dec 2003 10:16:00 +1100
Message-ID: <3FE77BCD.5080701@ericsson.com>
Date: Tue, 23 Dec 2003 10:18:37 +1100
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: Troy Cauble <troy@bell-labs.com>
CC: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] wildcarding question
References: <3FDE2122.8010703@bell-labs.com> <3FE63F48.9060606@ericsson.com> <3FE7011A.7070007@bell-labs.com>
In-Reply-To: <3FE7011A.7070007@bell-labs.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

So what is the problem is they return specific and wildcarded returns? Its a 
pretty unlikely scenario to put a Context=*{w-command=*{} in the middle of non-W 
commands.

Christian

Troy Cauble wrote:

> Christian Groves wrote:
> 
>> Troy Cauble wrote:
> 
> 
>>> Also, regarding 6.6.4, wildcard responses:
>>> A wildcard resonse request happens at the command level.
>>> What if wildcard response commands and non-wildcard response commands
>>> exist in the same request context?
>>>
>>>     Context = * { Command=*{Descriptor/s},
>>>                   W-Command=*{Descriptor/s},
>>>                   Command=*{Descriptor/s}}
>>
>>
>>
>> [CHG] Each command would be handled would be handled normally. The 
>> non-W commands would have all the instances returned and the W-command 
>> would only have one return with *.
>>
> 
> 
> Yeah, but the first and third commands should return specified contexts,
> while the second should return Context=*.  So do we end up with....
> 
> Context = 1 { Command1=x1/1 { },
>           Command1=x2/1 { }},
> Context = 2 { Command1=x3/1 { }},
> Context = * { Command2=* { }),
> Context = 1 { Command3=x1/1 { },
>               Command3=x2/1 { }},
> Context = 2 { Command3=x3/1 { }}
> 
> -troy
> 
> 
> 


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


From exim@www1.ietf.org  Mon Dec 22 21:23:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21638
	for <megaco-archive@odin.ietf.org>; Mon, 22 Dec 2003 21:23:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYcCB-0002YY-J8
	for megaco-archive@odin.ietf.org; Mon, 22 Dec 2003 21:22:51 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBN2Mp0Z009820
	for megaco-archive@odin.ietf.org; Mon, 22 Dec 2003 21:22:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYcCB-0002YJ-Fx
	for megaco-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 21:22:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21598
	for <megaco-web-archive@ietf.org>; Mon, 22 Dec 2003 21:22:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYcC8-00034m-01
	for megaco-web-archive@ietf.org; Mon, 22 Dec 2003 21:22:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYc8W-00030l-00
	for megaco-web-archive@ietf.org; Mon, 22 Dec 2003 21:19:05 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYc8W-00030i-00
	for megaco-web-archive@ietf.org; Mon, 22 Dec 2003 21:19:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYc8T-0002P6-4O; Mon, 22 Dec 2003 21:19:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYc8G-0002O1-Ln
	for megaco@optimus.ietf.org; Mon, 22 Dec 2003 21:18:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21514
	for <megaco@ietf.org>; Mon, 22 Dec 2003 21:18:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYc8D-0002wl-01
	for megaco@ietf.org; Mon, 22 Dec 2003 21:18:46 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYc6t-0002vL-00
	for megaco@ietf.org; Mon, 22 Dec 2003 21:17:23 -0500
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYc6s-0002ud-00
	for megaco@ietf.org; Mon, 22 Dec 2003 21:17:22 -0500
Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id hBMNESv03971;
	Tue, 23 Dec 2003 10:14:28 +1100 (EST)
Received: from ericsson.com (EFTUF01K2P3DA50 [146.11.245.223]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id YV5L8J8P; Tue, 23 Dec 2003 10:16:00 +1100
Message-ID: <3FE77BCD.5080701@ericsson.com>
Date: Tue, 23 Dec 2003 10:18:37 +1100
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: Troy Cauble <troy@bell-labs.com>
CC: MEGACO list <megaco@ietf.org>
Subject: Re: [Megaco] wildcarding question
References: <3FDE2122.8010703@bell-labs.com> <3FE63F48.9060606@ericsson.com> <3FE7011A.7070007@bell-labs.com>
In-Reply-To: <3FE7011A.7070007@bell-labs.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

So what is the problem is they return specific and wildcarded returns? Its a 
pretty unlikely scenario to put a Context=*{w-command=*{} in the middle of non-W 
commands.

Christian

Troy Cauble wrote:

> Christian Groves wrote:
> 
>> Troy Cauble wrote:
> 
> 
>>> Also, regarding 6.6.4, wildcard responses:
>>> A wildcard resonse request happens at the command level.
>>> What if wildcard response commands and non-wildcard response commands
>>> exist in the same request context?
>>>
>>>     Context = * { Command=*{Descriptor/s},
>>>                   W-Command=*{Descriptor/s},
>>>                   Command=*{Descriptor/s}}
>>
>>
>>
>> [CHG] Each command would be handled would be handled normally. The 
>> non-W commands would have all the instances returned and the W-command 
>> would only have one return with *.
>>
> 
> 
> Yeah, but the first and third commands should return specified contexts,
> while the second should return Context=*.  So do we end up with....
> 
> Context = 1 { Command1=x1/1 { },
>           Command1=x2/1 { }},
> Context = 2 { Command1=x3/1 { }},
> Context = * { Command2=* { }),
> Context = 1 { Command3=x1/1 { },
>               Command3=x2/1 { }},
> Context = 2 { Command3=x3/1 { }}
> 
> -troy
> 
> 
> 


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



From megaco-admin@ietf.org  Tue Dec 23 09:52:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21847
	for <megaco-archive@lists.ietf.org>; Tue, 23 Dec 2003 09:52:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYntA-0001uE-2l; Tue, 23 Dec 2003 09:52:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYnsU-0001t9-8X
	for megaco@optimus.ietf.org; Tue, 23 Dec 2003 09:51:43 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21798
	for <megaco@ietf.org>; Tue, 23 Dec 2003 09:51:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYnsI-0000QM-00
	for megaco@ietf.org; Tue, 23 Dec 2003 09:51:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYnrk-0000YS-00
	for megaco@ietf.org; Tue, 23 Dec 2003 09:50:33 -0500
Received: from motgate8.mot.com ([129.188.136.8])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYnrk-0000XI-00
	for megaco@ietf.org; Tue, 23 Dec 2003 09:50:32 -0500
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134])
	by motgate8.mot.com (Motorola/Motgate3) with ESMTP id hBNEnuE5023366;
	Tue, 23 Dec 2003 07:49:57 -0700 (MST)
Received: from smilevm.motorola.com ([10.14.25.162])
	by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hBNEnrTP017699;
	Tue, 23 Dec 2003 08:49:53 -0600
Message-Id: <5.2.1.1.0.20031223094134.05713db8@IL06EXM13.corp.mot.com>
X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Tue, 23 Dec 2003 09:47:15 -0500
To: megaco@ietf.org
From: Aleksandr Ryabin <kengr@motorola.com>
Subject: RE: [Megaco] CAS Metering Pulse support
Cc: Christian Groves <Christian.Groves@ericsson.com.au>, klaha@hss.hns.com,
        "Soncodi, Adrian" <adrian.soncodi@santera.com>,
        "Kevin Boyle" <kboyle@nortelnetworks.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0BDF4C71@zrtpd0jq.us.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=3.1 required=5.0 tests=USERPASS autolearn=no 
	version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Hi all,

Per this email thread I've put together the following document

http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Working/DC-xxx_H.248.26.metd.zip

Summary

This temporary document proposes an amendment to H.248.26
Enhanced Analog Line Packages to include new Metering Pulse
Detection Package and to extend Automatic Metering Package
to be used for digital lines.

This document will be presented to ITU-T in next meeting in Jan 2004
Please review and send comments.

Thanks
         Aleks

At 09:05 AM 10/6/2003, Kevin Boyle wrote:
>There is a 2833-bis draft out now that proposes some extensions to the set
>of detectable events under RFC2833.  If we want CAS metering included (and
>from reading all this, I think we do), then someone needs to contact the
>authors of the 2833-bis document and get the CAS metering stuff added.
>
>The 2833-bis draft can be found at
>http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-03.txt.
>
>Kevin
>
>-----Original Message-----
>From: Christian Groves [mailto:Christian.Groves@ericsson.com.au]
>Sent: Sunday, October 05, 2003 8:38 PM
>To: klaha@hss.hns.com
>Cc: Aleksandr Ryabin; Soncodi, Adrian; megaco@ietf.org; Boyle, Kevin
>[NCRTP:3Z40:EXCH]
>Subject: Re: [Megaco] CAS Metering Pulse support
>
>
>Hello,
>
>As Aleks said RTP is not in the scope of this working group. I believe the
>correct way to move this forward is to write a IETF draft of the carriage of
>
>metering pulses over RTP and submit it to the AVT WG for comment.
>
>Regards, Christian
>
>Kushanava Laha wrote:
>
> > Is it possible for this WG to convey this (metering
> > pulse via RTP) as a requirement to the relevant WG?
> >
> >
> > --- Aleksandr Ryabin <kengr@motorola.com> wrote:
> >
> >>Hi,
> >>
> >>How the pulse information is relayed between MGC is
> >>out of scope MEGACO.
> >>Whatever MGCs use for inter MGC communication will
> >>need to support this
> >>information.
> >>
> >>Regards,
> >>         Aleks
> >>
> >>At 02:44 PM 10/3/2003, Soncodi, Adrian wrote:
> >>
> >>>The pulse rate can change during the call. This is
> >>
> >>done by the switch
> >>
> >>>downstream, which is the TAX office, and which
> >>
> >>changes the rate based on
> >>
> >>>time-of-day and provisioned charge rates. This
> >>
> >>means that the receiving MG
> >>
> >>>would also neeed an event for pulse rate change. A
> >>
> >>little more overhead
> >>
> >>>will occur, but I guess it is acceptable. However,
> >>
> >>it becomes delicate
> >>
> >>>when the pulse rate decreases: by the time the
> >>
> >>receiving MG detects the
> >>
> >>>lower pulse rate, the generating MG has already
> >>
> >>generated a number of
> >>
> >>>extra pulses, based on the higher rate. With some
> >>
> >>effort though, one could
> >>
> >>>make this work.
> >>>
> >>>But I don't understand how the meter pulse rate can
> >>
> >>be relayed between 2
> >>
> >>>MGCs that talk SIP, for example in the following
> >>
> >>tandem-replacement solution:
> >>
> >>>  Local office - R2 - (MG1, MGC1) - SIP - (MGC2,
> >>
> >>MG2) - R2 - TAX office
> >>
> >>>I think an RFC2833-based solution causes less
> >>
> >>headache. But registering a
> >>
> >>>new RFC2833 event is outside the scope of the
> >>
> >>MEGACO working group anyway.
> >>
> >>>For registered events, the ability to negotiate the
> >>
> >>'telephone-event'
> >>
> >>>codec is already available via MEGACO/SDP.
> >>>
> >>>Adrian Soncodi
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: Aleksandr Ryabin [mailto:kengr@motorola.com]
> >>>Sent: Friday, October 03, 2003 12:56 PM
> >>>To: Soncodi, Adrian; megaco@ietf.org
> >>>Cc: Kevin Boyle; Christian Groves
> >>>Subject: RE: [Megaco] CAS Metering Pulse support
> >>>
> >>>
> >>>Proposed new metd package will have functionality
> >>
> >>described in 1).
> >>
> >>>However I have a slightly different proposal for
> >>
> >>relaying.
> >>
> >>>In order to relay pulses all needed to be known is
> >>
> >>a repetition interval,
> >>
> >>>changes to it, if any, and when to start, and stop
> >>
> >>metering pulses.
> >>
> >>>If "receiving" MGC (the one that controls MG which
> >>
> >>receives
> >>
> >>>metering pulses) gets notified with this
> >>
> >>information using new
> >>
> >>>metd package then it can relay this information to
> >>
> >>"generating"
> >>
> >>>MGC (the one that controls MG which generates
> >>
> >>metering pulses).
> >>
> >>>Then "generating" MGC can use amet to start/stop,
> >>
> >>or modify
> >>
> >>>generation of metering pulses.
> >>>
> >>>That is in reality, if repetition interval does not
> >>
> >>change during
> >>
> >>>the call, "receiving" MGC will get only two
> >>
> >>notifies per call:
> >>
> >>>first pulse detected,
> >>>repetition interval calculated (e.g. second pulse
> >>
> >>detected)
> >>
> >>>"Generating" MGC will need to send tree modifies:
> >>>pulse once (when first pulse detected event is
> >>
> >>relayed)
> >>
> >>>pulse forever (when repetition interval received)
> >>>stop pulse generation (when call terminates)
> >>>
> >>>Regards,
> >>>         Aleks
> >>>
> >>>At 01:12 PM 10/3/2003, Soncodi, Adrian wrote:
> >>>
> >>>>In some countries a tandem switch is required to
> >>
> >>propagate meter pulses
> >>
> >>>>(backwards) from the outgoing R2 trunk to the
> >>
> >>incoming R2 trunk. These
> >>
> >>>>pulses are used for billing. A potential problem
> >>
> >>is that the pulse rate
> >>
> >>>>may be very high, sometimes it can be a
> >>
> >>sub-second interval. Therefore, a
> >>
> >>>>tandem MGC which has a considerable number of R2
> >>
> >>trunks will have a big
> >>
> >>>>overhead for propagating meter pulses, which will
> >>
> >>affect its call
> >>
> >>>>processing rate.
> >>>>
> >>>>So I'm wondering if anything can be done about
> >>
> >>this. Here are two
> >>
> >>>>possibilities:
> >>>>
> >>>>1) Allow the MG to detect meter pulses but report
> >>
> >>them in chunks of N. By
> >>
> >>>>default, N=1 (report every pulse), but the MGC
> >>
> >>could also select, say,
> >>
> >>>>N=10, in which case the MG reports once every 10
> >>
> >>pulses. (A residual pulse
> >>
> >>>>count could be reported on Subtract). This method
> >>
> >>saves a lot of NTFY
> >>
> >>>>messages. However, on the other side, the MGC
> >>
> >>would be forced to propagate
> >>
> >>>>the pulses as bursts-of-N, and I am not sure a
> >>
> >>switch is allowed to
> >>
> >>>>transform constant-rate pulsing into bursts. (On
> >>
> >>the other hand why not?
> >>
> >>>>because it's only the total pulse count that is
> >>
> >>relevant for charging.
> >>
> >>>>Time-of-day periods with higher charging rates
> >>
> >>actually result in more
> >>
> >>>>meter pulses.)
> >>>>
> >>>>2) Define a mode which allows the meter pulses to
> >>
> >>be propagated directly
> >>
> >>>>between MGs, without MGC involvement, i.e. by a
> >>
> >>method similar to RFC2833.
> >>
> >>>>RFC2833 does not currently have an event defined
> >>
> >>for meter pulses, but it
> >>
> >>>>could be extended, since it defines a lot of
> >>
> >>signaling-related tones
> >>
> >>>>anyway. In addition to solving the NTFY messaging
> >>
> >>overhead, this method
> >>
> >>>>would have the side benefit that it would also
> >>
> >>work between two MGCs that
> >>
> >>>>use SIP or BICC between them. Currently, there is
> >>
> >>no way to transport
> >>
> >>>>meter pulse information in SIP or BICC, and this
> >>
> >>would have a terrible
> >>
> >>>>overhead anyway.
> >>>>Of course, the ability to detect meter pulses is
> >>
> >>still required, because
> >>
> >>>>there is always the possibility that the MGC must
> >>
> >>perform the
> >>
> >>>>meter-pulse-based charging itself (rather than
> >>
> >>propagate).
> >>
> >>>>Any other ideas or comments?
> >>>>
> >>>>Adrian Soncodi
> >>>>
> >>>>
> >>>>
> >>>>-----Original Message-----
> >>>>From: Christian Groves
> >>
> >>[mailto:Christian.Groves@ericsson.com.au]
> >>
> >>>>Sent: Thursday, October 02, 2003 10:38 PM
> >>>>To: Aleksandr Ryabin
> >>>>Cc: megaco@ietf.org; Kevin Boyle
> >>>>Subject: Re: [Megaco] CAS Metering Pulse support
> >>>>
> >>>>
> >>>>Hello Aleksandr,
> >>>>
> >>>>I'm happy enough to have the your proposed
> >>
> >>amendment if the editor agrees.
> >>
> >>>>Regards, Christian
> >>>>
> >>>>Aleksandr Ryabin wrote:
> >>>>
> >>>>>Hi Christian,
> >>>>>
> >>>>>No description of the event does say how to
> >>
> >>use it for detection
> >>
> >>>>>incoming metering pulse. More over it
> >>
> >>explicitly limits to generation:
> >>
> >>>>>"This event is used in conjunction with the
> >>
> >>"enable metering" and
> >>
> >>>>>"metering pulse burst" signals defined in this
> >>
> >>package..."
> >>
> >>>>>My point being that descriptions of amet
> >>
> >>events and statistics
> >>
> >>>>>are siting that event pr is generated and
> >>
> >>statistics are changed
> >>
> >>>>>only based on previously applied em, or mbp
> >>
> >>signal.
> >>
> >>>>>The wording needs to be amended to cover the
> >>
> >>cases
> >
> > === message truncated ===
> >
> >
> > =====
> > Kushanava Laha
> > Hughes Software Systems
> >
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Shopping - with improved product search
> > http://shopping.yahoo.com
> >


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


From exim@www1.ietf.org  Tue Dec 23 09:53:38 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21890
	for <megaco-archive@odin.ietf.org>; Tue, 23 Dec 2003 09:53:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYnuE-000219-2O
	for megaco-archive@odin.ietf.org; Tue, 23 Dec 2003 09:53:11 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNEr6U8007752
	for megaco-archive@odin.ietf.org; Tue, 23 Dec 2003 09:53:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYnuD-00020x-Uf
	for megaco-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 09:53:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21873
	for <megaco-web-archive@ietf.org>; Tue, 23 Dec 2003 09:53:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYnu6-0000ZP-00
	for megaco-web-archive@ietf.org; Tue, 23 Dec 2003 09:52:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYntX-0000cv-00
	for megaco-web-archive@ietf.org; Tue, 23 Dec 2003 09:52:24 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYntX-0000c1-00
	for megaco-web-archive@ietf.org; Tue, 23 Dec 2003 09:52:23 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYntA-0001uE-2l; Tue, 23 Dec 2003 09:52:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYnsU-0001t9-8X
	for megaco@optimus.ietf.org; Tue, 23 Dec 2003 09:51:43 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21798
	for <megaco@ietf.org>; Tue, 23 Dec 2003 09:51:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYnsI-0000QM-00
	for megaco@ietf.org; Tue, 23 Dec 2003 09:51:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYnrk-0000YS-00
	for megaco@ietf.org; Tue, 23 Dec 2003 09:50:33 -0500
Received: from motgate8.mot.com ([129.188.136.8])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYnrk-0000XI-00
	for megaco@ietf.org; Tue, 23 Dec 2003 09:50:32 -0500
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134])
	by motgate8.mot.com (Motorola/Motgate3) with ESMTP id hBNEnuE5023366;
	Tue, 23 Dec 2003 07:49:57 -0700 (MST)
Received: from smilevm.motorola.com ([10.14.25.162])
	by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hBNEnrTP017699;
	Tue, 23 Dec 2003 08:49:53 -0600
Message-Id: <5.2.1.1.0.20031223094134.05713db8@IL06EXM13.corp.mot.com>
X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Tue, 23 Dec 2003 09:47:15 -0500
To: megaco@ietf.org
From: Aleksandr Ryabin <kengr@motorola.com>
Subject: RE: [Megaco] CAS Metering Pulse support
Cc: Christian Groves <Christian.Groves@ericsson.com.au>, klaha@hss.hns.com,
        "Soncodi, Adrian" <adrian.soncodi@santera.com>,
        "Kevin Boyle" <kboyle@nortelnetworks.com>
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C0BDF4C71@zrtpd0jq.us.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=3.1 required=5.0 tests=USERPASS autolearn=no 
	version=2.60

Hi all,

Per this email thread I've put together the following document

http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Working/DC-xxx_H.248.26.metd.zip

Summary

This temporary document proposes an amendment to H.248.26
Enhanced Analog Line Packages to include new Metering Pulse
Detection Package and to extend Automatic Metering Package
to be used for digital lines.

This document will be presented to ITU-T in next meeting in Jan 2004
Please review and send comments.

Thanks
         Aleks

At 09:05 AM 10/6/2003, Kevin Boyle wrote:
>There is a 2833-bis draft out now that proposes some extensions to the set
>of detectable events under RFC2833.  If we want CAS metering included (and
>from reading all this, I think we do), then someone needs to contact the
>authors of the 2833-bis document and get the CAS metering stuff added.
>
>The 2833-bis draft can be found at
>http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-03.txt.
>
>Kevin
>
>-----Original Message-----
>From: Christian Groves [mailto:Christian.Groves@ericsson.com.au]
>Sent: Sunday, October 05, 2003 8:38 PM
>To: klaha@hss.hns.com
>Cc: Aleksandr Ryabin; Soncodi, Adrian; megaco@ietf.org; Boyle, Kevin
>[NCRTP:3Z40:EXCH]
>Subject: Re: [Megaco] CAS Metering Pulse support
>
>
>Hello,
>
>As Aleks said RTP is not in the scope of this working group. I believe the
>correct way to move this forward is to write a IETF draft of the carriage of
>
>metering pulses over RTP and submit it to the AVT WG for comment.
>
>Regards, Christian
>
>Kushanava Laha wrote:
>
> > Is it possible for this WG to convey this (metering
> > pulse via RTP) as a requirement to the relevant WG?
> >
> >
> > --- Aleksandr Ryabin <kengr@motorola.com> wrote:
> >
> >>Hi,
> >>
> >>How the pulse information is relayed between MGC is
> >>out of scope MEGACO.
> >>Whatever MGCs use for inter MGC communication will
> >>need to support this
> >>information.
> >>
> >>Regards,
> >>         Aleks
> >>
> >>At 02:44 PM 10/3/2003, Soncodi, Adrian wrote:
> >>
> >>>The pulse rate can change during the call. This is
> >>
> >>done by the switch
> >>
> >>>downstream, which is the TAX office, and which
> >>
> >>changes the rate based on
> >>
> >>>time-of-day and provisioned charge rates. This
> >>
> >>means that the receiving MG
> >>
> >>>would also neeed an event for pulse rate change. A
> >>
> >>little more overhead
> >>
> >>>will occur, but I guess it is acceptable. However,
> >>
> >>it becomes delicate
> >>
> >>>when the pulse rate decreases: by the time the
> >>
> >>receiving MG detects the
> >>
> >>>lower pulse rate, the generating MG has already
> >>
> >>generated a number of
> >>
> >>>extra pulses, based on the higher rate. With some
> >>
> >>effort though, one could
> >>
> >>>make this work.
> >>>
> >>>But I don't understand how the meter pulse rate can
> >>
> >>be relayed between 2
> >>
> >>>MGCs that talk SIP, for example in the following
> >>
> >>tandem-replacement solution:
> >>
> >>>  Local office - R2 - (MG1, MGC1) - SIP - (MGC2,
> >>
> >>MG2) - R2 - TAX office
> >>
> >>>I think an RFC2833-based solution causes less
> >>
> >>headache. But registering a
> >>
> >>>new RFC2833 event is outside the scope of the
> >>
> >>MEGACO working group anyway.
> >>
> >>>For registered events, the ability to negotiate the
> >>
> >>'telephone-event'
> >>
> >>>codec is already available via MEGACO/SDP.
> >>>
> >>>Adrian Soncodi
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: Aleksandr Ryabin [mailto:kengr@motorola.com]
> >>>Sent: Friday, October 03, 2003 12:56 PM
> >>>To: Soncodi, Adrian; megaco@ietf.org
> >>>Cc: Kevin Boyle; Christian Groves
> >>>Subject: RE: [Megaco] CAS Metering Pulse support
> >>>
> >>>
> >>>Proposed new metd package will have functionality
> >>
> >>described in 1).
> >>
> >>>However I have a slightly different proposal for
> >>
> >>relaying.
> >>
> >>>In order to relay pulses all needed to be known is
> >>
> >>a repetition interval,
> >>
> >>>changes to it, if any, and when to start, and stop
> >>
> >>metering pulses.
> >>
> >>>If "receiving" MGC (the one that controls MG which
> >>
> >>receives
> >>
> >>>metering pulses) gets notified with this
> >>
> >>information using new
> >>
> >>>metd package then it can relay this information to
> >>
> >>"generating"
> >>
> >>>MGC (the one that controls MG which generates
> >>
> >>metering pulses).
> >>
> >>>Then "generating" MGC can use amet to start/stop,
> >>
> >>or modify
> >>
> >>>generation of metering pulses.
> >>>
> >>>That is in reality, if repetition interval does not
> >>
> >>change during
> >>
> >>>the call, "receiving" MGC will get only two
> >>
> >>notifies per call:
> >>
> >>>first pulse detected,
> >>>repetition interval calculated (e.g. second pulse
> >>
> >>detected)
> >>
> >>>"Generating" MGC will need to send tree modifies:
> >>>pulse once (when first pulse detected event is
> >>
> >>relayed)
> >>
> >>>pulse forever (when repetition interval received)
> >>>stop pulse generation (when call terminates)
> >>>
> >>>Regards,
> >>>         Aleks
> >>>
> >>>At 01:12 PM 10/3/2003, Soncodi, Adrian wrote:
> >>>
> >>>>In some countries a tandem switch is required to
> >>
> >>propagate meter pulses
> >>
> >>>>(backwards) from the outgoing R2 trunk to the
> >>
> >>incoming R2 trunk. These
> >>
> >>>>pulses are used for billing. A potential problem
> >>
> >>is that the pulse rate
> >>
> >>>>may be very high, sometimes it can be a
> >>
> >>sub-second interval. Therefore, a
> >>
> >>>>tandem MGC which has a considerable number of R2
> >>
> >>trunks will have a big
> >>
> >>>>overhead for propagating meter pulses, which will
> >>
> >>affect its call
> >>
> >>>>processing rate.
> >>>>
> >>>>So I'm wondering if anything can be done about
> >>
> >>this. Here are two
> >>
> >>>>possibilities:
> >>>>
> >>>>1) Allow the MG to detect meter pulses but report
> >>
> >>them in chunks of N. By
> >>
> >>>>default, N=1 (report every pulse), but the MGC
> >>
> >>could also select, say,
> >>
> >>>>N=10, in which case the MG reports once every 10
> >>
> >>pulses. (A residual pulse
> >>
> >>>>count could be reported on Subtract). This method
> >>
> >>saves a lot of NTFY
> >>
> >>>>messages. However, on the other side, the MGC
> >>
> >>would be forced to propagate
> >>
> >>>>the pulses as bursts-of-N, and I am not sure a
> >>
> >>switch is allowed to
> >>
> >>>>transform constant-rate pulsing into bursts. (On
> >>
> >>the other hand why not?
> >>
> >>>>because it's only the total pulse count that is
> >>
> >>relevant for charging.
> >>
> >>>>Time-of-day periods with higher charging rates
> >>
> >>actually result in more
> >>
> >>>>meter pulses.)
> >>>>
> >>>>2) Define a mode which allows the meter pulses to
> >>
> >>be propagated directly
> >>
> >>>>between MGs, without MGC involvement, i.e. by a
> >>
> >>method similar to RFC2833.
> >>
> >>>>RFC2833 does not currently have an event defined
> >>
> >>for meter pulses, but it
> >>
> >>>>could be extended, since it defines a lot of
> >>
> >>signaling-related tones
> >>
> >>>>anyway. In addition to solving the NTFY messaging
> >>
> >>overhead, this method
> >>
> >>>>would have the side benefit that it would also
> >>
> >>work between two MGCs that
> >>
> >>>>use SIP or BICC between them. Currently, there is
> >>
> >>no way to transport
> >>
> >>>>meter pulse information in SIP or BICC, and this
> >>
> >>would have a terrible
> >>
> >>>>overhead anyway.
> >>>>Of course, the ability to detect meter pulses is
> >>
> >>still required, because
> >>
> >>>>there is always the possibility that the MGC must
> >>
> >>perform the
> >>
> >>>>meter-pulse-based charging itself (rather than
> >>
> >>propagate).
> >>
> >>>>Any other ideas or comments?
> >>>>
> >>>>Adrian Soncodi
> >>>>
> >>>>
> >>>>
> >>>>-----Original Message-----
> >>>>From: Christian Groves
> >>
> >>[mailto:Christian.Groves@ericsson.com.au]
> >>
> >>>>Sent: Thursday, October 02, 2003 10:38 PM
> >>>>To: Aleksandr Ryabin
> >>>>Cc: megaco@ietf.org; Kevin Boyle
> >>>>Subject: Re: [Megaco] CAS Metering Pulse support
> >>>>
> >>>>
> >>>>Hello Aleksandr,
> >>>>
> >>>>I'm happy enough to have the your proposed
> >>
> >>amendment if the editor agrees.
> >>
> >>>>Regards, Christian
> >>>>
> >>>>Aleksandr Ryabin wrote:
> >>>>
> >>>>>Hi Christian,
> >>>>>
> >>>>>No description of the event does say how to
> >>
> >>use it for detection
> >>
> >>>>>incoming metering pulse. More over it
> >>
> >>explicitly limits to generation:
> >>
> >>>>>"This event is used in conjunction with the
> >>
> >>"enable metering" and
> >>
> >>>>>"metering pulse burst" signals defined in this
> >>
> >>package..."
> >>
> >>>>>My point being that descriptions of amet
> >>
> >>events and statistics
> >>
> >>>>>are siting that event pr is generated and
> >>
> >>statistics are changed
> >>
> >>>>>only based on previously applied em, or mbp
> >>
> >>signal.
> >>
> >>>>>The wording needs to be amended to cover the
> >>
> >>cases
> >
> > === message truncated ===
> >
> >
> > =====
> > Kushanava Laha
> > Hughes Software Systems
> >
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Shopping - with improved product search
> > http://shopping.yahoo.com
> >


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



From megaco-admin@ietf.org  Tue Dec 23 11:00:44 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25523
	for <megaco-archive@lists.ietf.org>; Tue, 23 Dec 2003 11:00:44 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYow1-00053P-PK; Tue, 23 Dec 2003 10:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYovx-000535-MA
	for megaco@optimus.ietf.org; Tue, 23 Dec 2003 10:58:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25481
	for <megaco@ietf.org>; Tue, 23 Dec 2003 10:58:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYovv-0003HK-00
	for megaco@ietf.org; Tue, 23 Dec 2003 10:58:55 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYosM-0003Fb-00
	for megaco@ietf.org; Tue, 23 Dec 2003 10:55:14 -0500
Received: from nwd2mail2.analog.com ([137.71.25.51])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYosM-0003FY-00
	for Megaco@ietf.org; Tue, 23 Dec 2003 10:55:14 -0500
Received: from nwd2mhb1.analog.com (nwd2mhb1.analog.com [137.71.5.12])
	by nwd2mail2.analog.com (8.12.10/8.12.10) with ESMTP id hBNFtBxd028384
	for <Megaco@ietf.org>; Tue, 23 Dec 2003 10:55:11 -0500
Received: from jasmine.cpgindia.analog.com ([137.71.32.30])
	by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id KAA01052
	for <Megaco@ietf.org>; Tue, 23 Dec 2003 10:55:04 -0500 (EST)
Received: from kumard02 ([137.71.32.241])
	by jasmine.cpgindia.analog.com (8.9.1/8.9.1) with SMTP id VAA10283
	for <Megaco@ietf.org>; Tue, 23 Dec 2003 21:34:56 +0530 (IST)
From: "Kumar" <kumaraswamy.uppu@analog.com>
To: <Megaco@ietf.org>
Date: Tue, 23 Dec 2003 21:35:51 +0530
Message-ID: <KDEKIIFNFCDINCIDOFNMMEBICCAA.kumaraswamy.uppu@analog.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.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
X-Scanned-By: MIMEDefang 2.38
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] Looking for  MGC
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hi All,
  We are looking to buy MGC. Can any one please send us the details
available/widely deployed MGC?

Thanks & Regards,
Kumar


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


From exim@www1.ietf.org  Tue Dec 23 11:03:32 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25642
	for <megaco-archive@odin.ietf.org>; Tue, 23 Dec 2003 11:03:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYozy-0005Cu-E0
	for megaco-archive@odin.ietf.org; Tue, 23 Dec 2003 11:03:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNG36wi020011
	for megaco-archive@odin.ietf.org; Tue, 23 Dec 2003 11:03:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYozy-0005Cg-93
	for megaco-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 11:03:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25601
	for <megaco-web-archive@ietf.org>; Tue, 23 Dec 2003 11:03:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYozv-0003Oe-00
	for megaco-web-archive@ietf.org; Tue, 23 Dec 2003 11:03:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYoxE-0003LH-00
	for megaco-web-archive@ietf.org; Tue, 23 Dec 2003 11:00:16 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYoxE-0003LE-00
	for megaco-web-archive@ietf.org; Tue, 23 Dec 2003 11:00:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYow1-00053P-PK; Tue, 23 Dec 2003 10:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYovx-000535-MA
	for megaco@optimus.ietf.org; Tue, 23 Dec 2003 10:58:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25481
	for <megaco@ietf.org>; Tue, 23 Dec 2003 10:58:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYovv-0003HK-00
	for megaco@ietf.org; Tue, 23 Dec 2003 10:58:55 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYosM-0003Fb-00
	for megaco@ietf.org; Tue, 23 Dec 2003 10:55:14 -0500
Received: from nwd2mail2.analog.com ([137.71.25.51])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYosM-0003FY-00
	for Megaco@ietf.org; Tue, 23 Dec 2003 10:55:14 -0500
Received: from nwd2mhb1.analog.com (nwd2mhb1.analog.com [137.71.5.12])
	by nwd2mail2.analog.com (8.12.10/8.12.10) with ESMTP id hBNFtBxd028384
	for <Megaco@ietf.org>; Tue, 23 Dec 2003 10:55:11 -0500
Received: from jasmine.cpgindia.analog.com ([137.71.32.30])
	by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id KAA01052
	for <Megaco@ietf.org>; Tue, 23 Dec 2003 10:55:04 -0500 (EST)
Received: from kumard02 ([137.71.32.241])
	by jasmine.cpgindia.analog.com (8.9.1/8.9.1) with SMTP id VAA10283
	for <Megaco@ietf.org>; Tue, 23 Dec 2003 21:34:56 +0530 (IST)
From: "Kumar" <kumaraswamy.uppu@analog.com>
To: <Megaco@ietf.org>
Date: Tue, 23 Dec 2003 21:35:51 +0530
Message-ID: <KDEKIIFNFCDINCIDOFNMMEBICCAA.kumaraswamy.uppu@analog.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.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
X-Scanned-By: MIMEDefang 2.38
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Looking for  MGC
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: 7bit

Hi All,
  We are looking to buy MGC. Can any one please send us the details
available/widely deployed MGC?

Thanks & Regards,
Kumar


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



From megaco-admin@ietf.org  Wed Dec 24 04:24:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01949
	for <megaco-archive@lists.ietf.org>; Wed, 24 Dec 2003 04:24:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ5FK-0002i1-Dy; Wed, 24 Dec 2003 04:24:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ47V-0000Fi-Ux
	for megaco@optimus.ietf.org; Wed, 24 Dec 2003 03:11:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00946
	for <megaco@ietf.org>; Wed, 24 Dec 2003 03:11:49 -0500 (EST)
From: gsachin@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZ47Q-0006KA-00
	for megaco@ietf.org; Wed, 24 Dec 2003 03:11:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AZ45b-0006Hg-00
	for megaco@ietf.org; Wed, 24 Dec 2003 03:09:56 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZ43u-0006BM-00
	for megaco@ietf.org; Wed, 24 Dec 2003 03:08:10 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id hBO83GiB016250;
	Wed, 24 Dec 2003 13:33:16 +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 hBO84JZ25034;
	Wed, 24 Dec 2003 13:34:20 +0530 (IST)
Subject: RE: [Megaco] CAS Metering Pulse support
To: Aleksandr Ryabin <kengr@motorola.com>
Cc: megaco@ietf.org, Christian Groves <Christian.Groves@ericsson.com.au>,
        klaha@hss.hns.com, "Soncodi, Adrian" <adrian.soncodi@santera.com>,
        "Kevin Boyle" <kboyle@nortelnetworks.com>
Date: Wed, 24 Dec 2003 13:27:27 +0530
Message-ID: <OF1A72C36B.B9BA0934-ON65256E06.002B1375@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 24/12/2003
 01:24:58 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=4.9 required=5.0 tests=AWL,NO_REAL_NAME,
	ROUND_THE_WORLD_LOCAL,USERPASS autolearn=no version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>






Hi Aleks,

I feel that following should also be taken care in the package procedures.

(A) If the new events descriptor only contains one of these events
         (pr/ric), then the existing events, different from pr/ric, should
         not be effected. As per the protocol rules they will get
         disabled.
(B) Not much clarity on the following statement
"It is noted that care should be taken to specify desired KeepActive flag
         ............"
Are there possible scenarios where the use of KA flag may not be required.
         If not, then should MG report some error and what would be the
         error code?
similarly for the EventBufferControl property.

Regards
Sachin Gupta




Aleksandr Ryabin <kengr@motorola.com>@ietf.org on 12/23/2003 08:17:15 PM

Sent by:    megaco-admin@ietf.org


To:    megaco@ietf.org
cc:    Christian Groves <Christian.Groves@ericsson.com.au>, Kushanava
       Laha/HSS@HSS, "Soncodi, Adrian" <adrian.soncodi@santera.com>, "Kevin
       Boyle" <kboyle@nortelnetworks.com>

Subject:    RE: [Megaco] CAS Metering Pulse support


Hi all,

Per this email thread I've put together the following document

http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Working/DC-xxx_H.248.26.metd.zip


Summary

This temporary document proposes an amendment to H.248.26
Enhanced Analog Line Packages to include new Metering Pulse
Detection Package and to extend Automatic Metering Package
to be used for digital lines.

This document will be presented to ITU-T in next meeting in Jan 2004
Please review and send comments.

Thanks
         Aleks

At 09:05 AM 10/6/2003, Kevin Boyle wrote:
>There is a 2833-bis draft out now that proposes some extensions to the set
>of detectable events under RFC2833.  If we want CAS metering included (and
>from reading all this, I think we do), then someone needs to contact the
>authors of the 2833-bis document and get the CAS metering stuff added.
>
>The 2833-bis draft can be found at
>http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-03.txt.
>
>Kevin
>
>-----Original Message-----
>From: Christian Groves [mailto:Christian.Groves@ericsson.com.au]
>Sent: Sunday, October 05, 2003 8:38 PM
>To: klaha@hss.hns.com
>Cc: Aleksandr Ryabin; Soncodi, Adrian; megaco@ietf.org; Boyle, Kevin
>[NCRTP:3Z40:EXCH]
>Subject: Re: [Megaco] CAS Metering Pulse support
>
>
>Hello,
>
>As Aleks said RTP is not in the scope of this working group. I believe the
>correct way to move this forward is to write a IETF draft of the carriage
of
>
>metering pulses over RTP and submit it to the AVT WG for comment.
>
>Regards, Christian
>
>Kushanava Laha wrote:
>
> > Is it possible for this WG to convey this (metering
> > pulse via RTP) as a requirement to the relevant WG?
> >
> >
> > --- Aleksandr Ryabin <kengr@motorola.com> wrote:
> >
> >>Hi,
> >>
> >>How the pulse information is relayed between MGC is
> >>out of scope MEGACO.
> >>Whatever MGCs use for inter MGC communication will
> >>need to support this
> >>information.
> >>
> >>Regards,
> >>         Aleks
> >>
> >>At 02:44 PM 10/3/2003, Soncodi, Adrian wrote:
> >>
> >>>The pulse rate can change during the call. This is
> >>
> >>done by the switch
> >>
> >>>downstream, which is the TAX office, and which
> >>
> >>changes the rate based on
> >>
> >>>time-of-day and provisioned charge rates. This
> >>
> >>means that the receiving MG
> >>
> >>>would also neeed an event for pulse rate change. A
> >>
> >>little more overhead
> >>
> >>>will occur, but I guess it is acceptable. However,
> >>
> >>it becomes delicate
> >>
> >>>when the pulse rate decreases: by the time the
> >>
> >>receiving MG detects the
> >>
> >>>lower pulse rate, the generating MG has already
> >>
> >>generated a number of
> >>
> >>>extra pulses, based on the higher rate. With some
> >>
> >>effort though, one could
> >>
> >>>make this work.
> >>>
> >>>But I don't understand how the meter pulse rate can
> >>
> >>be relayed between 2
> >>
> >>>MGCs that talk SIP, for example in the following
> >>
> >>tandem-replacement solution:
> >>
> >>>  Local office - R2 - (MG1, MGC1) - SIP - (MGC2,
> >>
> >>MG2) - R2 - TAX office
> >>
> >>>I think an RFC2833-based solution causes less
> >>
> >>headache. But registering a
> >>
> >>>new RFC2833 event is outside the scope of the
> >>
> >>MEGACO working group anyway.
> >>
> >>>For registered events, the ability to negotiate the
> >>
> >>'telephone-event'
> >>
> >>>codec is already available via MEGACO/SDP.
> >>>
> >>>Adrian Soncodi
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: Aleksandr Ryabin [mailto:kengr@motorola.com]
> >>>Sent: Friday, October 03, 2003 12:56 PM
> >>>To: Soncodi, Adrian; megaco@ietf.org
> >>>Cc: Kevin Boyle; Christian Groves
> >>>Subject: RE: [Megaco] CAS Metering Pulse support
> >>>
> >>>
> >>>Proposed new metd package will have functionality
> >>
> >>described in 1).
> >>
> >>>However I have a slightly different proposal for
> >>
> >>relaying.
> >>
> >>>In order to relay pulses all needed to be known is
> >>
> >>a repetition interval,
> >>
> >>>changes to it, if any, and when to start, and stop
> >>
> >>metering pulses.
> >>
> >>>If "receiving" MGC (the one that controls MG which
> >>
> >>receives
> >>
> >>>metering pulses) gets notified with this
> >>
> >>information using new
> >>
> >>>metd package then it can relay this information to
> >>
> >>"generating"
> >>
> >>>MGC (the one that controls MG which generates
> >>
> >>metering pulses).
> >>
> >>>Then "generating" MGC can use amet to start/stop,
> >>
> >>or modify
> >>
> >>>generation of metering pulses.
> >>>
> >>>That is in reality, if repetition interval does not
> >>
> >>change during
> >>
> >>>the call, "receiving" MGC will get only two
> >>
> >>notifies per call:
> >>
> >>>first pulse detected,
> >>>repetition interval calculated (e.g. second pulse
> >>
> >>detected)
> >>
> >>>"Generating" MGC will need to send tree modifies:
> >>>pulse once (when first pulse detected event is
> >>
> >>relayed)
> >>
> >>>pulse forever (when repetition interval received)
> >>>stop pulse generation (when call terminates)
> >>>
> >>>Regards,
> >>>         Aleks
> >>>
> >>>At 01:12 PM 10/3/2003, Soncodi, Adrian wrote:
> >>>
> >>>>In some countries a tandem switch is required to
> >>
> >>propagate meter pulses
> >>
> >>>>(backwards) from the outgoing R2 trunk to the
> >>
> >>incoming R2 trunk. These
> >>
> >>>>pulses are used for billing. A potential problem
> >>
> >>is that the pulse rate
> >>
> >>>>may be very high, sometimes it can be a
> >>
> >>sub-second interval. Therefore, a
> >>
> >>>>tandem MGC which has a considerable number of R2
> >>
> >>trunks will have a big
> >>
> >>>>overhead for propagating meter pulses, which will
> >>
> >>affect its call
> >>
> >>>>processing rate.
> >>>>
> >>>>So I'm wondering if anything can be done about
> >>
> >>this. Here are two
> >>
> >>>>possibilities:
> >>>>
> >>>>1) Allow the MG to detect meter pulses but report
> >>
> >>them in chunks of N. By
> >>
> >>>>default, N=1 (report every pulse), but the MGC
> >>
> >>could also select, say,
> >>
> >>>>N=10, in which case the MG reports once every 10
> >>
> >>pulses. (A residual pulse
> >>
> >>>>count could be reported on Subtract). This method
> >>
> >>saves a lot of NTFY
> >>
> >>>>messages. However, on the other side, the MGC
> >>
> >>would be forced to propagate
> >>
> >>>>the pulses as bursts-of-N, and I am not sure a
> >>
> >>switch is allowed to
> >>
> >>>>transform constant-rate pulsing into bursts. (On
> >>
> >>the other hand why not?
> >>
> >>>>because it's only the total pulse count that is
> >>
> >>relevant for charging.
> >>
> >>>>Time-of-day periods with higher charging rates
> >>
> >>actually result in more
> >>
> >>>>meter pulses.)
> >>>>
> >>>>2) Define a mode which allows the meter pulses to
> >>
> >>be propagated directly
> >>
> >>>>between MGs, without MGC involvement, i.e. by a
> >>
> >>method similar to RFC2833.
> >>
> >>>>RFC2833 does not currently have an event defined
> >>
> >>for meter pulses, but it
> >>
> >>>>could be extended, since it defines a lot of
> >>
> >>signaling-related tones
> >>
> >>>>anyway. In addition to solving the NTFY messaging
> >>
> >>overhead, this method
> >>
> >>>>would have the side benefit that it would also
> >>
> >>work between two MGCs that
> >>
> >>>>use SIP or BICC between them. Currently, there is
> >>
> >>no way to transport
> >>
> >>>>meter pulse information in SIP or BICC, and this
> >>
> >>would have a terrible
> >>
> >>>>overhead anyway.
> >>>>Of course, the ability to detect meter pulses is
> >>
> >>still required, because
> >>
> >>>>there is always the possibility that the MGC must
> >>
> >>perform the
> >>
> >>>>meter-pulse-based charging itself (rather than
> >>
> >>propagate).
> >>
> >>>>Any other ideas or comments?
> >>>>
> >>>>Adrian Soncodi
> >>>>
> >>>>
> >>>>
> >>>>-----Original Message-----
> >>>>From: Christian Groves
> >>
> >>[mailto:Christian.Groves@ericsson.com.au]
> >>
> >>>>Sent: Thursday, October 02, 2003 10:38 PM
> >>>>To: Aleksandr Ryabin
> >>>>Cc: megaco@ietf.org; Kevin Boyle
> >>>>Subject: Re: [Megaco] CAS Metering Pulse support
> >>>>
> >>>>
> >>>>Hello Aleksandr,
> >>>>
> >>>>I'm happy enough to have the your proposed
> >>
> >>amendment if the editor agrees.
> >>
> >>>>Regards, Christian
> >>>>
> >>>>Aleksandr Ryabin wrote:
> >>>>
> >>>>>Hi Christian,
> >>>>>
> >>>>>No description of the event does say how to
> >>
> >>use it for detection
> >>
> >>>>>incoming metering pulse. More over it
> >>
> >>explicitly limits to generation:
> >>
> >>>>>"This event is used in conjunction with the
> >>
> >>"enable metering" and
> >>
> >>>>>"metering pulse burst" signals defined in this
> >>
> >>package..."
> >>
> >>>>>My point being that descriptions of amet
> >>
> >>events and statistics
> >>
> >>>>>are siting that event pr is generated and
> >>
> >>statistics are changed
> >>
> >>>>>only based on previously applied em, or mbp
> >>
> >>signal.
> >>
> >>>>>The wording needs to be amended to cover the
> >>
> >>cases
> >
> > === message truncated ===
> >
> >
> > =====
> > Kushanava Laha
> > Hughes Software Systems
> >
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Shopping - with improved product search
> > http://shopping.yahoo.com
> >


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



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


From exim@www1.ietf.org  Wed Dec 24 04:28:26 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02170
	for <megaco-archive@odin.ietf.org>; Wed, 24 Dec 2003 04:28:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ5J7-0002zN-8C
	for megaco-archive@odin.ietf.org; Wed, 24 Dec 2003 04:27:58 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBO9RvRt011490
	for megaco-archive@odin.ietf.org; Wed, 24 Dec 2003 04:27:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ5J6-0002zF-Sk
	for megaco-web-archive@optimus.ietf.org; Wed, 24 Dec 2003 04:27:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02069
	for <megaco-web-archive@ietf.org>; Wed, 24 Dec 2003 04:27:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZ5J3-00009q-00
	for megaco-web-archive@ietf.org; Wed, 24 Dec 2003 04:27:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AZ5HE-00003V-00
	for megaco-web-archive@ietf.org; Wed, 24 Dec 2003 04:26:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZ5FL-0007nF-00
	for megaco-web-archive@ietf.org; Wed, 24 Dec 2003 04:24:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ5FK-0002i1-Dy; Wed, 24 Dec 2003 04:24:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ47V-0000Fi-Ux
	for megaco@optimus.ietf.org; Wed, 24 Dec 2003 03:11:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00946
	for <megaco@ietf.org>; Wed, 24 Dec 2003 03:11:49 -0500 (EST)
From: gsachin@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZ47Q-0006KA-00
	for megaco@ietf.org; Wed, 24 Dec 2003 03:11:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AZ45b-0006Hg-00
	for megaco@ietf.org; Wed, 24 Dec 2003 03:09:56 -0500
Received: from [203.200.71.140] (helo=spark.hss.co.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZ43u-0006BM-00
	for megaco@ietf.org; Wed, 24 Dec 2003 03:08:10 -0500
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id hBO83GiB016250;
	Wed, 24 Dec 2003 13:33:16 +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 hBO84JZ25034;
	Wed, 24 Dec 2003 13:34:20 +0530 (IST)
Subject: RE: [Megaco] CAS Metering Pulse support
To: Aleksandr Ryabin <kengr@motorola.com>
Cc: megaco@ietf.org, Christian Groves <Christian.Groves@ericsson.com.au>,
        klaha@hss.hns.com, "Soncodi, Adrian" <adrian.soncodi@santera.com>,
        "Kevin Boyle" <kboyle@nortelnetworks.com>
Date: Wed, 24 Dec 2003 13:27:27 +0530
Message-ID: <OF1A72C36B.B9BA0934-ON65256E06.002B1375@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 24/12/2003
 01:24:58 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: Yes, hits=5.1 required=5.0 tests=AWL,NO_REAL_NAME,
	ROUND_THE_WORLD_LOCAL,USERPASS autolearn=no version=2.60
X-Spam-Report: 
	*  0.3 NO_REAL_NAME From: does not include a real name
	*  3.1 USERPASS URI: URL contains username and (optional) password
	*  3.0 ROUND_THE_WORLD_LOCAL Received: says mail sent around the world (HELO)
	* -1.2 AWL AWL: Auto-whitelist adjustment






Hi Aleks,

I feel that following should also be taken care in the package procedures.

(A) If the new events descriptor only contains one of these events
         (pr/ric), then the existing events, different from pr/ric, should
         not be effected. As per the protocol rules they will get
         disabled.
(B) Not much clarity on the following statement
"It is noted that care should be taken to specify desired KeepActive flag
         ............"
Are there possible scenarios where the use of KA flag may not be required.
         If not, then should MG report some error and what would be the
         error code?
similarly for the EventBufferControl property.

Regards
Sachin Gupta




Aleksandr Ryabin <kengr@motorola.com>@ietf.org on 12/23/2003 08:17:15 PM

Sent by:    megaco-admin@ietf.org


To:    megaco@ietf.org
cc:    Christian Groves <Christian.Groves@ericsson.com.au>, Kushanava
       Laha/HSS@HSS, "Soncodi, Adrian" <adrian.soncodi@santera.com>, "Kevin
       Boyle" <kboyle@nortelnetworks.com>

Subject:    RE: [Megaco] CAS Metering Pulse support


Hi all,

Per this email thread I've put together the following document

http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Working/DC-xxx_H.248.26.metd.zip


Summary

This temporary document proposes an amendment to H.248.26
Enhanced Analog Line Packages to include new Metering Pulse
Detection Package and to extend Automatic Metering Package
to be used for digital lines.

This document will be presented to ITU-T in next meeting in Jan 2004
Please review and send comments.

Thanks
         Aleks

At 09:05 AM 10/6/2003, Kevin Boyle wrote:
>There is a 2833-bis draft out now that proposes some extensions to the set
>of detectable events under RFC2833.  If we want CAS metering included (and
>from reading all this, I think we do), then someone needs to contact the
>authors of the 2833-bis document and get the CAS metering stuff added.
>
>The 2833-bis draft can be found at
>http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-03.txt.
>
>Kevin
>
>-----Original Message-----
>From: Christian Groves [mailto:Christian.Groves@ericsson.com.au]
>Sent: Sunday, October 05, 2003 8:38 PM
>To: klaha@hss.hns.com
>Cc: Aleksandr Ryabin; Soncodi, Adrian; megaco@ietf.org; Boyle, Kevin
>[NCRTP:3Z40:EXCH]
>Subject: Re: [Megaco] CAS Metering Pulse support
>
>
>Hello,
>
>As Aleks said RTP is not in the scope of this working group. I believe the
>correct way to move this forward is to write a IETF draft of the carriage
of
>
>metering pulses over RTP and submit it to the AVT WG for comment.
>
>Regards, Christian
>
>Kushanava Laha wrote:
>
> > Is it possible for this WG to convey this (metering
> > pulse via RTP) as a requirement to the relevant WG?
> >
> >
> > --- Aleksandr Ryabin <kengr@motorola.com> wrote:
> >
> >>Hi,
> >>
> >>How the pulse information is relayed between MGC is
> >>out of scope MEGACO.
> >>Whatever MGCs use for inter MGC communication will
> >>need to support this
> >>information.
> >>
> >>Regards,
> >>         Aleks
> >>
> >>At 02:44 PM 10/3/2003, Soncodi, Adrian wrote:
> >>
> >>>The pulse rate can change during the call. This is
> >>
> >>done by the switch
> >>
> >>>downstream, which is the TAX office, and which
> >>
> >>changes the rate based on
> >>
> >>>time-of-day and provisioned charge rates. This
> >>
> >>means that the receiving MG
> >>
> >>>would also neeed an event for pulse rate change. A
> >>
> >>little more overhead
> >>
> >>>will occur, but I guess it is acceptable. However,
> >>
> >>it becomes delicate
> >>
> >>>when the pulse rate decreases: by the time the
> >>
> >>receiving MG detects the
> >>
> >>>lower pulse rate, the generating MG has already
> >>
> >>generated a number of
> >>
> >>>extra pulses, based on the higher rate. With some
> >>
> >>effort though, one could
> >>
> >>>make this work.
> >>>
> >>>But I don't understand how the meter pulse rate can
> >>
> >>be relayed between 2
> >>
> >>>MGCs that talk SIP, for example in the following
> >>
> >>tandem-replacement solution:
> >>
> >>>  Local office - R2 - (MG1, MGC1) - SIP - (MGC2,
> >>
> >>MG2) - R2 - TAX office
> >>
> >>>I think an RFC2833-based solution causes less
> >>
> >>headache. But registering a
> >>
> >>>new RFC2833 event is outside the scope of the
> >>
> >>MEGACO working group anyway.
> >>
> >>>For registered events, the ability to negotiate the
> >>
> >>'telephone-event'
> >>
> >>>codec is already available via MEGACO/SDP.
> >>>
> >>>Adrian Soncodi
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: Aleksandr Ryabin [mailto:kengr@motorola.com]
> >>>Sent: Friday, October 03, 2003 12:56 PM
> >>>To: Soncodi, Adrian; megaco@ietf.org
> >>>Cc: Kevin Boyle; Christian Groves
> >>>Subject: RE: [Megaco] CAS Metering Pulse support
> >>>
> >>>
> >>>Proposed new metd package will have functionality
> >>
> >>described in 1).
> >>
> >>>However I have a slightly different proposal for
> >>
> >>relaying.
> >>
> >>>In order to relay pulses all needed to be known is
> >>
> >>a repetition interval,
> >>
> >>>changes to it, if any, and when to start, and stop
> >>
> >>metering pulses.
> >>
> >>>If "receiving" MGC (the one that controls MG which
> >>
> >>receives
> >>
> >>>metering pulses) gets notified with this
> >>
> >>information using new
> >>
> >>>metd package then it can relay this information to
> >>
> >>"generating"
> >>
> >>>MGC (the one that controls MG which generates
> >>
> >>metering pulses).
> >>
> >>>Then "generating" MGC can use amet to start/stop,
> >>
> >>or modify
> >>
> >>>generation of metering pulses.
> >>>
> >>>That is in reality, if repetition interval does not
> >>
> >>change during
> >>
> >>>the call, "receiving" MGC will get only two
> >>
> >>notifies per call:
> >>
> >>>first pulse detected,
> >>>repetition interval calculated (e.g. second pulse
> >>
> >>detected)
> >>
> >>>"Generating" MGC will need to send tree modifies:
> >>>pulse once (when first pulse detected event is
> >>
> >>relayed)
> >>
> >>>pulse forever (when repetition interval received)
> >>>stop pulse generation (when call terminates)
> >>>
> >>>Regards,
> >>>         Aleks
> >>>
> >>>At 01:12 PM 10/3/2003, Soncodi, Adrian wrote:
> >>>
> >>>>In some countries a tandem switch is required to
> >>
> >>propagate meter pulses
> >>
> >>>>(backwards) from the outgoing R2 trunk to the
> >>
> >>incoming R2 trunk. These
> >>
> >>>>pulses are used for billing. A potential problem
> >>
> >>is that the pulse rate
> >>
> >>>>may be very high, sometimes it can be a
> >>
> >>sub-second interval. Therefore, a
> >>
> >>>>tandem MGC which has a considerable number of R2
> >>
> >>trunks will have a big
> >>
> >>>>overhead for propagating meter pulses, which will
> >>
> >>affect its call
> >>
> >>>>processing rate.
> >>>>
> >>>>So I'm wondering if anything can be done about
> >>
> >>this. Here are two
> >>
> >>>>possibilities:
> >>>>
> >>>>1) Allow the MG to detect meter pulses but report
> >>
> >>them in chunks of N. By
> >>
> >>>>default, N=1 (report every pulse), but the MGC
> >>
> >>could also select, say,
> >>
> >>>>N=10, in which case the MG reports once every 10
> >>
> >>pulses. (A residual pulse
> >>
> >>>>count could be reported on Subtract). This method
> >>
> >>saves a lot of NTFY
> >>
> >>>>messages. However, on the other side, the MGC
> >>
> >>would be forced to propagate
> >>
> >>>>the pulses as bursts-of-N, and I am not sure a
> >>
> >>switch is allowed to
> >>
> >>>>transform constant-rate pulsing into bursts. (On
> >>
> >>the other hand why not?
> >>
> >>>>because it's only the total pulse count that is
> >>
> >>relevant for charging.
> >>
> >>>>Time-of-day periods with higher charging rates
> >>
> >>actually result in more
> >>
> >>>>meter pulses.)
> >>>>
> >>>>2) Define a mode which allows the meter pulses to
> >>
> >>be propagated directly
> >>
> >>>>between MGs, without MGC involvement, i.e. by a
> >>
> >>method similar to RFC2833.
> >>
> >>>>RFC2833 does not currently have an event defined
> >>
> >>for meter pulses, but it
> >>
> >>>>could be extended, since it defines a lot of
> >>
> >>signaling-related tones
> >>
> >>>>anyway. In addition to solving the NTFY messaging
> >>
> >>overhead, this method
> >>
> >>>>would have the side benefit that it would also
> >>
> >>work between two MGCs that
> >>
> >>>>use SIP or BICC between them. Currently, there is
> >>
> >>no way to transport
> >>
> >>>>meter pulse information in SIP or BICC, and this
> >>
> >>would have a terrible
> >>
> >>>>overhead anyway.
> >>>>Of course, the ability to detect meter pulses is
> >>
> >>still required, because
> >>
> >>>>there is always the possibility that the MGC must
> >>
> >>perform the
> >>
> >>>>meter-pulse-based charging itself (rather than
> >>
> >>propagate).
> >>
> >>>>Any other ideas or comments?
> >>>>
> >>>>Adrian Soncodi
> >>>>
> >>>>
> >>>>
> >>>>-----Original Message-----
> >>>>From: Christian Groves
> >>
> >>[mailto:Christian.Groves@ericsson.com.au]
> >>
> >>>>Sent: Thursday, October 02, 2003 10:38 PM
> >>>>To: Aleksandr Ryabin
> >>>>Cc: megaco@ietf.org; Kevin Boyle
> >>>>Subject: Re: [Megaco] CAS Metering Pulse support
> >>>>
> >>>>
> >>>>Hello Aleksandr,
> >>>>
> >>>>I'm happy enough to have the your proposed
> >>
> >>amendment if the editor agrees.
> >>
> >>>>Regards, Christian
> >>>>
> >>>>Aleksandr Ryabin wrote:
> >>>>
> >>>>>Hi Christian,
> >>>>>
> >>>>>No description of the event does say how to
> >>
> >>use it for detection
> >>
> >>>>>incoming metering pulse. More over it
> >>
> >>explicitly limits to generation:
> >>
> >>>>>"This event is used in conjunction with the
> >>
> >>"enable metering" and
> >>
> >>>>>"metering pulse burst" signals defined in this
> >>
> >>package..."
> >>
> >>>>>My point being that descriptions of amet
> >>
> >>events and statistics
> >>
> >>>>>are siting that event pr is generated and
> >>
> >>statistics are changed
> >>
> >>>>>only based on previously applied em, or mbp
> >>
> >>signal.
> >>
> >>>>>The wording needs to be amended to cover the
> >>
> >>cases
> >
> > === message truncated ===
> >
> >
> > =====
> > Kushanava Laha
> > Hughes Software Systems
> >
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Shopping - with improved product search
> > http://shopping.yahoo.com
> >


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



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



From megaco-admin@ietf.org  Wed Dec 24 15:13:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21188
	for <megaco-archive@lists.ietf.org>; Wed, 24 Dec 2003 15:13:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZFNK-0000oy-RG; Wed, 24 Dec 2003 15:12:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZFMW-0000oY-Tk
	for megaco@optimus.ietf.org; Wed, 24 Dec 2003 15:12:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21065
	for <megaco@ietf.org>; Wed, 24 Dec 2003 15:12:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZFMV-0006k3-00
	for megaco@ietf.org; Wed, 24 Dec 2003 15:12:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AZFKg-0006hP-00
	for megaco@ietf.org; Wed, 24 Dec 2003 15:10:16 -0500
Received: from motgate2.mot.com ([136.182.1.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZFJf-0006dz-00
	for megaco@ietf.org; Wed, 24 Dec 2003 15:09:11 -0500
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234])
	by motgate2.mot.com (Motorola/Motgate2) with ESMTP id hBOK8SOG002692;
	Wed, 24 Dec 2003 13:08:38 -0700 (MST)
Received: from smilevm.motorola.com ([10.14.25.162])
	by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hBOK8PmF015747;
	Wed, 24 Dec 2003 14:08:26 -0600
Message-Id: <5.2.1.1.0.20031224144954.0335abc8@IL06EXM13.corp.mot.com>
X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Wed, 24 Dec 2003 15:05:46 -0500
To: <megaco@ietf.org>, <gsachin@hss.hns.com>
From: Aleksandr Ryabin <kengr@motorola.com>
Subject: RE: [Megaco] CAS Metering Pulse support
In-Reply-To: <OF1A72C36B.B9BA0934-ON65256E06.002B1375@hss.hns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=3.1 required=5.0 tests=USERPASS autolearn=no 
	version=2.60
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

Hi,
Please see below inline [AR].
Regards,
         Aleks

At 02:57 AM 12/24/2003, gsachin@hss.hns.com wrote:

>Hi Aleks,
>
>I feel that following should also be taken care in the package procedures.
>
>(A) If the new events descriptor only contains one of these events
>          (pr/ric), then the existing events, different from pr/ric, should
>          not be effected. As per the protocol rules they will get
>          disabled.

[AR] Procedures can not break base protocol specification, thus that holds 
true.
That is MGC must always provide complete EventsDescriptor.

>(B) Not much clarity on the following statement
>"It is noted that care should be taken to specify desired KeepActive flag
>          ............"
>Are there possible scenarios where the use of KA flag may not be required.
>          If not, then should MG report some error and what would be the
>          error code?
>similarly for the EventBufferControl property.

[AR] Not providing KA and usage EBC=on is valid from protocol point of view,
does not create any erroneous combinations and depending on a particular
situation can possibly produce meaningful results. Thus I think that package
should leave usage of these up to implementation. In this case procedures
simply pointing out to the most common usage and warns of potential problem
overlook by implementations.


>Regards
>Sachin Gupta
>
>
>
>
>Aleksandr Ryabin <kengr@motorola.com>@ietf.org on 12/23/2003 08:17:15 PM
>
>Sent by:    megaco-admin@ietf.org
>
>
>To:    megaco@ietf.org
>cc:    Christian Groves <Christian.Groves@ericsson.com.au>, Kushanava
>        Laha/HSS@HSS, "Soncodi, Adrian" <adrian.soncodi@santera.com>, "Kevin
>        Boyle" <kboyle@nortelnetworks.com>
>
>Subject:    RE: [Megaco] CAS Metering Pulse support
>
>
>Hi all,
>
>Per this email thread I've put together the following document
>
>http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Working/DC-xxx_H.248.26.metd.zip
>
>
>Summary
>
>This temporary document proposes an amendment to H.248.26
>Enhanced Analog Line Packages to include new Metering Pulse
>Detection Package and to extend Automatic Metering Package
>to be used for digital lines.
>
>This document will be presented to ITU-T in next meeting in Jan 2004
>Please review and send comments.
>
>Thanks
>          Aleks
>
>At 09:05 AM 10/6/2003, Kevin Boyle wrote:
> >There is a 2833-bis draft out now that proposes some extensions to the set
> >of detectable events under RFC2833.  If we want CAS metering included (and
> >from reading all this, I think we do), then someone needs to contact the
> >authors of the 2833-bis document and get the CAS metering stuff added.
> >
> >The 2833-bis draft can be found at
> >http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-03.txt.
> >
> >Kevin
> >
> >-----Original Message-----
> >From: Christian Groves [mailto:Christian.Groves@ericsson.com.au]
> >Sent: Sunday, October 05, 2003 8:38 PM
> >To: klaha@hss.hns.com
> >Cc: Aleksandr Ryabin; Soncodi, Adrian; megaco@ietf.org; Boyle, Kevin
> >[NCRTP:3Z40:EXCH]
> >Subject: Re: [Megaco] CAS Metering Pulse support
> >
> >
> >Hello,
> >
> >As Aleks said RTP is not in the scope of this working group. I believe the
> >correct way to move this forward is to write a IETF draft of the carriage
>of
> >
> >metering pulses over RTP and submit it to the AVT WG for comment.
> >
> >Regards, Christian
> >
> >Kushanava Laha wrote:
> >
> > > Is it possible for this WG to convey this (metering
> > > pulse via RTP) as a requirement to the relevant WG?
> > >
> > >
> > > --- Aleksandr Ryabin <kengr@motorola.com> wrote:
> > >
> > >>Hi,
> > >>
> > >>How the pulse information is relayed between MGC is
> > >>out of scope MEGACO.
> > >>Whatever MGCs use for inter MGC communication will
> > >>need to support this
> > >>information.
> > >>
> > >>Regards,
> > >>         Aleks
> > >>
> > >>At 02:44 PM 10/3/2003, Soncodi, Adrian wrote:
> > >>
> > >>>The pulse rate can change during the call. This is
> > >>
> > >>done by the switch
> > >>
> > >>>downstream, which is the TAX office, and which
> > >>
> > >>changes the rate based on
> > >>
> > >>>time-of-day and provisioned charge rates. This
> > >>
> > >>means that the receiving MG
> > >>
> > >>>would also neeed an event for pulse rate change. A
> > >>
> > >>little more overhead
> > >>
> > >>>will occur, but I guess it is acceptable. However,
> > >>
> > >>it becomes delicate
> > >>
> > >>>when the pulse rate decreases: by the time the
> > >>
> > >>receiving MG detects the
> > >>
> > >>>lower pulse rate, the generating MG has already
> > >>
> > >>generated a number of
> > >>
> > >>>extra pulses, based on the higher rate. With some
> > >>
> > >>effort though, one could
> > >>
> > >>>make this work.
> > >>>
> > >>>But I don't understand how the meter pulse rate can
> > >>
> > >>be relayed between 2
> > >>
> > >>>MGCs that talk SIP, for example in the following
> > >>
> > >>tandem-replacement solution:
> > >>
> > >>>  Local office - R2 - (MG1, MGC1) - SIP - (MGC2,
> > >>
> > >>MG2) - R2 - TAX office
> > >>
> > >>>I think an RFC2833-based solution causes less
> > >>
> > >>headache. But registering a
> > >>
> > >>>new RFC2833 event is outside the scope of the
> > >>
> > >>MEGACO working group anyway.
> > >>
> > >>>For registered events, the ability to negotiate the
> > >>
> > >>'telephone-event'
> > >>
> > >>>codec is already available via MEGACO/SDP.
> > >>>
> > >>>Adrian Soncodi
> > >>>
> > >>>
> > >>>-----Original Message-----
> > >>>From: Aleksandr Ryabin [mailto:kengr@motorola.com]
> > >>>Sent: Friday, October 03, 2003 12:56 PM
> > >>>To: Soncodi, Adrian; megaco@ietf.org
> > >>>Cc: Kevin Boyle; Christian Groves
> > >>>Subject: RE: [Megaco] CAS Metering Pulse support
> > >>>
> > >>>
> > >>>Proposed new metd package will have functionality
> > >>
> > >>described in 1).
> > >>
> > >>>However I have a slightly different proposal for
> > >>
> > >>relaying.
> > >>
> > >>>In order to relay pulses all needed to be known is
> > >>
> > >>a repetition interval,
> > >>
> > >>>changes to it, if any, and when to start, and stop
> > >>
> > >>metering pulses.
> > >>
> > >>>If "receiving" MGC (the one that controls MG which
> > >>
> > >>receives
> > >>
> > >>>metering pulses) gets notified with this
> > >>
> > >>information using new
> > >>
> > >>>metd package then it can relay this information to
> > >>
> > >>"generating"
> > >>
> > >>>MGC (the one that controls MG which generates
> > >>
> > >>metering pulses).
> > >>
> > >>>Then "generating" MGC can use amet to start/stop,
> > >>
> > >>or modify
> > >>
> > >>>generation of metering pulses.
> > >>>
> > >>>That is in reality, if repetition interval does not
> > >>
> > >>change during
> > >>
> > >>>the call, "receiving" MGC will get only two
> > >>
> > >>notifies per call:
> > >>
> > >>>first pulse detected,
> > >>>repetition interval calculated (e.g. second pulse
> > >>
> > >>detected)
> > >>
> > >>>"Generating" MGC will need to send tree modifies:
> > >>>pulse once (when first pulse detected event is
> > >>
> > >>relayed)
> > >>
> > >>>pulse forever (when repetition interval received)
> > >>>stop pulse generation (when call terminates)
> > >>>
> > >>>Regards,
> > >>>         Aleks
> > >>>
> > >>>At 01:12 PM 10/3/2003, Soncodi, Adrian wrote:
> > >>>
> > >>>>In some countries a tandem switch is required to
> > >>
> > >>propagate meter pulses
> > >>
> > >>>>(backwards) from the outgoing R2 trunk to the
> > >>
> > >>incoming R2 trunk. These
> > >>
> > >>>>pulses are used for billing. A potential problem
> > >>
> > >>is that the pulse rate
> > >>
> > >>>>may be very high, sometimes it can be a
> > >>
> > >>sub-second interval. Therefore, a
> > >>
> > >>>>tandem MGC which has a considerable number of R2
> > >>
> > >>trunks will have a big
> > >>
> > >>>>overhead for propagating meter pulses, which will
> > >>
> > >>affect its call
> > >>
> > >>>>processing rate.
> > >>>>
> > >>>>So I'm wondering if anything can be done about
> > >>
> > >>this. Here are two
> > >>
> > >>>>possibilities:
> > >>>>
> > >>>>1) Allow the MG to detect meter pulses but report
> > >>
> > >>them in chunks of N. By
> > >>
> > >>>>default, N=1 (report every pulse), but the MGC
> > >>
> > >>could also select, say,
> > >>
> > >>>>N=10, in which case the MG reports once every 10
> > >>
> > >>pulses. (A residual pulse
> > >>
> > >>>>count could be reported on Subtract). This method
> > >>
> > >>saves a lot of NTFY
> > >>
> > >>>>messages. However, on the other side, the MGC
> > >>
> > >>would be forced to propagate
> > >>
> > >>>>the pulses as bursts-of-N, and I am not sure a
> > >>
> > >>switch is allowed to
> > >>
> > >>>>transform constant-rate pulsing into bursts. (On
> > >>
> > >>the other hand why not?
> > >>
> > >>>>because it's only the total pulse count that is
> > >>
> > >>relevant for charging.
> > >>
> > >>>>Time-of-day periods with higher charging rates
> > >>
> > >>actually result in more
> > >>
> > >>>>meter pulses.)
> > >>>>
> > >>>>2) Define a mode which allows the meter pulses to
> > >>
> > >>be propagated directly
> > >>
> > >>>>between MGs, without MGC involvement, i.e. by a
> > >>
> > >>method similar to RFC2833.
> > >>
> > >>>>RFC2833 does not currently have an event defined
> > >>
> > >>for meter pulses, but it
> > >>
> > >>>>could be extended, since it defines a lot of
> > >>
> > >>signaling-related tones
> > >>
> > >>>>anyway. In addition to solving the NTFY messaging
> > >>
> > >>overhead, this method
> > >>
> > >>>>would have the side benefit that it would also
> > >>
> > >>work between two MGCs that
> > >>
> > >>>>use SIP or BICC between them. Currently, there is
> > >>
> > >>no way to transport
> > >>
> > >>>>meter pulse information in SIP or BICC, and this
> > >>
> > >>would have a terrible
> > >>
> > >>>>overhead anyway.
> > >>>>Of course, the ability to detect meter pulses is
> > >>
> > >>still required, because
> > >>
> > >>>>there is always the possibility that the MGC must
> > >>
> > >>perform the
> > >>
> > >>>>meter-pulse-based charging itself (rather than
> > >>
> > >>propagate).
> > >>
> > >>>>Any other ideas or comments?
> > >>>>
> > >>>>Adrian Soncodi
> > >>>>
> > >>>>
> > >>>>
> > >>>>-----Original Message-----
> > >>>>From: Christian Groves
> > >>
> > >>[mailto:Christian.Groves@ericsson.com.au]
> > >>
> > >>>>Sent: Thursday, October 02, 2003 10:38 PM
> > >>>>To: Aleksandr Ryabin
> > >>>>Cc: megaco@ietf.org; Kevin Boyle
> > >>>>Subject: Re: [Megaco] CAS Metering Pulse support
> > >>>>
> > >>>>
> > >>>>Hello Aleksandr,
> > >>>>
> > >>>>I'm happy enough to have the your proposed
> > >>
> > >>amendment if the editor agrees.
> > >>
> > >>>>Regards, Christian
> > >>>>
> > >>>>Aleksandr Ryabin wrote:
> > >>>>
> > >>>>>Hi Christian,
> > >>>>>
> > >>>>>No description of the event does say how to
> > >>
> > >>use it for detection
> > >>
> > >>>>>incoming metering pulse. More over it
> > >>
> > >>explicitly limits to generation:
> > >>
> > >>>>>"This event is used in conjunction with the
> > >>
> > >>"enable metering" and
> > >>
> > >>>>>"metering pulse burst" signals defined in this
> > >>
> > >>package..."
> > >>
> > >>>>>My point being that descriptions of amet
> > >>
> > >>events and statistics
> > >>
> > >>>>>are siting that event pr is generated and
> > >>
> > >>statistics are changed
> > >>
> > >>>>>only based on previously applied em, or mbp
> > >>
> > >>signal.
> > >>
> > >>>>>The wording needs to be amended to cover the
> > >>
> > >>cases
> > >
> > > === message truncated ===
> > >
> > >
> > > =====
> > > Kushanava Laha
> > > Hughes Software Systems
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > The New Yahoo! Shopping - with improved product search
> > > http://shopping.yahoo.com
> > >
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>  https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco


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


From exim@www1.ietf.org  Wed Dec 24 15:16:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21481
	for <megaco-archive@odin.ietf.org>; Wed, 24 Dec 2003 15:16:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZFQJ-0000wx-1L
	for megaco-archive@odin.ietf.org; Wed, 24 Dec 2003 15:16:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBOKG3OV003645
	for megaco-archive@odin.ietf.org; Wed, 24 Dec 2003 15:16:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZFQI-0000wi-Rl
	for megaco-web-archive@optimus.ietf.org; Wed, 24 Dec 2003 15:16:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21423
	for <megaco-web-archive@ietf.org>; Wed, 24 Dec 2003 15:16:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZFQH-0006op-00
	for megaco-web-archive@ietf.org; Wed, 24 Dec 2003 15:16:01 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AZFOM-0006mk-00
	for megaco-web-archive@ietf.org; Wed, 24 Dec 2003 15:14:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZFNN-0006lV-00
	for megaco-web-archive@ietf.org; Wed, 24 Dec 2003 15:13:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZFNK-0000oy-RG; Wed, 24 Dec 2003 15:12:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZFMW-0000oY-Tk
	for megaco@optimus.ietf.org; Wed, 24 Dec 2003 15:12:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21065
	for <megaco@ietf.org>; Wed, 24 Dec 2003 15:12:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZFMV-0006k3-00
	for megaco@ietf.org; Wed, 24 Dec 2003 15:12:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AZFKg-0006hP-00
	for megaco@ietf.org; Wed, 24 Dec 2003 15:10:16 -0500
Received: from motgate2.mot.com ([136.182.1.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZFJf-0006dz-00
	for megaco@ietf.org; Wed, 24 Dec 2003 15:09:11 -0500
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234])
	by motgate2.mot.com (Motorola/Motgate2) with ESMTP id hBOK8SOG002692;
	Wed, 24 Dec 2003 13:08:38 -0700 (MST)
Received: from smilevm.motorola.com ([10.14.25.162])
	by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hBOK8PmF015747;
	Wed, 24 Dec 2003 14:08:26 -0600
Message-Id: <5.2.1.1.0.20031224144954.0335abc8@IL06EXM13.corp.mot.com>
X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Wed, 24 Dec 2003 15:05:46 -0500
To: <megaco@ietf.org>, <gsachin@hss.hns.com>
From: Aleksandr Ryabin <kengr@motorola.com>
Subject: RE: [Megaco] CAS Metering Pulse support
In-Reply-To: <OF1A72C36B.B9BA0934-ON65256E06.002B1375@hss.hns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=3.1 required=5.0 tests=USERPASS autolearn=no 
	version=2.60

Hi,
Please see below inline [AR].
Regards,
         Aleks

At 02:57 AM 12/24/2003, gsachin@hss.hns.com wrote:

>Hi Aleks,
>
>I feel that following should also be taken care in the package procedures.
>
>(A) If the new events descriptor only contains one of these events
>          (pr/ric), then the existing events, different from pr/ric, should
>          not be effected. As per the protocol rules they will get
>          disabled.

[AR] Procedures can not break base protocol specification, thus that holds 
true.
That is MGC must always provide complete EventsDescriptor.

>(B) Not much clarity on the following statement
>"It is noted that care should be taken to specify desired KeepActive flag
>          ............"
>Are there possible scenarios where the use of KA flag may not be required.
>          If not, then should MG report some error and what would be the
>          error code?
>similarly for the EventBufferControl property.

[AR] Not providing KA and usage EBC=on is valid from protocol point of view,
does not create any erroneous combinations and depending on a particular
situation can possibly produce meaningful results. Thus I think that package
should leave usage of these up to implementation. In this case procedures
simply pointing out to the most common usage and warns of potential problem
overlook by implementations.


>Regards
>Sachin Gupta
>
>
>
>
>Aleksandr Ryabin <kengr@motorola.com>@ietf.org on 12/23/2003 08:17:15 PM
>
>Sent by:    megaco-admin@ietf.org
>
>
>To:    megaco@ietf.org
>cc:    Christian Groves <Christian.Groves@ericsson.com.au>, Kushanava
>        Laha/HSS@HSS, "Soncodi, Adrian" <adrian.soncodi@santera.com>, "Kevin
>        Boyle" <kboyle@nortelnetworks.com>
>
>Subject:    RE: [Megaco] CAS Metering Pulse support
>
>
>Hi all,
>
>Per this email thread I've put together the following document
>
>http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/Working/DC-xxx_H.248.26.metd.zip
>
>
>Summary
>
>This temporary document proposes an amendment to H.248.26
>Enhanced Analog Line Packages to include new Metering Pulse
>Detection Package and to extend Automatic Metering Package
>to be used for digital lines.
>
>This document will be presented to ITU-T in next meeting in Jan 2004
>Please review and send comments.
>
>Thanks
>          Aleks
>
>At 09:05 AM 10/6/2003, Kevin Boyle wrote:
> >There is a 2833-bis draft out now that proposes some extensions to the set
> >of detectable events under RFC2833.  If we want CAS metering included (and
> >from reading all this, I think we do), then someone needs to contact the
> >authors of the 2833-bis document and get the CAS metering stuff added.
> >
> >The 2833-bis draft can be found at
> >http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-03.txt.
> >
> >Kevin
> >
> >-----Original Message-----
> >From: Christian Groves [mailto:Christian.Groves@ericsson.com.au]
> >Sent: Sunday, October 05, 2003 8:38 PM
> >To: klaha@hss.hns.com
> >Cc: Aleksandr Ryabin; Soncodi, Adrian; megaco@ietf.org; Boyle, Kevin
> >[NCRTP:3Z40:EXCH]
> >Subject: Re: [Megaco] CAS Metering Pulse support
> >
> >
> >Hello,
> >
> >As Aleks said RTP is not in the scope of this working group. I believe the
> >correct way to move this forward is to write a IETF draft of the carriage
>of
> >
> >metering pulses over RTP and submit it to the AVT WG for comment.
> >
> >Regards, Christian
> >
> >Kushanava Laha wrote:
> >
> > > Is it possible for this WG to convey this (metering
> > > pulse via RTP) as a requirement to the relevant WG?
> > >
> > >
> > > --- Aleksandr Ryabin <kengr@motorola.com> wrote:
> > >
> > >>Hi,
> > >>
> > >>How the pulse information is relayed between MGC is
> > >>out of scope MEGACO.
> > >>Whatever MGCs use for inter MGC communication will
> > >>need to support this
> > >>information.
> > >>
> > >>Regards,
> > >>         Aleks
> > >>
> > >>At 02:44 PM 10/3/2003, Soncodi, Adrian wrote:
> > >>
> > >>>The pulse rate can change during the call. This is
> > >>
> > >>done by the switch
> > >>
> > >>>downstream, which is the TAX office, and which
> > >>
> > >>changes the rate based on
> > >>
> > >>>time-of-day and provisioned charge rates. This
> > >>
> > >>means that the receiving MG
> > >>
> > >>>would also neeed an event for pulse rate change. A
> > >>
> > >>little more overhead
> > >>
> > >>>will occur, but I guess it is acceptable. However,
> > >>
> > >>it becomes delicate
> > >>
> > >>>when the pulse rate decreases: by the time the
> > >>
> > >>receiving MG detects the
> > >>
> > >>>lower pulse rate, the generating MG has already
> > >>
> > >>generated a number of
> > >>
> > >>>extra pulses, based on the higher rate. With some
> > >>
> > >>effort though, one could
> > >>
> > >>>make this work.
> > >>>
> > >>>But I don't understand how the meter pulse rate can
> > >>
> > >>be relayed between 2
> > >>
> > >>>MGCs that talk SIP, for example in the following
> > >>
> > >>tandem-replacement solution:
> > >>
> > >>>  Local office - R2 - (MG1, MGC1) - SIP - (MGC2,
> > >>
> > >>MG2) - R2 - TAX office
> > >>
> > >>>I think an RFC2833-based solution causes less
> > >>
> > >>headache. But registering a
> > >>
> > >>>new RFC2833 event is outside the scope of the
> > >>
> > >>MEGACO working group anyway.
> > >>
> > >>>For registered events, the ability to negotiate the
> > >>
> > >>'telephone-event'
> > >>
> > >>>codec is already available via MEGACO/SDP.
> > >>>
> > >>>Adrian Soncodi
> > >>>
> > >>>
> > >>>-----Original Message-----
> > >>>From: Aleksandr Ryabin [mailto:kengr@motorola.com]
> > >>>Sent: Friday, October 03, 2003 12:56 PM
> > >>>To: Soncodi, Adrian; megaco@ietf.org
> > >>>Cc: Kevin Boyle; Christian Groves
> > >>>Subject: RE: [Megaco] CAS Metering Pulse support
> > >>>
> > >>>
> > >>>Proposed new metd package will have functionality
> > >>
> > >>described in 1).
> > >>
> > >>>However I have a slightly different proposal for
> > >>
> > >>relaying.
> > >>
> > >>>In order to relay pulses all needed to be known is
> > >>
> > >>a repetition interval,
> > >>
> > >>>changes to it, if any, and when to start, and stop
> > >>
> > >>metering pulses.
> > >>
> > >>>If "receiving" MGC (the one that controls MG which
> > >>
> > >>receives
> > >>
> > >>>metering pulses) gets notified with this
> > >>
> > >>information using new
> > >>
> > >>>metd package then it can relay this information to
> > >>
> > >>"generating"
> > >>
> > >>>MGC (the one that controls MG which generates
> > >>
> > >>metering pulses).
> > >>
> > >>>Then "generating" MGC can use amet to start/stop,
> > >>
> > >>or modify
> > >>
> > >>>generation of metering pulses.
> > >>>
> > >>>That is in reality, if repetition interval does not
> > >>
> > >>change during
> > >>
> > >>>the call, "receiving" MGC will get only two
> > >>
> > >>notifies per call:
> > >>
> > >>>first pulse detected,
> > >>>repetition interval calculated (e.g. second pulse
> > >>
> > >>detected)
> > >>
> > >>>"Generating" MGC will need to send tree modifies:
> > >>>pulse once (when first pulse detected event is
> > >>
> > >>relayed)
> > >>
> > >>>pulse forever (when repetition interval received)
> > >>>stop pulse generation (when call terminates)
> > >>>
> > >>>Regards,
> > >>>         Aleks
> > >>>
> > >>>At 01:12 PM 10/3/2003, Soncodi, Adrian wrote:
> > >>>
> > >>>>In some countries a tandem switch is required to
> > >>
> > >>propagate meter pulses
> > >>
> > >>>>(backwards) from the outgoing R2 trunk to the
> > >>
> > >>incoming R2 trunk. These
> > >>
> > >>>>pulses are used for billing. A potential problem
> > >>
> > >>is that the pulse rate
> > >>
> > >>>>may be very high, sometimes it can be a
> > >>
> > >>sub-second interval. Therefore, a
> > >>
> > >>>>tandem MGC which has a considerable number of R2
> > >>
> > >>trunks will have a big
> > >>
> > >>>>overhead for propagating meter pulses, which will
> > >>
> > >>affect its call
> > >>
> > >>>>processing rate.
> > >>>>
> > >>>>So I'm wondering if anything can be done about
> > >>
> > >>this. Here are two
> > >>
> > >>>>possibilities:
> > >>>>
> > >>>>1) Allow the MG to detect meter pulses but report
> > >>
> > >>them in chunks of N. By
> > >>
> > >>>>default, N=1 (report every pulse), but the MGC
> > >>
> > >>could also select, say,
> > >>
> > >>>>N=10, in which case the MG reports once every 10
> > >>
> > >>pulses. (A residual pulse
> > >>
> > >>>>count could be reported on Subtract). This method
> > >>
> > >>saves a lot of NTFY
> > >>
> > >>>>messages. However, on the other side, the MGC
> > >>
> > >>would be forced to propagate
> > >>
> > >>>>the pulses as bursts-of-N, and I am not sure a
> > >>
> > >>switch is allowed to
> > >>
> > >>>>transform constant-rate pulsing into bursts. (On
> > >>
> > >>the other hand why not?
> > >>
> > >>>>because it's only the total pulse count that is
> > >>
> > >>relevant for charging.
> > >>
> > >>>>Time-of-day periods with higher charging rates
> > >>
> > >>actually result in more
> > >>
> > >>>>meter pulses.)
> > >>>>
> > >>>>2) Define a mode which allows the meter pulses to
> > >>
> > >>be propagated directly
> > >>
> > >>>>between MGs, without MGC involvement, i.e. by a
> > >>
> > >>method similar to RFC2833.
> > >>
> > >>>>RFC2833 does not currently have an event defined
> > >>
> > >>for meter pulses, but it
> > >>
> > >>>>could be extended, since it defines a lot of
> > >>
> > >>signaling-related tones
> > >>
> > >>>>anyway. In addition to solving the NTFY messaging
> > >>
> > >>overhead, this method
> > >>
> > >>>>would have the side benefit that it would also
> > >>
> > >>work between two MGCs that
> > >>
> > >>>>use SIP or BICC between them. Currently, there is
> > >>
> > >>no way to transport
> > >>
> > >>>>meter pulse information in SIP or BICC, and this
> > >>
> > >>would have a terrible
> > >>
> > >>>>overhead anyway.
> > >>>>Of course, the ability to detect meter pulses is
> > >>
> > >>still required, because
> > >>
> > >>>>there is always the possibility that the MGC must
> > >>
> > >>perform the
> > >>
> > >>>>meter-pulse-based charging itself (rather than
> > >>
> > >>propagate).
> > >>
> > >>>>Any other ideas or comments?
> > >>>>
> > >>>>Adrian Soncodi
> > >>>>
> > >>>>
> > >>>>
> > >>>>-----Original Message-----
> > >>>>From: Christian Groves
> > >>
> > >>[mailto:Christian.Groves@ericsson.com.au]
> > >>
> > >>>>Sent: Thursday, October 02, 2003 10:38 PM
> > >>>>To: Aleksandr Ryabin
> > >>>>Cc: megaco@ietf.org; Kevin Boyle
> > >>>>Subject: Re: [Megaco] CAS Metering Pulse support
> > >>>>
> > >>>>
> > >>>>Hello Aleksandr,
> > >>>>
> > >>>>I'm happy enough to have the your proposed
> > >>
> > >>amendment if the editor agrees.
> > >>
> > >>>>Regards, Christian
> > >>>>
> > >>>>Aleksandr Ryabin wrote:
> > >>>>
> > >>>>>Hi Christian,
> > >>>>>
> > >>>>>No description of the event does say how to
> > >>
> > >>use it for detection
> > >>
> > >>>>>incoming metering pulse. More over it
> > >>
> > >>explicitly limits to generation:
> > >>
> > >>>>>"This event is used in conjunction with the
> > >>
> > >>"enable metering" and
> > >>
> > >>>>>"metering pulse burst" signals defined in this
> > >>
> > >>package..."
> > >>
> > >>>>>My point being that descriptions of amet
> > >>
> > >>events and statistics
> > >>
> > >>>>>are siting that event pr is generated and
> > >>
> > >>statistics are changed
> > >>
> > >>>>>only based on previously applied em, or mbp
> > >>
> > >>signal.
> > >>
> > >>>>>The wording needs to be amended to cover the
> > >>
> > >>cases
> > >
> > > === message truncated ===
> > >
> > >
> > > =====
> > > Kushanava Laha
> > > Hughes Software Systems
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > The New Yahoo! Shopping - with improved product search
> > > http://shopping.yahoo.com
> > >
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>  https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco


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



From megaco-admin@ietf.org  Mon Dec 29 04:38:32 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21973
	for <megaco-archive@lists.ietf.org>; Mon, 29 Dec 2003 04:38:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aatqd-0004CQ-51; Mon, 29 Dec 2003 04:38:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AatqP-0004BH-LJ
	for megaco@optimus.ietf.org; Mon, 29 Dec 2003 04:37:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21952
	for <megaco@ietf.org>; Mon, 29 Dec 2003 04:37:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AatqM-0007Jo-00
	for megaco@ietf.org; Mon, 29 Dec 2003 04:37:46 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AatoU-0007Hy-00
	for megaco@ietf.org; Mon, 29 Dec 2003 04:35:50 -0500
Received: from [81.1.223.5] (helo=itsib.ru)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AatnE-0007Gh-00
	for megaco@ietf.org; Mon, 29 Dec 2003 04:34:32 -0500
Received: from denis_hd ([10.0.0.120])
	by itsib.ru (8.11.6/8.11.6) with ESMTP id hBT9bRV14522
	for <megaco@ietf.org>; Mon, 29 Dec 2003 15:37:27 +0600
Date: Mon, 29 Dec 2003 15:34:38 +0600
From: =?koi8-r?B?5MXOydMg79PBxN7Jyg==?= <osadchy@itsib.ru>
X-Mailer: The Bat! (v1.51) UNREG / CD5BF9353B3B7091
Reply-To: =?koi8-r?B?5MXOydMg79PBxN7Jyg==?= <osadchy@itsib.ru>
X-Priority: 3 (Normal)
Message-ID: <167273185906.20031229153438@itsib.ru>
To: megaco@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
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: 8bit
Subject: [Megaco] ServiceChange question
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 8bit

Hi, all!
I have a question:
is it possible to receive from MGC transaction which contain
ServiceChange command for RootTermination and other commands,
addressed for terminations?
  

Denis



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


From exim@www1.ietf.org  Mon Dec 29 04:42:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22100
	for <megaco-archive@odin.ietf.org>; Mon, 29 Dec 2003 04:42:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AatuI-0004Xn-Jt
	for megaco-archive@odin.ietf.org; Mon, 29 Dec 2003 04:41:50 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBT9fo7v017461
	for megaco-archive@odin.ietf.org; Mon, 29 Dec 2003 04:41:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AatuI-0004XY-6d
	for megaco-web-archive@optimus.ietf.org; Mon, 29 Dec 2003 04:41:50 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22069
	for <megaco-web-archive@ietf.org>; Mon, 29 Dec 2003 04:41:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AatuF-0007QG-00
	for megaco-web-archive@ietf.org; Mon, 29 Dec 2003 04:41:47 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AatsQ-0007OH-00
	for megaco-web-archive@ietf.org; Mon, 29 Dec 2003 04:39:55 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aatqc-0007M7-00
	for megaco-web-archive@ietf.org; Mon, 29 Dec 2003 04:38:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aatqd-0004CQ-51; Mon, 29 Dec 2003 04:38:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AatqP-0004BH-LJ
	for megaco@optimus.ietf.org; Mon, 29 Dec 2003 04:37:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21952
	for <megaco@ietf.org>; Mon, 29 Dec 2003 04:37:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AatqM-0007Jo-00
	for megaco@ietf.org; Mon, 29 Dec 2003 04:37:46 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AatoU-0007Hy-00
	for megaco@ietf.org; Mon, 29 Dec 2003 04:35:50 -0500
Received: from [81.1.223.5] (helo=itsib.ru)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AatnE-0007Gh-00
	for megaco@ietf.org; Mon, 29 Dec 2003 04:34:32 -0500
Received: from denis_hd ([10.0.0.120])
	by itsib.ru (8.11.6/8.11.6) with ESMTP id hBT9bRV14522
	for <megaco@ietf.org>; Mon, 29 Dec 2003 15:37:27 +0600
Date: Mon, 29 Dec 2003 15:34:38 +0600
From: =?koi8-r?B?5MXOydMg79PBxN7Jyg==?= <osadchy@itsib.ru>
X-Mailer: The Bat! (v1.51) UNREG / CD5BF9353B3B7091
Reply-To: =?koi8-r?B?5MXOydMg79PBxN7Jyg==?= <osadchy@itsib.ru>
X-Priority: 3 (Normal)
Message-ID: <167273185906.20031229153438@itsib.ru>
To: megaco@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [Megaco] ServiceChange question
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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: 8bit
Content-Transfer-Encoding: 8bit

Hi, all!
I have a question:
is it possible to receive from MGC transaction which contain
ServiceChange command for RootTermination and other commands,
addressed for terminations?
  

Denis



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



From megaco-admin@ietf.org  Tue Dec 30 15:57:42 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08543
	for <megaco-archive@lists.ietf.org>; Tue, 30 Dec 2003 15:57:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQvF-0004Xx-OD; Tue, 30 Dec 2003 15:57:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQul-0004Ww-F9
	for megaco@optimus.ietf.org; Tue, 30 Dec 2003 15:56:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08493
	for <megaco@ietf.org>; Tue, 30 Dec 2003 15:56:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQuj-0007fN-00
	for megaco@ietf.org; Tue, 30 Dec 2003 15:56:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbQss-0007cd-00
	for megaco@ietf.org; Tue, 30 Dec 2003 15:54:35 -0500
Received: from [65.198.40.5] (helo=mails.conexion.com.py)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQrc-0007Zk-00
	for megaco@ietf.org; Tue, 30 Dec 2003 15:53:17 -0500
Received: from carlos ([65.198.40.11])
	by mails.conexion.com.py (8.12.8/8.12.8) with SMTP id hBUKuKnn031722
	for <megaco@ietf.org>; Tue, 30 Dec 2003 17:56:21 -0300
Message-ID: <002e01c3cef6$c7b37750$6600a8c0@carlos>
From: =?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?= <crav@conexion.com.py>
To: <megaco@ietf.org>
Date: Tue, 30 Dec 2003 17:59:43 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0023_01C3CEFE.B4323470"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300
X-ConeXion-MailScanner-Information: Please contact the ISP for more information
X-ConeXion-MailScanner: Found to be clean
X-ConeXion-MailScanner-SpamCheck: no es spam, SpamAssassin (puntuación=1,
	requerido 4, SPAM_PHRASE_00_01 0.78, USER_AGENT_OE 0.18)
X-ConeXion-MailScanner-SpamScore: s
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,DATE_IN_PAST_03_06,
	HTML_30_40,HTML_MESSAGE autolearn=no version=2.60
Subject: [Megaco] embed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01C3CEFE.B4323470
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

We have the next megaco transaction:

Step 1
MGC to RGW:
   MEGACO/1 [216.33.33.61]:27000
   Transaction =3D 1234 {
       Context =3D - {
           Modify =3D TermA {
               Media {
                        LocalControl {
                            Mode =3D Receiveonly}
                        },
               DigitMap=3D Dmap1 {(2XXX)}
               Events =3D 1111 {
                    al/of Embed {signals {cg/dt},
                    Events=3D1112 {al/on},
                    {dd/ce {Dmap1}}}
           }
       }
   }

Can "signals" be an "Embed"'s parameter.

In Megaco structure we have:

RequestedActions
{
  keepActive
  eventDM
  secondEvent
  signalDescriptor
  ...
}

In this point 'secondEvent' (Embed) and 'signalDescriptor' (Signal) are =
in
the same level.
But, following 'secondEvent', we have:

SecondEventDescriptor
{
  requestID
  eventList
}

there is no 'signalDescriptor' in this structure. So, is the Transaction
showed in the RFC wrong?

The event 1112 has only 'al/on', so, who does own the parameter
'dd/ce{Dmap1}'?  Are the parentesis wrong?

Thanks in advance.



------=_NextPart_000_0023_01C3CEFE.B4323470
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.2734.1600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>We have the next megaco transaction:<BR><BR>Step 1<BR>MGC to=20
RGW:<BR>&nbsp;&nbsp; MEGACO/1 [216.33.33.61]:27000<BR>&nbsp;&nbsp; =
Transaction =3D=20
1234 {<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Context =3D -=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Modify =
=3D TermA=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
Media=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
LocalControl=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
Mode =3D=20
Receiveonly}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
},<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
DigitMap=3D Dmap1=20
{(2XXX)}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
Events =3D 1111=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
al/of Embed {signals=20
{cg/dt},<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Events=3D1112=20
{al/on},<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
{dd/ce =
{Dmap1}}}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<BR>&nbsp;&nbsp; }<BR><BR>Can =

"signals" be an "Embed"'s parameter.<BR><BR>In Megaco structure we=20
have:<BR><BR>RequestedActions<BR>{<BR>&nbsp; keepActive<BR>&nbsp;=20
eventDM<BR>&nbsp; secondEvent<BR>&nbsp; signalDescriptor<BR>&nbsp;=20
...<BR>}<BR><BR>In this point 'secondEvent' (Embed) and =
'signalDescriptor'=20
(Signal) are in<BR>the same level.<BR>But, following 'secondEvent', we=20
have:<BR><BR>SecondEventDescriptor<BR>{<BR>&nbsp; requestID<BR>&nbsp;=20
eventList<BR>}<BR><BR>there is no 'signalDescriptor' in this structure. =
So, is=20
the Transaction<BR>showed in the RFC wrong?<BR><BR>The event 1112 has =
only=20
'al/on', so, who does own the parameter<BR>'dd/ce{Dmap1}'?&nbsp; Are the =

parentesis wrong?<BR><BR>Thanks in advance.<BR><BR></DIV></BODY></HTML>

------=_NextPart_000_0023_01C3CEFE.B4323470--


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


From exim@www1.ietf.org  Tue Dec 30 16:01:00 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08673
	for <megaco-archive@odin.ietf.org>; Tue, 30 Dec 2003 16:01:00 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQyd-0004yd-25
	for megaco-archive@odin.ietf.org; Tue, 30 Dec 2003 16:00:32 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBUL0VeU019130
	for megaco-archive@odin.ietf.org; Tue, 30 Dec 2003 16:00:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQyc-0004yT-TM
	for megaco-web-archive@optimus.ietf.org; Tue, 30 Dec 2003 16:00:30 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08644
	for <megaco-web-archive@ietf.org>; Tue, 30 Dec 2003 16:00:28 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQyb-0007nQ-00
	for megaco-web-archive@ietf.org; Tue, 30 Dec 2003 16:00:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbQwj-0007jz-00
	for megaco-web-archive@ietf.org; Tue, 30 Dec 2003 15:58:34 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQvR-0007hI-00
	for megaco-web-archive@ietf.org; Tue, 30 Dec 2003 15:57:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQvF-0004Xx-OD; Tue, 30 Dec 2003 15:57:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbQul-0004Ww-F9
	for megaco@optimus.ietf.org; Tue, 30 Dec 2003 15:56:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08493
	for <megaco@ietf.org>; Tue, 30 Dec 2003 15:56:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQuj-0007fN-00
	for megaco@ietf.org; Tue, 30 Dec 2003 15:56:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbQss-0007cd-00
	for megaco@ietf.org; Tue, 30 Dec 2003 15:54:35 -0500
Received: from [65.198.40.5] (helo=mails.conexion.com.py)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbQrc-0007Zk-00
	for megaco@ietf.org; Tue, 30 Dec 2003 15:53:17 -0500
Received: from carlos ([65.198.40.11])
	by mails.conexion.com.py (8.12.8/8.12.8) with SMTP id hBUKuKnn031722
	for <megaco@ietf.org>; Tue, 30 Dec 2003 17:56:21 -0300
Message-ID: <002e01c3cef6$c7b37750$6600a8c0@carlos>
From: =?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?= <crav@conexion.com.py>
To: <megaco@ietf.org>
Date: Tue, 30 Dec 2003 17:59:43 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0023_01C3CEFE.B4323470"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300
X-ConeXion-MailScanner-Information: Please contact the ISP for more information
X-ConeXion-MailScanner: Found to be clean
X-ConeXion-MailScanner-SpamCheck: no es spam, SpamAssassin (puntuación=1,
	requerido 4, SPAM_PHRASE_00_01 0.78, USER_AGENT_OE 0.18)
X-ConeXion-MailScanner-SpamScore: s
Subject: [Megaco] embed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,DATE_IN_PAST_03_06,
	HTML_30_40,HTML_MESSAGE autolearn=no version=2.60

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01C3CEFE.B4323470
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

We have the next megaco transaction:

Step 1
MGC to RGW:
   MEGACO/1 [216.33.33.61]:27000
   Transaction =3D 1234 {
       Context =3D - {
           Modify =3D TermA {
               Media {
                        LocalControl {
                            Mode =3D Receiveonly}
                        },
               DigitMap=3D Dmap1 {(2XXX)}
               Events =3D 1111 {
                    al/of Embed {signals {cg/dt},
                    Events=3D1112 {al/on},
                    {dd/ce {Dmap1}}}
           }
       }
   }

Can "signals" be an "Embed"'s parameter.

In Megaco structure we have:

RequestedActions
{
  keepActive
  eventDM
  secondEvent
  signalDescriptor
  ...
}

In this point 'secondEvent' (Embed) and 'signalDescriptor' (Signal) are =
in
the same level.
But, following 'secondEvent', we have:

SecondEventDescriptor
{
  requestID
  eventList
}

there is no 'signalDescriptor' in this structure. So, is the Transaction
showed in the RFC wrong?

The event 1112 has only 'al/on', so, who does own the parameter
'dd/ce{Dmap1}'?  Are the parentesis wrong?

Thanks in advance.



------=_NextPart_000_0023_01C3CEFE.B4323470
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.2734.1600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>We have the next megaco transaction:<BR><BR>Step 1<BR>MGC to=20
RGW:<BR>&nbsp;&nbsp; MEGACO/1 [216.33.33.61]:27000<BR>&nbsp;&nbsp; =
Transaction =3D=20
1234 {<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Context =3D -=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Modify =
=3D TermA=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
Media=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
LocalControl=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
Mode =3D=20
Receiveonly}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
},<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
DigitMap=3D Dmap1=20
{(2XXX)}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
Events =3D 1111=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
al/of Embed {signals=20
{cg/dt},<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Events=3D1112=20
{al/on},<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
{dd/ce =
{Dmap1}}}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<BR>&nbsp;&nbsp; }<BR><BR>Can =

"signals" be an "Embed"'s parameter.<BR><BR>In Megaco structure we=20
have:<BR><BR>RequestedActions<BR>{<BR>&nbsp; keepActive<BR>&nbsp;=20
eventDM<BR>&nbsp; secondEvent<BR>&nbsp; signalDescriptor<BR>&nbsp;=20
...<BR>}<BR><BR>In this point 'secondEvent' (Embed) and =
'signalDescriptor'=20
(Signal) are in<BR>the same level.<BR>But, following 'secondEvent', we=20
have:<BR><BR>SecondEventDescriptor<BR>{<BR>&nbsp; requestID<BR>&nbsp;=20
eventList<BR>}<BR><BR>there is no 'signalDescriptor' in this structure. =
So, is=20
the Transaction<BR>showed in the RFC wrong?<BR><BR>The event 1112 has =
only=20
'al/on', so, who does own the parameter<BR>'dd/ce{Dmap1}'?&nbsp; Are the =

parentesis wrong?<BR><BR>Thanks in advance.<BR><BR></DIV></BODY></HTML>

------=_NextPart_000_0023_01C3CEFE.B4323470--


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



From megaco-admin@ietf.org  Tue Dec 30 21:17:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24132
	for <megaco-archive@lists.ietf.org>; Tue, 30 Dec 2003 21:17:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbVuv-0007rB-O0; Tue, 30 Dec 2003 21:17:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbVua-0007pV-NF
	for megaco@optimus.ietf.org; Tue, 30 Dec 2003 21:16:40 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24124
	for <megaco@ietf.org>; Tue, 30 Dec 2003 21:16:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbVuX-0003hj-00
	for megaco@ietf.org; Tue, 30 Dec 2003 21:16:37 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbVsf-0003fx-00
	for megaco@ietf.org; Tue, 30 Dec 2003 21:14:42 -0500
Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbVrd-0003cV-00
	for megaco@ietf.org; Tue, 30 Dec 2003 21:13:37 -0500
Received: from l12381 (huawei.com [172.17.1.60])
 by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14
 2003)) with ESMTPA id <0HQQ00MIMLSRGU@mta1.huawei.com> for megaco@ietf.org;
 Wed, 31 Dec 2003 10:05:16 +0800 (CST)
Date: Wed, 31 Dec 2003 10:14:26 +0800
From: lihu <l12381@huawei.com>
To: megaco@ietf.org
Message-id: <001701c3cf43$d45c8ee0$e0486e0a@huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
Content-type: multipart/alternative;
 boundary="Boundary_(ID_WkuJiqJLIUYq+7/sMOgqTQ)"
X-Priority: 3
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=2.1 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS,
	HTML_20_30,HTML_FONT_FACE_BAD,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR 
	autolearn=no version=2.60
Subject: [Megaco] Fw: how to nodify MGC when MG's resource is error during conversation
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>

This is a multi-part message in MIME format.

--Boundary_(ID_WkuJiqJLIUYq+7/sMOgqTQ)
Content-type: text/plain; charset=Windows-1252
Content-Transfer-Encoding: 7BIT


----- Original Message ----- 
From: lihu 
To: megaco@ietf.org 
Sent: Tuesday, December 30, 2003 5:42 PM
Subject: how to nodify MGC when MG's resource is error during conversation


hi,all,
    Does anyone know how to deal with the below situation?
In MGW,there are echo cancel(EC) ,transcoder(TC) and other resource.If EC/TC is error during conversation,how to notify MGC ? If ServiceChange is used,which reason
is used? Has it any other method to notify MGC ?

Best Regards


LiHu
Huawei co.,Ltd.
86-10-82882747

*****************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
*****************************************************************

--Boundary_(ID_WkuJiqJLIUYq+7/sMOgqTQ)
Content-type: text/html; charset=Windows-1252
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 5.50.4933.1800" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=&#23435;&#20307; size=2></FONT>&nbsp;</DIV>
<DIV style="FONT: 9pt &#23435;&#20307;">----- Original Message ----- 
<DIV style="BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A 
title=l12381@huawei.com href="mailto:l12381@huawei.com">lihu</A> </DIV>
<DIV><B>To:</B> <A title=megaco@ietf.org 
href="mailto:megaco@ietf.org">megaco@ietf.org</A> </DIV>
<DIV><B>Sent:</B> Tuesday, December 30, 2003 5:42 PM</DIV>
<DIV><B>Subject:</B> how to nodify MGC when MG's resource is error during 
conversation</DIV></DIV>
<DIV><BR></DIV>
<DIV><FONT size=2>hi,all,</FONT></DIV>
<DIV><FONT size=2>&nbsp;&nbsp;&nbsp; Does anyone know how to deal with the below 
situation?</FONT></DIV>
<DIV><FONT size=2>In MGW,there are echo cancel(EC) ,transcoder(TC) and other 
resource.If EC/TC is error during conversation,how to notify MGC ? If 
ServiceChange is used,which reason</FONT></DIV>
<DIV><FONT size=2>is used? Has it any other method to notify MGC ?</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Best Regards</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>LiHu<BR>Huawei co.,Ltd.<BR>86-10-82882747</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT 
size=2>*****************************************************************<BR>This 
e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use 
of the information contained herein in any way (including, but not limited to, 
total or partial disclosure, reproduction, or dissemination) by persons other 
than the intended recipient(s) is prohibited. If you receive this e-mail in 
error, please notify the sender by phone or email immediately and delete 
it!<BR>*****************************************************************<BR></FONT></DIV></BODY></HTML>

--Boundary_(ID_WkuJiqJLIUYq+7/sMOgqTQ)--

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


From exim@www1.ietf.org  Tue Dec 30 21:21:13 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24236
	for <megaco-archive@odin.ietf.org>; Tue, 30 Dec 2003 21:21:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbVyV-0007zG-0w
	for megaco-archive@odin.ietf.org; Tue, 30 Dec 2003 21:20:46 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBV2KhM5030703
	for megaco-archive@odin.ietf.org; Tue, 30 Dec 2003 21:20:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbVyU-0007z8-S8
	for megaco-web-archive@optimus.ietf.org; Tue, 30 Dec 2003 21:20:42 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24224
	for <megaco-web-archive@ietf.org>; Tue, 30 Dec 2003 21:20:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbVyS-0003rh-00
	for megaco-web-archive@ietf.org; Tue, 30 Dec 2003 21:20:40 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbVwc-0003nX-00
	for megaco-web-archive@ietf.org; Tue, 30 Dec 2003 21:18:47 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbVuv-0003jh-00
	for megaco-web-archive@ietf.org; Tue, 30 Dec 2003 21:17:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbVuv-0007rB-O0; Tue, 30 Dec 2003 21:17:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbVua-0007pV-NF
	for megaco@optimus.ietf.org; Tue, 30 Dec 2003 21:16:40 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24124
	for <megaco@ietf.org>; Tue, 30 Dec 2003 21:16:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbVuX-0003hj-00
	for megaco@ietf.org; Tue, 30 Dec 2003 21:16:37 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbVsf-0003fx-00
	for megaco@ietf.org; Tue, 30 Dec 2003 21:14:42 -0500
Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbVrd-0003cV-00
	for megaco@ietf.org; Tue, 30 Dec 2003 21:13:37 -0500
Received: from l12381 (huawei.com [172.17.1.60])
 by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14
 2003)) with ESMTPA id <0HQQ00MIMLSRGU@mta1.huawei.com> for megaco@ietf.org;
 Wed, 31 Dec 2003 10:05:16 +0800 (CST)
Date: Wed, 31 Dec 2003 10:14:26 +0800
From: lihu <l12381@huawei.com>
To: megaco@ietf.org
Message-id: <001701c3cf43$d45c8ee0$e0486e0a@huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
Content-type: multipart/alternative;
 boundary="Boundary_(ID_WkuJiqJLIUYq+7/sMOgqTQ)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [Megaco] Fw: how to nodify MGC when MG's resource is error during conversation
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=2.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS,
	HTML_20_30,HTML_FONT_FACE_BAD,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR 
	autolearn=no version=2.60

This is a multi-part message in MIME format.

--Boundary_(ID_WkuJiqJLIUYq+7/sMOgqTQ)
Content-type: text/plain; charset=Windows-1252
Content-Transfer-Encoding: 7BIT


----- Original Message ----- 
From: lihu 
To: megaco@ietf.org 
Sent: Tuesday, December 30, 2003 5:42 PM
Subject: how to nodify MGC when MG's resource is error during conversation


hi,all,
    Does anyone know how to deal with the below situation?
In MGW,there are echo cancel(EC) ,transcoder(TC) and other resource.If EC/TC is error during conversation,how to notify MGC ? If ServiceChange is used,which reason
is used? Has it any other method to notify MGC ?

Best Regards


LiHu
Huawei co.,Ltd.
86-10-82882747

*****************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
*****************************************************************

--Boundary_(ID_WkuJiqJLIUYq+7/sMOgqTQ)
Content-type: text/html; charset=Windows-1252
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 5.50.4933.1800" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=&#23435;&#20307; size=2></FONT>&nbsp;</DIV>
<DIV style="FONT: 9pt &#23435;&#20307;">----- Original Message ----- 
<DIV style="BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A 
title=l12381@huawei.com href="mailto:l12381@huawei.com">lihu</A> </DIV>
<DIV><B>To:</B> <A title=megaco@ietf.org 
href="mailto:megaco@ietf.org">megaco@ietf.org</A> </DIV>
<DIV><B>Sent:</B> Tuesday, December 30, 2003 5:42 PM</DIV>
<DIV><B>Subject:</B> how to nodify MGC when MG's resource is error during 
conversation</DIV></DIV>
<DIV><BR></DIV>
<DIV><FONT size=2>hi,all,</FONT></DIV>
<DIV><FONT size=2>&nbsp;&nbsp;&nbsp; Does anyone know how to deal with the below 
situation?</FONT></DIV>
<DIV><FONT size=2>In MGW,there are echo cancel(EC) ,transcoder(TC) and other 
resource.If EC/TC is error during conversation,how to notify MGC ? If 
ServiceChange is used,which reason</FONT></DIV>
<DIV><FONT size=2>is used? Has it any other method to notify MGC ?</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Best Regards</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>LiHu<BR>Huawei co.,Ltd.<BR>86-10-82882747</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT 
size=2>*****************************************************************<BR>This 
e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use 
of the information contained herein in any way (including, but not limited to, 
total or partial disclosure, reproduction, or dissemination) by persons other 
than the intended recipient(s) is prohibited. If you receive this e-mail in 
error, please notify the sender by phone or email immediately and delete 
it!<BR>*****************************************************************<BR></FONT></DIV></BODY></HTML>

--Boundary_(ID_WkuJiqJLIUYq+7/sMOgqTQ)--

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



From megaco-admin@ietf.org  Wed Dec 31 00:59:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29710
	for <megaco-archive@lists.ietf.org>; Wed, 31 Dec 2003 00:59:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbZNl-0005mL-Fq; Wed, 31 Dec 2003 00:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbZNU-0005lX-Ob
	for megaco@optimus.ietf.org; Wed, 31 Dec 2003 00:58:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29706
	for <megaco@ietf.org>; Wed, 31 Dec 2003 00:58:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbZNR-0002l5-00
	for megaco@ietf.org; Wed, 31 Dec 2003 00:58:41 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbZLa-0002iF-00
	for megaco@ietf.org; Wed, 31 Dec 2003 00:56:47 -0500
Received: from nwd2mail1.analog.com ([137.71.25.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbZKZ-0002ex-00
	for megaco@ietf.org; Wed, 31 Dec 2003 00:55:43 -0500
Received: from nwd2mhb1.analog.com (nwd2mhb1.analog.com [137.71.5.12])
	by nwd2mail1.analog.com (8.12.10/8.12.10) with ESMTP id hBV5tqeZ013346
	for <megaco@ietf.org>; Wed, 31 Dec 2003 00:55:52 -0500
Received: from jasmine.cpgindia.analog.com ([137.71.32.30])
	by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id AAA01673
	for <megaco@ietf.org>; Wed, 31 Dec 2003 00:55:36 -0500 (EST)
Received: from kumard02 ([137.71.32.241])
	by jasmine.cpgindia.analog.com (8.9.1/8.9.1) with SMTP id LAA24037
	for <megaco@ietf.org>; Wed, 31 Dec 2003 11:35:24 +0530 (IST)
From: "Kumar" <kumaraswamy.uppu@analog.com>
To: <megaco@ietf.org>
Date: Wed, 31 Dec 2003 11:36:14 +0530
Message-ID: <KDEKIIFNFCDINCIDOFNMKECGCCAA.kumaraswamy.uppu@analog.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.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
X-Scanned-By: MIMEDefang 2.38
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] How to differentiate Ephemeral and Physical Termination
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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-Transfer-Encoding: 7bit

Hi All,

    I have a question about termination ids.

    1. Is it OK to send add req with termination id as CHOOSE for physical
termination ? In general we get CHOOSE to add RTP termination .If so, on MG
side, how can I differentiate between Ephemeral (RTP) termination and
physical termination ?

Thanks & Regards,
Kumar




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


From exim@www1.ietf.org  Wed Dec 31 01:03:08 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29850
	for <megaco-archive@odin.ietf.org>; Wed, 31 Dec 2003 01:03:08 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbZRG-0005vU-TK
	for megaco-archive@odin.ietf.org; Wed, 31 Dec 2003 01:02:39 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBV62cbG022780
	for megaco-archive@odin.ietf.org; Wed, 31 Dec 2003 01:02:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbZRG-0005vK-Ms
	for megaco-web-archive@optimus.ietf.org; Wed, 31 Dec 2003 01:02:38 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29821
	for <megaco-web-archive@ietf.org>; Wed, 31 Dec 2003 01:02:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbZRD-0002tK-00
	for megaco-web-archive@ietf.org; Wed, 31 Dec 2003 01:02:35 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbZPP-0002q3-00
	for megaco-web-archive@ietf.org; Wed, 31 Dec 2003 01:00:44 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbZNl-0002md-00
	for megaco-web-archive@ietf.org; Wed, 31 Dec 2003 00:59:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbZNl-0005mL-Fq; Wed, 31 Dec 2003 00:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbZNU-0005lX-Ob
	for megaco@optimus.ietf.org; Wed, 31 Dec 2003 00:58:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29706
	for <megaco@ietf.org>; Wed, 31 Dec 2003 00:58:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbZNR-0002l5-00
	for megaco@ietf.org; Wed, 31 Dec 2003 00:58:41 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbZLa-0002iF-00
	for megaco@ietf.org; Wed, 31 Dec 2003 00:56:47 -0500
Received: from nwd2mail1.analog.com ([137.71.25.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbZKZ-0002ex-00
	for megaco@ietf.org; Wed, 31 Dec 2003 00:55:43 -0500
Received: from nwd2mhb1.analog.com (nwd2mhb1.analog.com [137.71.5.12])
	by nwd2mail1.analog.com (8.12.10/8.12.10) with ESMTP id hBV5tqeZ013346
	for <megaco@ietf.org>; Wed, 31 Dec 2003 00:55:52 -0500
Received: from jasmine.cpgindia.analog.com ([137.71.32.30])
	by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id AAA01673
	for <megaco@ietf.org>; Wed, 31 Dec 2003 00:55:36 -0500 (EST)
Received: from kumard02 ([137.71.32.241])
	by jasmine.cpgindia.analog.com (8.9.1/8.9.1) with SMTP id LAA24037
	for <megaco@ietf.org>; Wed, 31 Dec 2003 11:35:24 +0530 (IST)
From: "Kumar" <kumaraswamy.uppu@analog.com>
To: <megaco@ietf.org>
Date: Wed, 31 Dec 2003 11:36:14 +0530
Message-ID: <KDEKIIFNFCDINCIDOFNMKECGCCAA.kumaraswamy.uppu@analog.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.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
X-Scanned-By: MIMEDefang 2.38
Content-Transfer-Encoding: 7bit
Subject: [Megaco] How to differentiate Ephemeral and Physical Termination
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
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>
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
Content-Transfer-Encoding: 7bit

Hi All,

    I have a question about termination ids.

    1. Is it OK to send add req with termination id as CHOOSE for physical
termination ? In general we get CHOOSE to add RTP termination .If so, on MG
side, how can I differentiate between Ephemeral (RTP) termination and
physical termination ?

Thanks & Regards,
Kumar




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