From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  1 11:41:25 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26076
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 1 Jun 2000 11:41:25 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.069C7E80@standards.nortelnetworks.com>; Thu, 1 Jun 2000 11:32:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1301 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 1 Jun 2000 11:30:52 -0400
Received: from qhars002.nortel.com (47.101.112.102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.D7CD7640@standards.nortelnetworks.com>; Thu, 1 Jun 2000
          11:30:52 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Thu, 1 Jun 2000 16:36:30 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Thu, 1 Jun 2000 11:30:14 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <L3HQAKA0>; Thu, 1 Jun 2000 11:30:14 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1103858541@zcard00g.ca.nortel.com>
Date:         Thu, 1 Jun 2000 11:28:20 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Messages Not Delivered To The Megaco List
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The foolowing messages are in the Megaco archives at
http://standards.nortelnetworks.com/archives/megaco.html
but have not been delivered to the list due to configuration problems on the
server.  I apologize for the inconvenience.  The list is operating normally
for the moment.


116.Redundant MG implementation issue (43 lines)
From: Pavitra Krishnaswamy <pavitra@TRILLIUM.COM>
Date: Tue, 25 May 0100 17:56:46 -0700

117.TCP Transport and ServiceChange Address (54 lines)
From: Bharat Kaul <bharat@TRILLIUM.COM>
Date: Thu, 25 May 2000 18:28:10 -0700

118.Conflicting information in section 11.5 & section D.1.5 (77 lines)
From: Pavitra Krishnaswamy <pavitra@TRILLIUM.COM>
Date: Tue, 25 May 0100 18:47:46 -0700

119.Re: Redundant MG implementation issue (58 lines)
From: Rosen, Brian <Brian.Rosen@MARCONI.COM>
Date: Fri, 26 May 2000 07:42:11 -0400

120.Re: Conflicting information in section 11.5 & section D.1.5 (106 lines)
From: Rosen, Brian <Brian.Rosen@MARCONI.COM>
Date: Fri, 26 May 2000 07:50:42 -0400

121.Text encoding (52 lines)
From: Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
Date: Fri, 26 May 2000 18:10:58 -0500

122.Re: Registering Package IDs with IANA (78 lines)
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Date: Fri, 26 May 2000 11:30:16 -0400

123.Re: Conflicting information in section 11.5 & section D.1.5 (fwd ) (123
lines)
From: Bharat Kaul <bharat@TRILLIUM.COM>
Date: Fri, 26 May 2000 11:26:42 -0700

124.FW: MEGACO errata (43 lines)
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Date: Fri, 26 May 2000 15:08:56 -0500

125.Re: FW: MEGACO errata (59 lines)
From: Chip Sharp <chsharp@CISCO.COM>
Date: Fri, 26 May 2000 17:22:14 -0400

126.Text encoding (63 lines)
From: Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
Date: Mon, 29 May 2000 10:19:32 -0500

127.Re: Text encoding (97 lines)
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Date: Mon, 29 May 2000 08:56:56 -0400

128.Re: TCP Transport /ServiceChange Command (100 lines)
From: Rosen, Brian <Brian.Rosen@MARCONI.COM>
Date: Tue, 30 May 2000 08:42:09 -0400

129.Interop Testing Co-Sponsor (25 lines)
From: Rosen, Brian <Brian.Rosen@MARCONI.COM>
Date: Tue, 30 May 2000 10:31:10 -0400

130.ALF/UDP (48 lines)
From: Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
Date: Wed, 31 May 2000 13:49:01 -0500

131.Protocol Action: MEGACO Protocol to Proposed Standard (56 lines)
From: The IESG <iesg-secretary@IETF.ORG>
Date: Wed, 31 May 2000 08:22:36 -0400

132.MEGACO gateway and call routing (41 lines)
From: Dimitris Terzis <D.Terzis@CS.UCL.AC.UK>
Date: Tue, 30 May 2000 14:19:35 +0100

133.Re: ATM Package for Megaco (312 lines)
From: Rosen, Brian <Brian.Rosen@MARCONI.COM>
Date: Wed, 31 May 2000 10:17:18 -0400

134.Megaco TerminationID and IUA Interface Identifier (55 lines)
From: Bouwen Jan <jan.bouwen@ALCATEL.BE>
Date: Wed, 31 May 2000 16:53:29 +0200

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  1 11:54:58 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26230
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 1 Jun 2000 11:54:57 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FDDEB900@standards.nortelnetworks.com>; Thu, 1 Jun 2000 11:46:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1323 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 1 Jun 2000 11:44:15 -0400
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.50535800@standards.nortelnetworks.com>; Thu, 1 Jun 2000
          11:34:14 -0400
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
          by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with
          ESMTP id e51FgKJ25417 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu,
          1 Jun 2000 17:42:20 +0200 (MET DST)
Received: from greymse1.lmf.ericsson.se (greymse1.lmf.ericsson.se
          [131.160.1.6]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with
          ESMTP id SAA28685 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 1
          Jun 2000 18:42:20 +0300 (EET DST)
Received: from localhost (root@localhost) by greymse1.lmf.ericsson.se (8.9.3
          (PHNE_18979)/8.8.6) with ESMTP id SAA00496 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 1 Jun 2000 18:42:19 +0300
          (EETDST)
X-OpenMail-Hops: 2
X-OpenMail-Autoreplied: TRUE
Encoding: 5 text
Message-ID:  <"AUTOANS-088cefb6.0959874138.greymse1.lmf.ericsson.se*"@MHS>
Date:         Thu, 1 Jun 2000 18:42:18 +0300
Reply-To: Miguel.A*A.Garcia@LMF.ERICSSON.SE
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Miguel.A*A.Garcia@LMF.ERICSSON.SE
Subject:      Auto Reply Message
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <C51ED84B6F47D211917A0000F8BCBD1103858541@zcard00g.ca.nortel.co>

I am on vacation until June 5th. If urgent, phone me at +358 40 514 0002

Regards,

           Miguel.A.Garcia@ericsson.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  1 14:18:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29137
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 1 Jun 2000 14:18:20 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FFB73270@standards.nortelnetworks.com>; Thu, 1 Jun 2000 14:09:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1447 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 1 Jun 2000 14:07:59 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.CACE9490@standards.nortelnetworks.com>; Thu, 1 Jun 2000 14:07:59
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id OAA19981 for <megaco@standards.nortelnetworks.com>; Thu, 1
          Jun 2000 14:16:04 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id OAA26204 for <megaco@standards.nortelnetworks.com>; Thu, 1
          Jun 2000 14:16:06 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <K07X5FS1>; Thu, 1 Jun 2000 14:16:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6783EB@whq-msgusr-02.fore.com>
Date:         Thu, 1 Jun 2000 14:16:02 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      FW: Interop Testing Co-Sponsor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is one of the messages that was never distributed by the listserv.

It's a little late, and in fact I have two discussions underway,
but if you are associated with a university that might be interested,
please get in touch with me right away!

Brian

-----Original Message-----
From: Rosen, Brian
Sent: Tuesday, May 30, 2000 10:31 AM
To: 'megaco@standards.nortelnetworks.com'
Subject: Interop Testing Co-Sponsor


For various reasons, I have wanted to enlist a North American
university to co-sponsor the first interoperability event.
So far, no luck (not even a reply to email!).  I have some
(indirect) offers of support from UK institutions.  I thought
I'd give it one more try.  If I don't enlist one, it's not
really important, but I need to get this finished this week!

If you, or someone you know, might be interested, please get
in touch with me.

Reminder: Discussions on the event occur on the
megaco-nterop@fore.com mail list.
To subscribe, send a message to majordomo@fore.com with the first line:
subscribe megaco-interop

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  1 14:22:25 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29257
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 1 Jun 2000 14:22:24 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8EFB11E0@standards.nortelnetworks.com>; Thu, 1 Jun 2000 14:13:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1446 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 1 Jun 2000 14:12:04 -0400
Received: from opera (168.191.24.145) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.F64EB560@standards.nortelnetworks.com>; Thu, 1 Jun 2000 14:02:03
          -0400
X-Sender: Opera5@veriomail.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3
X-MSMail-Priority: Normal
Message-ID:  <MEGACO%2000060114120406@STANDARDS.NORTELNETWORKS.COM>
Date:         Thu, 1 Jun 2000 14:03:32 -0500
Reply-To: Opera5@VERIOMAIL.COM
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Opera5@VERIOMAIL.COM
Subject:      Best New Trade Show Display by Opera Portables, Inc. adv
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Opera Portables, Inc. is offering "by invitation" visits to our web site.  Packed full of exciting projects and news, Opera is leading the industry with displays that are as much eye-popping as they are eye catching.

Winner of numerous industry awards, including Ernst & Young's Crescendo Award, Exhibitor Magazine's Best New Product, Forty Under 40 and Emerging 30, Opera Portables is a progressive young company with imagination and vision.

If you use displays, you really owe it to yourself to check out our stuff!   Go to http://3637331613/

Opera Portables, Inc.

All removes honored at http://3637331613/removes.htm


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 07:36:15 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28876
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 07:36:15 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.04FFEBA0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 7:27:34 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2119 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 07:25:54 -0400
Received: from bells.cs.ucl.ac.uk by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.63DEA460@standards.nortelnetworks.com>; Fri, 2 Jun 2000 7:15:54
          -0400
Received: from 213.108.12.43 by bells.cs.ucl.ac.uk with Internet SMTP id
          <g.20751-0@bells.cs.ucl.ac.uk>; Fri, 2 Jun 2000 12:23:54 +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 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Message-ID:  <00ac01bfcc85$18366d40$73046cd5@kallisto>
Date:         Fri, 2 Jun 2000 12:24:13 +0100
Reply-To: Dimitris Terzis <D.Terzis@CS.UCL.AC.UK>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Dimitris Terzis <D.Terzis@CS.UCL.AC.UK>
Subject:      Gateways and call routing
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi there...

After the short list breakdown and a number of e-mails with
Tom Taylor, relating to a previous message that was not
delivered, I am resorting to your patience for discussing a
not-so-core-technology issue that has been puzzling me after
reading the MEGACO and TRIP documents
(DISCLAIMER: Not a MEGACO/TRIP/H.323 expert).

My questions relate to the definition of a VoIP gateway,
and to how it is realised by MEGACO for call routing.

My current understanding is that, following the H.323
model, a VoIP gateway has three major functions:

(a) Signalling Gateway (SG), for connectivity to SCN

(b) Media Gateway (MG), for handling the media path

(c) Media Gateway Controller (MGC), for terminating
the SCN and IP signalling, translating between the two,
and managing the MG resources.

As Tom pointed out,

> This is consonant with the H.323 architectural framework
> within which SG 16 addressed Megaco/H.248.
> MG-MGC-SG are functional parts of an H.323 Gateway,
> and it is the MGC which does the H.245 signalling.

As I understand it, these three functions/entities can exist
in any number within the (potentially distributed) VoIP gateway,
with the restriction that each MG has a controlling MGC,
which also communicates with an SG for the SCN signalling
path. Also, as far as I understand, MEGACO only covers
the MGC-MG part.

Tom's comment on the above was:

> The starting point for discussion is the intention within
> our architecture for the MGC to be the source and
> destination of all call signalling.  The SG is just a mediation
> function, and the MG has a similar mediation role in the case
> of in-band signalling.

Given the previous, I have the following questions:

(a) Is there a central entity within a distributed VoIP gateway,
consisting of a number of SG's, MG's and MGC's, which
would serve as its "representative" to the outside world
(e.g., by advertising its capabilities to TRIP Location Servers),
so that the gateway could be visible as an integrated entity
by the outside world? Or an external mechanism would be
used to discover (how?) these capabilities?

Given that the MGC is (essentially) the Gateway Controller,
one would expect that it would do this job, but what happens
in the case of multiple MGC's? Is there any "leader" election
process defined/implied?

(b) What is the preferable internal capability discovery
for a VoIP gateway? There is, for instance, the MGC-MG
Resource Discovery mechanism that allows the MGC to
know of the media capabilities of the gateway, but what
happens with signalling?

(c) Where does a Signalling Server, and particularly
an IP one (e.g., a SIP Proxy) fit in this gateway model?
Is it part of an MGC?

(d) Is there any compelling reason why we should have
Signalling Gateways that are (essentially) SCN clients
(Signalling Processors), following the H.323 model,
and then need mechanisms like SIGTRAN (RFC 2719)
to communicate with the MGC?

Why wouldn't we want to move all the external signalling
functions to the SG (i.e., ask _it_ to do the translation
between SCN and IP signalling), and only use the
MGC as an internal management function, which also
collects and advertises the gateway capabilities to the
outside world?

From the definition of a SG in RFC's 2719 and 2805,
translation is one of the envisioned functions (at least
for some cases).

(e) Is the above model suitable for "pure IP" gateways?
What happens, for example, when we want to connect an
H.323 subnet to a SIP one? Or when we want to use only
the media resources of a gateway (e.g., its codecs) in the
middle of a call?

Thanks for your attention.

Regards,

Dimitris

---------------------------------------------------------------
    Dimitris Terzis
    PhD Candidate - Department of Computer Science, UCL
    E-Mail: D.Terzis@cs.ucl.ac.uk
    URL : http://www.cs.ucl.ac.uk/staff/D.Terzis/
---------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 08:30:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00442
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 08:30:19 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.935FF690@standards.nortelnetworks.com>; Fri, 2 Jun 2000 8:21:39 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2166 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 08:19:44 -0400
Received: from ctsincsisxia.DBSS.COM (202.54.64.137) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.4DD561A0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 8:19:42
          -0400
Received: from 162.44.9.80 by ctsincsisxia.DBSS.COM (InterScan E-Mail VirusWall
          NT); Fri, 02 Jun 2000 17:53:25 +0530
Received: from rnd.cts-corp.com (206.136.109.204 [206.136.109.204]) by
          ctsincsisxic.cts-corp.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2448.0) id MAHLCCJT; Fri, 2 Jun 2000 18:01:13
          +0530
Received: from 9a4-gnd ([206.136.109.229]) by rnd.cts-corp.com (8.9.3/8.8.7)
          with SMTP id SAA21675; Fri, 2 Jun 2000 18:03:47 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0068_01BFCCBC.715495F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Message-ID:  <006b01bfcce6$5a7d03b0$e56d88ce@9a4-gnd>
Date:         Fri, 2 Jun 2000 18:00:31 -0500
Reply-To: Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
Subject:      ordering of commands
X-To:         taylor@nortelnetworks.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0068_01BFCCBC.715495F0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello.

In section 9.1 of the MEGACO draft we say that the Subtract command can =
be sent anytime. What happens if the Subtract command  is executed bu =
the MG before the Add command on the samewas executed?
Does the MG return errorcode 400 : "Bad Request"?
What does it do with the Add command executed later ?

Thank-you.
Regards,
Sameer.


------=_NextPart_000_0068_01BFCCBC.715495F0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3612.1706"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hello.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>In section 9.1 of the MEGACO draft =
we say that=20
the Subtract command can be sent anytime. What happens if the Subtract=20
command&nbsp; is executed bu the MG before the Add command on the =
samewas=20
executed?</FONT></DIV>
<DIV><FONT size=3D2>Does the MG return errorcode 400 : &quot;Bad=20
Request&quot;?</FONT></DIV>
<DIV><FONT size=3D2>What does it do with the Add command executed later=20
?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Thank-you.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Regards,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Sameer.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0068_01BFCCBC.715495F0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 08:48:46 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00876
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 08:48:46 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.193A8E40@standards.nortelnetworks.com>; Fri, 2 Jun 2000 8:39:43 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2213 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 08:38:07 -0400
Received: from qhars002.nortel.com (47.101.112.102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E02CFED0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 8:38:07
          -0400
Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com;
          Fri, 2 Jun 2000 13:45:52 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Fri, 2 Jun 2000 07:32:12 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <LW2CBL8Y>; Fri, 2 Jun 2000 07:40:35 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD110385854B@zcard00g.ca.nortel.com>
Date:         Fri, 2 Jun 2000 07:40:43 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: H.248/BICC discussions
X-To:         Mark Watson <mwatson@nortelnetworks.com>,
              "Christian.Groves@ericsson.com" <Christian.Groves@ericsson.com>
X-cc:         Sophia Scoggins <scoggins@nortelnetworks.com>,
              megaco-interop@fore.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I have forwarded this note to the Megaco list because I believe there is a
fundamental point to be discussed on the nature of packages.  I have not
sent it to the SG 11 BICC list because that list is closed to non-members.
If someone thinks it is worth forwarding they are free to do so.

I have held the intent in my own mind that it should be possible within
packages to define properties that are realized within Local and Remote.
This would be consistent with Annex C usage and would also imply that
packages can specify additions to SDP detailed syntax.  If this is the
consensus view, then it won't be necessary to modify H.248 to accommodate
BICC.  Instead, Local and Remote would be stripped out at the MGC and
forwarded via the tunnel, in exact accordance with H.248 design intent.

> -----Original Message-----
> From: Watson, Mark [MAIFP:EP11-M:EXCH]
> Sent: Friday, June 02, 2000 8:03 AM
> To:   'Christian.Groves@ericsson.com'; 'tsg11bicc@ties.itu.int'
> Cc:   Scoggins, Sophia [NC1:3T18:EXCH]; megaco-interop@fore.com
> Subject:      RE: H.248/BICC discussions
>
> Christian, All,
>
> Before we get confused, let's remember that the Tunnelling mechanism, and
> the question of what is carried inside the Tunnell, are separate and
> independent issues.
>
> What I understand has been agreed is that we will work on a general
> purpose tunnelling mechanism in BICC for the purpose of transporting MG to
> MG information for Bearer Control.
>
> As Christian says, the tunnelling mechanism will not be specific to any
> bearer technology and could in principle be used in any cases where there
> is no need for any intermediate BCF-Rs in the bearer network to see the
> Bearer Control information.
>
> Personally, I think that there are some cases where Bearer Control
> Tunnelling *could* in principle be used, but where we should decide that
> it is not applicable. Specifically, I think that for those technologies
> supported by CS1, we should think carefully before introducing alternative
> ways of supporting the same thing. As an example, Bearer Control
> Tunnelling could be used to transport ATM UNI signalling between two GSNs,
> because there is no ATM switching between GSNs. However, I don't see any
> value in specifying this application of Bearer Control Tunnelling. This is
> at present my opinion. The meeting has not yet addressed this point in
> detail.
>
> Sophia's comments below referred also to the other Nortel contribution to
> Melbourne which discussed the way that H.248 presently transports the
> pieces of information which need to be exchanged between MGs for IP Bearer
> Control. The proposal was that in considering what may be placed inside
> the Tunnel for IP Bearer Control, we should consider the encodings already
> supported in H.248 such as SDP and Native Tags.
>
> If we followed this approach, then the BICC version of H.248 would carry
> the SDP information inside the Bearer Control Tunnelling package, rather
> than inside the present termination properties used for SDP. This would be
> a minor change, but with the important effect of clearly separating out
> the MG-MG information from the MG-MGC information in the protocol.
>
> What remain an open issues, are (i) whether any other information or
> wrapper needs to be carried with the SDP inside the tunnel, and (ii)where
> we specify the procedures relating to sending and receipt of tunnelled SDP
> information. These should probably be covered in the IP Bearer Control
> document produced by SG11.
>
> Comments ?
>
> Regards,
>
> Mark Watson
> Nortel Networks
>
>
>
> -----Original Message-----
> From: Scoggins, Sophia [NC1:3T18:EXCH]
> Sent: 01 June 2000 12:28
> To: megaco-interop@fore.com; Watson, Mark [MAIFP:EP11-M:EXCH]
> Subject: Re: Multiple MGC scenarios
>
>
> Christian,
>
>
> Nortel has separate contributions regarding this topic. One addressed
> the bearer information tunneling method (it was Mark's contribution).
> The other proposed using the H.248 Native Tags or SDP as the encoding
> mechanism (is was Mark and my contribution). Mark presented both at the
> Melbourne meeting. I didn't go.
>
>
> Mark,
>
> Would you please answer Christian's question? This mailing list is for
> H.248 Megaco Interop testing coming in Aug.
>
>
> Regards, Sophia
>
> Christian Groves wrote:
> >
> > G'Day Sophia,
> >
> > Is this decision in a meeting report somewhere?
> >
> > I was at the Melbourne meeting where this was discussed and it was
> > decided that the tunnel was a global mechanism to be used for IP and ATM
>
> > bearer establishment signalling. The tunnel accepted did not mention SDP
>
> > or H.248 Native tags, it was a simply a bucket to carry bearer
> > establishment signalling which otherwise would been signalled directly
> > between 2 peer BCFs (MGs).
> >
> > Regards, Christian
> >
> > Sophia Scoggins wrote:
> > >
> > > Christian,
> > >
> > > You are right. There is one Nortel Network submission particularly
> > > addressing tunneling H.248 parameters in SDP or H.248 native tag
> > > formats. This is, however, for IP parameters only (in the BICC/ISUP+
> CS2
> > > or capability Set 2). All the ATM parameters have been defined in BICC
>
> > > parameter field. In order to backward compatible, ITU-T SG11 has
> decided
> > > by majority not to change it or provide extension to carry additional
> > > ATM related information in the tunneling messages.
> > >
> > > Regards, Sophia
> > >
> > > Christian Groves wrote:
> > > >
> > > > G'Day Sophia,
> > > >
> > > > Just to clarify what SG11 accepted. It was the idea of tunnelling
> bearer
> > > > control messages across BICC and H.248, not to add H.248 parameters
> in
> > > > BICC messages.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Sophia Scoggins wrote:
> > > > >
> > > > > My understanding is that this interop testing event will have a
> single
> > > > > MGC to a MG or possibly extend to a single MGC to two MGs. There
> won't
> > > > > be multiple MGCs. The communications between MGC-MGC is outside of
> the
> > > > > Megaco protocols, and it is not included in this initial H.248
> interop
> > > > > testing. Gatekeepers are for IP phones. If a MG doesn't handle IP
> > > > > phones, gatekeepers are not needed.
> > > > >
> > > > > There are parameters from MG-MGC that are not included in the
> current
> > > > > MGC-MGC communication protocols, such as ISUP+ and SIP+. In my
> recent
> > > > > contribution to ITU-T, I have added extension to ISUP+ (now known
> as
> > > > > BICC) to pass H.248 native tags or SDP parameters. This
> contribution is
> > > > > accepted as an work item by the SG11. To see it to be included in
> the
> > > > > standard and implementation, it will take time. So, interop from
> H.248
> > > > > end-to-end through MGCs will take time to be reality.
> > > > >
> > > > > Regards, Sophia
> > > > >
> > > > > samittal@hss.hns.com wrote:
> > > > > >
> > > > > > In section 1.1.1 it is mentioned "The digit shall be
> provisionable.  In single
> > > > > > MGC test environments, the digit will normally be zero.  In
> multiple MGC
> > > > > > scenarios, the gateways are numbered from zero."
> > > > > >
> > > > > > Between multiple MGCs what kind of MGC-MGC interface will be
> used.
> > > > > > Is some MGC-MGC communication interface standaridised ???
> > > > > >
> > > > > > Is there a plan to include getekeepers in multiple MGC scenarios
> for the simple
> > > > > > tests included in the test document ???
> > > > > >
> > > > > > Sachin Mittal
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 08:48:49 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00879
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 08:48:46 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1948E620@standards.nortelnetworks.com>; Fri, 2 Jun 2000 8:39:43 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2218 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 08:38:48 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.F8285E80@standards.nortelnetworks.com>; Fri, 2 Jun 2000 8:38:47
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id IAA18676; Fri, 2 Jun 2000 08:46:54 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id IAA05362; Fri, 2 Jun 2000 08:46:57 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <K07X5X59>; Fri, 2 Jun 2000 08:46:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCC90.A1FB178C"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67840E@whq-msgusr-02.fore.com>
Date:         Fri, 2 Jun 2000 08:46:54 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: H.248/BICC discussions
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>,
              Mark Watson <mwatson@nortelnetworks.com>,
              "Christian.Groves@ericsson.com" <Christian.Groves@ericsson.com>
X-cc:         Sophia Scoggins <scoggins@nortelnetworks.com>,
              megaco-interop@fore.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Well, I'm having a problem with the idea that a package can extend SDP.

For one thing, that's a non-trivial change to the protocol document, as it
describes what
is in a package.  For another, SDP is described in a separate RFC and is
under
control of a different group.  For a third, the mechanism wouldn't work with
SIP (or really
MGCP).

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, June 02, 2000 8:41 AM
To: Mark Watson; 'Christian.Groves@ericsson.com'
Cc: Sophia Scoggins; megaco-interop@fore.com;
megaco@standards.nortelnetworks.com
Subject: RE: H.248/BICC discussions



I have forwarded this note to the Megaco list because I believe there is a
fundamental point to be discussed on the nature of packages.  I have not
sent it to the SG 11 BICC list because that list is closed to non-members.
If someone thinks it is worth forwarding they are free to do so.

I have held the intent in my own mind that it should be possible within
packages to define properties that are realized within Local and Remote.
This would be consistent with Annex C usage and would also imply that
packages can specify additions to SDP detailed syntax.  If this is the
consensus view, then it won't be necessary to modify H.248 to accommodate
BICC.  Instead, Local and Remote would be stripped out at the MGC and
forwarded via the tunnel, in exact accordance with H.248 design intent.

        -----Original Message-----
From:   Watson, Mark [MAIFP:EP11-M:EXCH]
Sent:   Friday, June 02, 2000 8:03 AM
To:     'Christian.Groves@ericsson.com'; 'tsg11bicc@ties.itu.int'
Cc:     Scoggins, Sophia [NC1:3T18:EXCH]; megaco-interop@fore.com
Subject:        RE: H.248/BICC discussions

        Christian, All,

        Before we get confused, let's remember that the Tunnelling
mechanism, and the question of what is carried inside the Tunnell, are
separate and independent issues.

        What I understand has been agreed is that we will work on a general
purpose tunnelling mechanism in BICC for the purpose of transporting MG to
MG information for Bearer Control.

        As Christian says, the tunnelling mechanism will not be specific to
any bearer technology and could in principle be used in any cases where
there is no need for any intermediate BCF-Rs in the bearer network to see
the Bearer Control information.

        Personally, I think that there are some cases where Bearer Control
Tunnelling *could* in principle be used, but where we should decide that it
is not applicable. Specifically, I think that for those technologies
supported by CS1, we should think carefully before introducing alternative
ways of supporting the same thing. As an example, Bearer Control Tunnelling
could be used to transport ATM UNI signalling between two GSNs, because
there is no ATM switching between GSNs. However, I don't see any value in
specifying this application of Bearer Control Tunnelling. This is at present
my opinion. The meeting has not yet addressed this point in detail.

        Sophia's comments below referred also to the other Nortel
contribution to Melbourne which discussed the way that H.248 presently
transports the pieces of information which need to be exchanged between MGs
for IP Bearer Control. The proposal was that in considering what may be
placed inside the Tunnel for IP Bearer Control, we should consider the
encodings already supported in H.248 such as SDP and Native Tags.

        If we followed this approach, then the BICC version of H.248 would
carry the SDP information inside the Bearer Control Tunnelling package,
rather than inside the present termination properties used for SDP. This
would be a minor change, but with the important effect of clearly separating
out the MG-MG information from the MG-MGC information in the protocol.

        What remain an open issues, are (i) whether any other information or
wrapper needs to be carried with the SDP inside the tunnel, and (ii)where we
specify the procedures relating to sending and receipt of tunnelled SDP
information. These should probably be covered in the IP Bearer Control
document produced by SG11.

        Comments ?

        Regards,

        Mark Watson
Nortel Networks



        -----Original Message-----
From: Scoggins, Sophia [NC1:3T18:EXCH]
Sent: 01 June 2000 12:28
To: megaco-interop@fore.com; Watson, Mark [MAIFP:EP11-M:EXCH]
Subject: Re: Multiple MGC scenarios


        Christian,


        Nortel has separate contributions regarding this topic. One
addressed
the bearer information tunneling method (it was Mark's contribution).
The other proposed using the H.248 Native Tags or SDP as the encoding
mechanism (is was Mark and my contribution). Mark presented both at the
Melbourne meeting. I didn't go.


        Mark,

        Would you please answer Christian's question? This mailing list is
for
H.248 Megaco Interop testing coming in Aug.


        Regards, Sophia

        Christian Groves wrote:
>
> G'Day Sophia,
>
> Is this decision in a meeting report somewhere?
>
> I was at the Melbourne meeting where this was discussed and it was
> decided that the tunnel was a global mechanism to be used for IP and ATM
> bearer establishment signalling. The tunnel accepted did not mention SDP
> or H.248 Native tags, it was a simply a bucket to carry bearer
> establishment signalling which otherwise would been signalled directly
> between 2 peer BCFs (MGs).
>
> Regards, Christian
>
> Sophia Scoggins wrote:
> >
> > Christian,
> >
> > You are right. There is one Nortel Network submission particularly
> > addressing tunneling H.248 parameters in SDP or H.248 native tag
> > formats. This is, however, for IP parameters only (in the BICC/ISUP+ CS2
> > or capability Set 2). All the ATM parameters have been defined in BICC
> > parameter field. In order to backward compatible, ITU-T SG11 has decided
> > by majority not to change it or provide extension to carry additional
> > ATM related information in the tunneling messages.
> >
> > Regards, Sophia
> >
> > Christian Groves wrote:
> > >
> > > G'Day Sophia,
> > >
> > > Just to clarify what SG11 accepted. It was the idea of tunnelling
bearer
> > > control messages across BICC and H.248, not to add H.248 parameters in
> > > BICC messages.
> > >
> > > Cheers, Christian
> > >
> > > Sophia Scoggins wrote:
> > > >
> > > > My understanding is that this interop testing event will have a
single
> > > > MGC to a MG or possibly extend to a single MGC to two MGs. There
won't
> > > > be multiple MGCs. The communications between MGC-MGC is outside of
the
> > > > Megaco protocols, and it is not included in this initial H.248
interop
> > > > testing. Gatekeepers are for IP phones. If a MG doesn't handle IP
> > > > phones, gatekeepers are not needed.
> > > >
> > > > There are parameters from MG-MGC that are not included in the
current
> > > > MGC-MGC communication protocols, such as ISUP+ and SIP+. In my
recent
> > > > contribution to ITU-T, I have added extension to ISUP+ (now known as
> > > > BICC) to pass H.248 native tags or SDP parameters. This contribution
is
> > > > accepted as an work item by the SG11. To see it to be included in
the
> > > > standard and implementation, it will take time. So, interop from
H.248
> > > > end-to-end through MGCs will take time to be reality.
> > > >
> > > > Regards, Sophia
> > > >
> > > > samittal@hss.hns.com wrote:
> > > > >
> > > > > In section 1.1.1 it is mentioned "The digit shall be
provisionable.  In single
> > > > > MGC test environments, the digit will normally be zero.  In
multiple MGC
> > > > > scenarios, the gateways are numbered from zero."
> > > > >
> > > > > Between multiple MGCs what kind of MGC-MGC interface will be used.
> > > > > Is some MGC-MGC communication interface standaridised ???
> > > > >
> > > > > Is there a plan to include getekeepers in multiple MGC scenarios
for the simple
> > > > > tests included in the test document ???
> > > > >
> > > > > Sachin Mittal


------_=_NextPart_001_01BFCC90.A1FB178C
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: H.248/BICC discussions</TITLE>

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=920044312-02062000>Well,
I'm having a problem with the idea that a package can extend
SDP.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=920044312-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=920044312-02062000>For
one thing, that's a non-trivial change to the protocol document, as it describes
what</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=920044312-02062000>is in
a package.&nbsp; For another, SDP is described in a separate RFC and is
under</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=920044312-02062000>control of a different group.&nbsp; For a third, the
mechanism wouldn't work with SIP (or really</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=920044312-02062000>MGCP).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=920044312-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=920044312-02062000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]<BR><B>Sent:</B> Friday, June 02, 2000 8:41
  AM<BR><B>To:</B> Mark Watson; 'Christian.Groves@ericsson.com'<BR><B>Cc:</B>
  Sophia Scoggins; megaco-interop@fore.com;
  megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: H.248/BICC
  discussions<BR><BR></DIV></FONT>
  <P><FONT color=#0000ff face=Arial size=2>I have forwarded this note to the
  Megaco list because I believe there is a fundamental point to be discussed on
  the nature of packages.&nbsp; I have not sent it to the SG 11 BICC list
  because that list is closed to non-members.&nbsp; If someone thinks it is
  worth forwarding they are free to do so.</FONT></P>
  <P><FONT color=#0000ff face=Arial size=2>I have held the intent in my own mind
  that it should be possible within packages to define properties that are
  realized within Local and Remote.&nbsp; This would be consistent with Annex C
  usage and would also imply that packages can specify additions to SDP detailed
  syntax.&nbsp; If this is the consensus view, then it won't be necessary to
  modify H.248 to accommodate BICC.&nbsp; Instead, Local and Remote would be
  stripped out at the MGC and forwarded via the tunnel, in exact accordance with
  H.248 design intent.</FONT></P>
  <UL>
    <P><FONT face=Arial size=1>-----Original Message-----</FONT> <BR><B><FONT
    face=Arial size=1>From:&nbsp;&nbsp;</FONT></B> <FONT face=Arial
    size=1>Watson, Mark [MAIFP:EP11-M:EXCH] </FONT><BR><B><FONT face=Arial
    size=1>Sent:&nbsp;&nbsp;</FONT></B> <FONT face=Arial size=1>Friday, June 02,
    2000 8:03 AM</FONT> <BR><B><FONT face=Arial
    size=1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial
    size=1>'Christian.Groves@ericsson.com'; 'tsg11bicc@ties.itu.int'</FONT>
    <BR><B><FONT face=Arial size=1>Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT
    face=Arial size=1>Scoggins, Sophia [NC1:3T18:EXCH];
    megaco-interop@fore.com</FONT> <BR><B><FONT face=Arial
    size=1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT
    face=Arial size=1>RE: H.248/BICC discussions</FONT> </P>
    <P><FONT face=Arial size=2>Christian, All,</FONT><FONT face=Arial>
    </FONT></P>
    <P><FONT face=Arial size=2>Before we get confused, let's remember that the
    Tunnelling mechanism, and the question of what is carried inside the
    Tunnell, are separate and independent issues.</FONT></P>
    <P><FONT face=Arial size=2>What I understand has been agreed is that we will
    work on a general purpose tunnelling mechanism in BICC for the purpose of
    transporting MG to MG information for Bearer Control.</FONT></P>
    <P><FONT face=Arial size=2>As Christian says, the tunnelling mechanism will
    not be specific to any bearer technology and could in principle be used in
    any cases where there is no need for any intermediate BCF-Rs in the bearer
    network to see the Bearer Control information.</FONT></P>
    <P><FONT face=Arial size=2>Personally, I think that there are some cases
    where Bearer Control Tunnelling *could* in principle be used, but where we
    should decide that it is not applicable. Specifically, I think that for
    those technologies supported by CS1, we should think carefully before
    introducing alternative ways of supporting the same thing. As an example,
    Bearer Control Tunnelling could be used to transport ATM UNI signalling
    between two GSNs, because there is no ATM switching between GSNs. However, I
    don't see any value in specifying this application of Bearer Control
    Tunnelling. This is at present my opinion. The meeting has not yet addressed
    this point in detail.</FONT></P>
    <P><FONT face=Arial size=2>Sophia's comments below referred also to the
    other Nortel contribution to Melbourne which discussed the way that H.248
    presently transports the pieces of information which need to be exchanged
    between MGs for IP Bearer Control. The proposal was that in considering what
    may be placed inside the Tunnel for IP Bearer Control, we should consider
    the encodings already supported in H.248 such as SDP and Native
    Tags.</FONT></P>
    <P><FONT face=Arial size=2>If we followed this approach, then the BICC
    version of H.248 would carry the SDP information inside the Bearer Control
    Tunnelling package, rather than inside the present termination properties
    used for SDP. This would be a minor change, but with the important effect of
    clearly separating out the MG-MG information from the MG-MGC information in
    the protocol.</FONT></P>
    <P><FONT face=Arial size=2>What remain an open issues, are (i) whether any
    other information or wrapper needs to be carried with the SDP inside the
    tunnel, and (ii)where we specify the procedures relating to sending and
    receipt of tunnelled SDP information. These should probably be covered in
    the IP Bearer Control document produced by SG11.</FONT></P>
    <P><FONT face=Arial size=2>Comments ?</FONT><FONT face=Arial> </FONT></P>
    <P><FONT face=Arial size=2>Regards,</FONT><FONT face=Arial> </FONT></P>
    <P><FONT face=Arial size=2>Mark Watson</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>Nortel Networks</FONT><FONT
    face=Arial> </FONT></P><BR><BR>
    <P><FONT face=Arial size=2>-----Original Message-----</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>From: Scoggins, Sophia
    [NC1:3T18:EXCH]</FONT><BR><FONT face=Arial size=2>Sent: 01 June 2000
    12:28</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>To:
    megaco-interop@fore.com; Watson, Mark [MAIFP:EP11-M:EXCH]</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>Subject: Re: Multiple MGC
    scenarios</FONT><FONT face=Arial> </FONT></P><BR>
    <P><FONT face=Arial size=2>Christian,</FONT><FONT face=Arial>
</FONT></P><BR>
    <P><FONT face=Arial size=2>Nortel has separate contributions regarding this
    topic. One addressed</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
    size=2>the bearer information tunneling method (it was Mark's
    contribution).</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>The
    other proposed using the H.248 Native Tags or SDP as the
    encoding</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>mechanism
    (is was Mark and my contribution). Mark presented both at the</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>Melbourne meeting. I didn't
    go.</FONT><FONT face=Arial> </FONT></P><BR>
    <P><FONT face=Arial size=2>Mark,</FONT><FONT face=Arial> </FONT></P>
    <P><FONT face=Arial size=2>Would you please answer Christian's question?
    This mailing list is for</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
    size=2>H.248 Megaco Interop testing coming in Aug.</FONT><FONT face=Arial>
    </FONT></P><BR>
    <P><FONT face=Arial size=2>Regards, Sophia</FONT><FONT face=Arial>
    </FONT></P>
    <P><FONT face=Arial size=2>Christian Groves wrote:</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt;</FONT><BR><FONT
    face=Arial size=2>&gt; G'Day Sophia,</FONT><FONT face=Arial><BR></FONT><FONT
    face=Arial size=2>&gt;</FONT><BR><FONT face=Arial size=2>&gt; Is this
    decision in a meeting report somewhere?</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt;</FONT><BR><FONT
    face=Arial size=2>&gt; I was at the Melbourne meeting where this was
    discussed and it was</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
    size=2>&gt; decided that the tunnel was a global mechanism to be used for IP
    and ATM</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
    bearer establishment signalling. The tunnel accepted did not mention
    SDP</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; or H.248
    Native tags, it was a simply a bucket to carry bearer</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; establishment signalling
    which otherwise would been signalled directly</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; between 2 peer BCFs
    (MGs).</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
    size=2>&gt;</FONT><BR><FONT face=Arial size=2>&gt; Regards,
    Christian</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
    size=2>&gt;</FONT><BR><FONT face=Arial size=2>&gt; Sophia Scoggins
    wrote:</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
    &gt;</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;
    Christian,</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
    &gt;</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; You
    are right. There is one Nortel Network submission particularly</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; addressing tunneling
    H.248 parameters in SDP or H.248 native tag</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; formats. This is,
    however, for IP parameters only (in the BICC/ISUP+ CS2</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; or capability Set
    2). All the ATM parameters have been defined in BICC</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; parameter field. In
    order to backward compatible, ITU-T SG11 has decided</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; by majority not to
    change it or provide extension to carry additional</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; ATM related
    information in the tunneling messages.</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; Regards,
    Sophia</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
    &gt;</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;
    Christian Groves wrote:</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
    size=2>&gt; &gt; &gt;</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
    size=2>&gt; &gt; &gt; G'Day Sophia,</FONT><FONT face=Arial><BR></FONT><FONT
    face=Arial size=2>&gt; &gt; &gt;</FONT><FONT face=Arial><BR></FONT><FONT
    face=Arial size=2>&gt; &gt; &gt; Just to clarify what SG11 accepted. It was
    the idea of tunnelling bearer</FONT><FONT face=Arial><BR></FONT><FONT
    face=Arial size=2>&gt; &gt; &gt; control messages across BICC and H.248, not
    to add H.248 parameters in</FONT><FONT face=Arial><BR></FONT><FONT
    face=Arial size=2>&gt; &gt; &gt; BICC messages.</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt;</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt; Cheers,
    Christian</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
    &gt; &gt;</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
    &gt; &gt; Sophia Scoggins wrote:</FONT><FONT face=Arial><BR></FONT><FONT
    face=Arial size=2>&gt; &gt; &gt; &gt;</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt; &gt; My
    understanding is that this interop testing event will have a
    single</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;
    &gt; &gt; MGC to a MG or possibly extend to a single MGC to two MGs. There
    won't</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;
    &gt; &gt; be multiple MGCs. The communications between MGC-MGC is outside of
    the</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt;
    &gt; Megaco protocols, and it is not included in this initial H.248
    interop</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;
    &gt; &gt; testing. Gatekeepers are for IP phones. If a MG doesn't handle
    IP</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt;
    &gt; phones, gatekeepers are not needed.</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt;
    &gt;</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;
    &gt; &gt; There are parameters from MG-MGC that are not included in the
    current</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;
    &gt; &gt; MGC-MGC communication protocols, such as ISUP+ and SIP+. In my
    recent</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;
    &gt; &gt; contribution to ITU-T, I have added extension to ISUP+ (now known
    as</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt;
    &gt; BICC) to pass H.248 native tags or SDP parameters. This contribution
    is</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt;
    &gt; accepted as an work item by the SG11. To see it to be included in
    the</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt;
    &gt; standard and implementation, it will take time. So, interop from
    H.248</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;
    &gt; &gt; end-to-end through MGCs will take time to be reality.</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt;
    &gt;</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;
    &gt; &gt; Regards, Sophia</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
    size=2>&gt; &gt; &gt; &gt;</FONT><FONT face=Arial><BR></FONT><FONT
    face=Arial size=2>&gt; &gt; &gt; &gt; samittal@hss.hns.com
    wrote:</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;
    &gt; &gt; &gt;</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
    size=2>&gt; &gt; &gt; &gt; &gt; In section 1.1.1 it is mentioned "The digit
    shall be provisionable.&nbsp; In single</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt; &gt; &gt; MGC
    test environments, the digit will normally be zero.&nbsp; In multiple
    MGC</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt;
    &gt; &gt; scenarios, the gateways are numbered from zero."</FONT><FONT
    face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt; &gt;
    &gt;</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;
    &gt; &gt; &gt; Between multiple MGCs what kind of MGC-MGC interface will be
    used.</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt;
    &gt; &gt; &gt; Is some MGC-MGC communication interface standaridised
    ???</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt;
    &gt; &gt;</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
    &gt; &gt; &gt; &gt; Is there a plan to include getekeepers in multiple MGC
    scenarios for the simple</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
    size=2>&gt; &gt; &gt; &gt; &gt; tests included in the test document
    ???</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt; &gt; &gt;
    &gt; &gt;</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
    &gt; &gt; &gt; &gt; Sachin Mittal</FONT><FONT face=Arial>
</FONT></P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFCC90.A1FB178C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 08:55:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01082
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 08:55:21 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.140D5F00@standards.nortelnetworks.com>; Fri, 2 Jun 2000 8:46:43 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2295 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 08:44:47 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.CEADAAA0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 8:44:47
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id IAA19458; Fri, 2 Jun 2000 08:52:54 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id IAA06769; Fri, 2 Jun 2000 08:52:54 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <K07X5YCL>; Fri, 2 Jun 2000 08:52:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCC91.6ECE7D76"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67840F@whq-msgusr-02.fore.com>
Date:         Fri, 2 Jun 2000 08:52:37 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: ordering of commands
X-To:         Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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_01BFCC91.6ECE7D76
Content-Type: text/plain;
        charset="ISO-8859-1"

It's actually pretty hard to get into this circumstance, as most scenarios
would not allow
the situation to occur.  It is possible under a scenario where you have a
pre-existing
context (so you know the ContextId), and you add and subtract a physical
termination (so you
know the terminationId), and the MG actually does execute the Subtract
before the Add.

You would get some error, which one is not clear.  400 is a possibility.
So is 410 Incorrect Identifier, or 430 Unknown TerminationId.  Some day, we
might make
a new one for this case.

The subsequent Add would succeed.

Brian

 -----Original Message-----
From: Sameer Kaikini [mailto:ksameer@RND.CTS-CORP.COM]
Sent: Friday, June 02, 2000 7:01 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: ordering of commands



Hello.

In section 9.1 of the MEGACO draft we say that the Subtract command can be
sent anytime. What happens if the Subtract command  is executed bu the MG
before the Add command on the samewas executed?
Does the MG return errorcode 400 : "Bad Request"?
What does it do with the Add command executed later ?

Thank-you.
Regards,
Sameer.



------_=_NextPart_001_01BFCC91.6ECE7D76
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 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=870173312-02062000>It's
actually pretty hard to get into this circumstance, as most scenarios would not
allow</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=870173312-02062000>the
situation to occur.&nbsp; It is possible under a scenario where you have a
pre-existing </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=870173312-02062000>context (so you know the ContextId), and you add and
subtract a physical termination (so you</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=870173312-02062000>know
the terminationId), and the MG actually does execute the Subtract before the
Add.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=870173312-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=870173312-02062000>You
would get some error, which one is not clear.&nbsp; 400 is a
possibility.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=870173312-02062000>So is
410 Incorrect Identifier, or 430 Unknown TerminationId.&nbsp; Some day, we might
make</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=870173312-02062000>a new
one for this case.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=870173312-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=870173312-02062000>The
subsequent Add would succeed.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=870173312-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=870173312-02062000>Brian</SPAN></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN
class=870173312-02062000></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN
class=870173312-02062000>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B>
Sameer Kaikini [mailto:ksameer@RND.CTS-CORP.COM]<BR><B>Sent:</B> Friday, June
02, 2000 7:01 PM<BR><B>To:</B>
MEGACO@STANDARDS.NORTELNETWORKS.COM<BR><B>Subject:</B> ordering of
commands<BR><BR></DIV></FONT>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"></FONT>
  <DIV><FONT color=#000000 size=2>Hello.</FONT></DIV>
  <DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
  <DIV><FONT color=#000000 size=2>In section 9.1 of the MEGACO draft we say that
  the Subtract command can be sent anytime. What happens if the Subtract
  command&nbsp; is executed bu the MG before the Add command on the samewas
  executed?</FONT></DIV>
  <DIV><FONT size=2>Does the MG return errorcode 400 : "Bad
  Request"?</FONT></DIV>
  <DIV><FONT size=2>What does it do with the Add command executed later
  ?</FONT></DIV>
  <DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
  <DIV><FONT color=#000000 size=2>Thank-you.</FONT></DIV>
  <DIV><FONT color=#000000 size=2>Regards,</FONT></DIV>
  <DIV><FONT color=#000000 size=2>Sameer.</FONT></DIV>
  <DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFCC91.6ECE7D76--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 09:01:25 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01258
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 09:01:25 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EAE89350@standards.nortelnetworks.com>; Fri, 2 Jun 2000 8:52:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2343 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 08:50:46 -0400
Received: from qhars002.nortel.com (47.101.112.102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A4A8B820@standards.nortelnetworks.com>; Fri, 2 Jun 2000 8:50:46
          -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Fri, 2 Jun 2000 13:58:11 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Fri, 2 Jun 2000 07:53:30 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <LW2CBMJY>; Fri, 2 Jun 2000 07:53:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCC91.8635BD3A"
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD110385854C@zcard00g.ca.nortel.com>
Date:         Fri, 2 Jun 2000 07:53:27 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: ordering of commands
X-To:         Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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_01BFCC91.8635BD3A
Content-Type: text/plain

The response to the Subtract would be 430: Unknown TerminationID for an
ephemeral termination.  I suppose 400: Bad Request would have to do for a
persistent termination which is in the null context already, but we really
should define an error code "TerminationID Not In Context", or more
generally "State Mismatch".

The Add would be executed normally.

> -----Original Message-----
> From: Sameer Kaikini [SMTP:ksameer@RND.CTS-CORP.COM]
> Sent: Friday, June 02, 2000 7:01 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      ordering of commands
>
> Hello.
>
> In section 9.1 of the MEGACO draft we say that the Subtract command can be
> sent anytime. What happens if the Subtract command  is executed bu the MG
> before the Add command on the samewas executed?
> Does the MG return errorcode 400 : "Bad Request"?
> What does it do with the Add command executed later ?
>
> Thank-you.
> Regards,
> Sameer.
>

------_=_NextPart_001_01BFCC91.8635BD3A
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-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: ordering of commands</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The response to the =
Subtract would be 430: Unknown TerminationID for an ephemeral =
termination.&nbsp; I suppose 400: Bad Request would have to do for a =
persistent termination which is in the null context already, but we =
really should define an error code &quot;TerminationID Not In =
Context&quot;, or more generally &quot;State Mismatch&quot;. =
</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The Add would be =
executed normally.</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Sameer Kaikini =
[SMTP:ksameer@RND.CTS-CORP.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, June 02, 2000 7:01 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">ordering of commands</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Hello.</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">In section 9.1 of =
the MEGACO draft we say that the Subtract command can be sent anytime. =
What happens if the Subtract command=A0 is executed bu the MG before =
the Add command on the samewas executed?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Does the MG return errorcode 400 : =
&quot;Bad Request&quot;?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">What does it do with the Add command =
executed later ?</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Thank-you.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Sameer.</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCC91.8635BD3A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 09:08:27 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01455
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 09:08:27 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E58BC890@standards.nortelnetworks.com>; Fri, 2 Jun 2000 8:59:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2385 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 08:58:25 -0400
Received: from qhars002.nortel.com (47.101.112.102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B351F700@standards.nortelnetworks.com>; Fri, 2 Jun 2000 8:58:20
          -0400
Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com;
          Fri, 2 Jun 2000 14:01:00 +0100
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          smtprich.nortel.com; Fri, 2 Jun 2000 07:52:11 -0500
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Fri, 2 Jun 2000 09:00:04 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <L3HQA8RN>; Fri, 2 Jun 2000 08:59:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCC92.74F1A70E"
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD110385854D@zcard00g.ca.nortel.com>
Date:         Fri, 2 Jun 2000 08:59:57 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: H.248/BICC discussions
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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_01BFCC92.74F1A70E
Content-Type: text/plain

As I noted in a previous posting, our Area Directors have agreed that when
it comes to detailed changes to SDP (not involving new principles), Megaco
can go ahead and do the job on its own.  MMUSIC, of course, has to be kept
informed.

While I'm being cooperative with MGCP, that shouldn't get in the way of a
logical evolution of the standard.

> -----Original Message-----
> From: Rosen, Brian [SMTP:Brian.Rosen@MARCONI.COM]
> Sent: Friday, June 02, 2000 8:47 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: H.248/BICC discussions
>
> Well, I'm having a problem with the idea that a package can extend SDP.
>
> For one thing, that's a non-trivial change to the protocol document, as it
> describes what
> is in a package.  For another, SDP is described in a separate RFC and is
> under
> control of a different group.  For a third, the mechanism wouldn't work
> with SIP (or really
> MGCP).
>
> Brian
>
>       -----Original Message-----
>       From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>       Sent: Friday, June 02, 2000 8:41 AM
>       To: Mark Watson; 'Christian.Groves@ericsson.com'
>       Cc: Sophia Scoggins; megaco-interop@fore.com;
> megaco@standards.nortelnetworks.com
>       Subject: RE: H.248/BICC discussions
>
>
>
>       I have forwarded this note to the Megaco list because I believe
> there is a fundamental point to be discussed on the nature of packages.  I
> have not sent it to the SG 11 BICC list because that list is closed to
> non-members.  If someone thinks it is worth forwarding they are free to do
> so.
>
>       I have held the intent in my own mind that it should be possible
> within packages to define properties that are realized within Local and
> Remote.  This would be consistent with Annex C usage and would also imply
> that packages can specify additions to SDP detailed syntax.  If this is
> the consensus view, then it won't be necessary to modify H.248 to
> accommodate BICC.  Instead, Local and Remote would be stripped out at the
> MGC and forwarded via the tunnel, in exact accordance with H.248 design
> intent.
>
>

------_=_NextPart_001_01BFCC92.74F1A70E
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-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: H.248/BICC discussions</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">As I noted in a =
previous posting, our Area Directors have agreed that when it comes to =
detailed changes to SDP (not involving new principles), Megaco can go =
ahead and do the job on its own.&nbsp; MMUSIC, of course, has to be =
kept informed.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">While I'm being =
cooperative with MGCP, that shouldn't get in the way of a logical =
evolution of the standard.</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Rosen, Brian =
[SMTP:Brian.Rosen@MARCONI.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, June 02, 2000 8:47 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: H.248/BICC discussions</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Well, I'm having a =
problem with the idea that a package can extend SDP.</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">For one thing, =
that's a non-trivial change to the protocol document, as it describes =
what</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">is in a package.=A0 =
For another, SDP is described in a separate RFC and is under</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">control of a =
different group.=A0 For a third, the mechanism wouldn't work with SIP =
(or really</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">MGCP).</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Brian</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Tahoma">-----Original Message-----<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">From:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Tom-PT Taylor [<U></U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Tahoma"><A =
HREF=3D"mailto:taylor@nortelnetworks.com">mailto:taylor@nortelnetworks.c=
om</A></FONT></U><FONT SIZE=3D2 FACE=3D"Tahoma">]<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Sent:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Friday, June 02, 2000 8:41 AM<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">To:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Mark Watson; 'Christian.Groves@ericsson.com'<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Cc:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Sophia Scoggins; megaco-interop@fore.com; =
megaco@standards.nortelnetworks.com<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Subject:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Tahoma"> RE: H.248/BICC discussions<BR>
<BR>
</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I have forwarded =
this note to the Megaco list because I believe there is a fundamental =
point to be discussed on the nature of packages.=A0 I have not sent it =
to the SG 11 BICC list because that list is closed to non-members.=A0 =
If someone thinks it is worth forwarding they are free to do =
so.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I have held the =
intent in my own mind that it should be possible within packages to =
define properties that are realized within Local and Remote.=A0 This =
would be consistent with Annex C usage and would also imply that =
packages can specify additions to SDP detailed syntax.=A0 If this is =
the consensus view, then it won't be necessary to modify H.248 to =
accommodate BICC.=A0 Instead, Local and Remote would be stripped out at =
the MGC and forwarded via the tunnel, in exact accordance with H.248 =
design intent.</FONT></P>
<BR>
</UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCC92.74F1A70E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 09:15:28 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01589
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 09:15:27 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E01BEB00@standards.nortelnetworks.com>; Fri, 2 Jun 2000 9:06:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2423 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 09:05:31 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.B3E17050@standards.nortelnetworks.com>; Fri, 2 Jun 2000 9:05:31
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id JAA21344; Fri, 2 Jun 2000 09:13:38 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id JAA11536; Fri, 2 Jun 2000 09:13:39 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <K07X5Y74>; Fri, 2 Jun 2000 09:13:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678410@whq-msgusr-02.fore.com>
Date:         Fri, 2 Jun 2000 09:13:35 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Gateways and call routing
X-To:         Dimitris Terzis <D.Terzis@CS.UCL.AC.UK>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> Given the previous, I have the following questions:
>
> (a) Is there a central entity within a distributed VoIP gateway,
> consisting of a number of SG's, MG's and MGC's, which
> would serve as its "representative" to the outside world
> (e.g., by advertising its capabilities to TRIP Location Servers),
> so that the gateway could be visible as an integrated entity
> by the outside world? Or an external mechanism would be
> used to discover (how?) these capabilities?
It is the MGC that is known to the outside world.  TRIP would point
to the appropriate MGC.

>
> Given that the MGC is (essentially) the Gateway Controller,
> one would expect that it would do this job, but what happens
> in the case of multiple MGC's? Is there any "leader" election
> process defined/implied?
There are several reasons to have multiple MGCs.  For reliability,
there might be more than one.  At any time however, only one
controls an MG.  The MG is connected to subscribers.  So, if you
think in terms of conventional telephone systems, the phone is connected
(somehow) to one MG, that MG is connected to one MGC, and the
directory number of that phone in the TRIP database would point
to the MGC that controlled that MG that was connected to that phone.

>
> (b) What is the preferable internal capability discovery
> for a VoIP gateway? There is, for instance, the MGC-MG
> Resource Discovery mechanism that allows the MGC to
> know of the media capabilities of the gateway, but what
> happens with signalling?
That is clearly outside the domain of Megaco.  In most circumstances
it is defined by the MGC-MGC signalling.  If you were to use SIP
for example, each phone would have a SIP URI, and the SIP UA
would be the MGC.  Nothing, of course, prevents one device (the MGC)
from looking like a million SIP UAs!

>
> (c) Where does a Signalling Server, and particularly
> an IP one (e.g., a SIP Proxy) fit in this gateway model?
> Is it part of an MGC?
Well, in the sense that one physical device can be both a UA and
a Server (of various kinds), and MGC can be a SIP server.  It
might not be a proxy server, since it has the UAs in it.

>
> (d) Is there any compelling reason why we should have
> Signalling Gateways that are (essentially) SCN clients
> (Signalling Processors), following the H.323 model,
> and then need mechanisms like SIGTRAN (RFC 2719)
> to communicate with the MGC?
Oh most definitely.  Suppose that the MG was connected to a PBX.
Suppose the PBX used ISDN signalling.  In this case, the MGC would
terminate Q.931.  However, the MG is the one that has the physical
connection, so the MG would terminate the signalling at Q.921,
and send the Q.931 to the MGC via SCTP.  In this case the SG is
collocated with the MG.

The other obvious case is where the MGC is doing interwork to the
PSTN.  In this case you might have SS7 links which are terminated
in a device which is not the MGC.  So, the SG terminates SS7 at, say
MTP2, and sends MTP3 to the MGC via SCTP.

>
> Why wouldn't we want to move all the external signalling
> functions to the SG (i.e., ask _it_ to do the translation
> between SCN and IP signalling), and only use the
> MGC as an internal management function, which also
> collects and advertises the gateway capabilities to the
> outside world?
We currently define the SG as a relatively dumb device, as we
define the MG as a relatively dumb device.  Your definition of
the SG as being a complete signalling interwork function overlaps
with our current definition of MGC.

Note that your definition could be made to work with the latter example
of PSTN signalling interwork, but not the former example of ISDN
signalling interwork.

At any rate, you are trying to redefine terms that we have
gradually come to consensus on, and, despite the fact that there
isn't a "right" or a "wrong" way to define anything, I believe that
you might be better off accepting the current definition.

>
> From the definition of a SG in RFC's 2719 and 2805,
> translation is one of the envisioned functions (at least
> for some cases).
>
> (e) Is the above model suitable for "pure IP" gateways?
> What happens, for example, when we want to connect an
> H.323 subnet to a SIP one? Or when we want to use only
> the media resources of a gateway (e.g., its codecs) in the
> middle of a call?
In the former case you need a SIP-H.323 interwork function,
which is neither an MGC or MG.  It could use an SG, but I suspect that
it would simply interwork H.323 to SIP.  There is effort to define
such an interworking function underway.

In the latter case of codec change in the middle of a call, it would
be very reasonable to have the codecs in an MG.  The controlling
MGC would have to somehow be in the middle of a signalling path.
The SIP/H.323 signalling mechanisms don't have explicit ways to do
that, but it can be constructed as a set of connections.  Use of
Megaco for this application is a very good use of the protocol.
Of course nothing stops you from making a single box with both the
MG and MGC functions, just like a current H.323 gateway, and then
you wouldn't need Megaco.  I'd be inclined to keep them separate,
but that's a product design decision.

>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 09:52:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02431
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 09:52:31 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0E5E5160@standards.nortelnetworks.com>; Fri, 2 Jun 2000 9:43:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2471 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 09:42:04 -0400
Received: from qhars002.nortel.com (47.101.112.102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.CF66C7D0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 9:42:04
          -0400
Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com;
          Fri, 2 Jun 2000 14:44:39 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Fri, 2 Jun 2000 08:36:03 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <LW2CB3LN>; Fri, 2 Jun 2000 08:44:26 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD110385854F@zcard00g.ca.nortel.com>
Date:         Fri, 2 Jun 2000 08:44:34 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      MGC-Initiated Control
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

There are cases where an MG will not be able to initiate a control session
(e.g. it has gone through its list of MGCs without success).  Can we agree
on principle that an MG that is not currently in a control session will
respond to an MGC-sent ServiceChange command directing it to initiate a
session at a given address?  If so, we could add this to the Implementor's
Guide and our IETF equivalent.

The exact text that would go into the Implementor's Guide would be as
follows:

        If an MG is not currently in a control association with an MGC and
it receives a ServiceChange command from an authorized source with
ServiceChangeMethod equal to Handoff, it will attempt to initiate a control
association as directed by that command.  To make this possible, an MG not
currently in a control session shall listen for incoming commands at the
default transport address corresponding to its supported transport and
encoding (e.g. UDP port 2944 for text-encoded UDP/ALF).

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 10:18:40 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02878
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 10:18:40 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B0C266F0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 10:09:51 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2511 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 10:07:54 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.054D14B0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 9:57:54
          -0400
Received: from cisco.com (rtp-dial-2-44.cisco.com [10.83.96.44]) by
          mailman.cisco.com (8.9.3/8.9.1) with ESMTP id HAA26287; Fri, 2 Jun
          2000 07:05:55 -0700 (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD110385854D@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------9BE39720C948001B5AA3C7F9"
Message-ID:  <3937EA36.97425404@cisco.com>
Date:         Fri, 2 Jun 2000 10:09:11 -0700
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Subject:      Re: H.248/BICC discussions
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------9BE39720C948001B5AA3C7F9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Tom-PT Taylor wrote:

>
>
> As I noted in a previous posting, our Area Directors have agreed that
> when it comes to detailed changes to SDP (not involving new
> principles), Megaco can go ahead and do the job on its own.  MMUSIC,
> of course, has to be kept informed.

Please refresh my mind - which posting was this ?

If all you are saying is, that Megaco, just like anybody else, is free
to "extend" SDP as per the Appendix B procedures in RFC 2327, then I
have no problem with that, provided existing SDP field names and values
do not do the job.

If on the other hand you are saying that Megaco has gotten approval to
violate SDP (in the MG=>MGC direction that is, as the MGC=>MG direction
is not RFC 2327 SDP), then I'm both confused and concerned.


>
>
> While I'm being cooperative with MGCP, that shouldn't get in the way
> of a logical evolution of the standard.

Agreed, however if we start violating RFC 2327, then we will have
interworking problems with several protocols. Megaco should not try and
operate in a vacuum IMHO.

-- Flemming

>
>
>      -----Original Message-----
>      From:   Rosen, Brian [SMTP:Brian.Rosen@MARCONI.COM]
>      Sent:   Friday, June 02, 2000 8:47 AM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Re: H.248/BICC discussions
>
>      Well, I'm having a problem with the idea that a package can
>      extend SDP.
>
>      For one thing, that's a non-trivial change to the protocol
>      document, as it describes what
>      is in a package.  For another, SDP is described in a separate RFC
>      and is under
>      control of a different group.  For a third, the mechanism
>      wouldn't work with SIP (or really
>      MGCP).
>
>      Brian
>           -----Original Message-----
>           From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>           Sent: Friday, June 02, 2000 8:41 AM
>           To: Mark Watson; 'Christian.Groves@ericsson.com'
>           Cc: Sophia Scoggins; megaco-interop@fore.com;
>           megaco@standards.nortelnetworks.com
>           Subject: RE: H.248/BICC discussions
>
>
>           I have forwarded this note to the Megaco list because I
>           believe there is a fundamental point to be discussed on the
>           nature of packages.  I have not sent it to the SG 11 BICC
>           list because that list is closed to non-members.  If someone
>           thinks it is worth forwarding they are free to do so.
>
>           I have held the intent in my own mind that it should be
>           possible within packages to define properties that are
>           realized within Local and Remote.  This would be consistent
>           with Annex C usage and would also imply that packages can
>           specify additions to SDP detailed syntax.  If this is the
>           consensus view, then it won't be necessary to modify H.248
>           to accommodate BICC.  Instead, Local and Remote would be
>           stripped out at the MGC and forwarded via the tunnel, in
>           exact accordance with H.248 design intent.
>
>
--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839


--------------9BE39720C948001B5AA3C7F9
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Tom-PT Taylor wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>As I noted in
a previous posting, our Area Directors have agreed that when it comes to
detailed changes to SDP (not involving new principles), Megaco can go ahead
and do the job on its own.&nbsp; MMUSIC, of course, has to be kept informed.</font></font></font></blockquote>
Please refresh my mind - which posting was this ?
<p>If all you are saying is, that Megaco, just like anybody else, is free
to "extend" SDP as per the Appendix B procedures in RFC 2327, then I have
no problem with that, provided existing SDP field names and values do not
do the job.
<p>If on the other hand you are saying that Megaco has gotten approval
to violate SDP (in the MG=>MGC direction that is, as the MGC=>MG direction
is not RFC 2327 SDP), then I'm both confused and concerned.
<br>&nbsp;
<blockquote TYPE=CITE><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>While I'm being
cooperative with MGCP, that shouldn't get in the way of a logical evolution
of the standard.</font></font></font></blockquote>
Agreed, however if we start violating RFC 2327, then we will have interworking
problems with several protocols. Megaco should not try and operate in a
vacuum IMHO.
<p>-- Flemming
<blockquote TYPE=CITE><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;
<ul><font face="Arial"><font size=-2>-----Original Message-----</font></font>
<br><b><font face="Arial"><font size=-2>From:&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>Rosen, Brian [SMTP:Brian.Rosen@MARCONI.COM]</font></font>
<br><b><font face="Arial"><font size=-2>Sent:&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>Friday, June 02, 2000 8:47 AM</font></font>
<br><b><font face="Arial"><font size=-2>To:&nbsp;&nbsp;&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>MEGACO@STANDARDS.NORTELNETWORKS.COM</font></font>
<br><b><font face="Arial"><font size=-2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>Re: H.248/BICC discussions</font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>Well, I'm having
a problem with the idea that a package can extend SDP.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>For one thing,
that's a non-trivial change to the protocol document, as it describes what</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>is in a package.&nbsp;
For another, SDP is described in a separate RFC and is under</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>control of a
different group.&nbsp; For a third, the mechanism wouldn't work with SIP
(or really</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>MGCP).</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>Brian</font></font></font>
<ul><font face="Tahoma"><font size=-1>-----Original Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Tom-PT Taylor [<u><font color="#0000FF"><a href="mailto:taylor@nortelnetworks.com">mailto:taylor@nortelnetworks.com</a></font></u>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Friday, June 02, 2000
8:41 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> Mark Watson; 'Christian.Groves@ericsson.com'</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> Sophia Scoggins; megaco-interop@fore.com;
megaco@standards.nortelnetworks.com</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> RE: H.248/BICC discussions</font></font>
<br>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>I have forwarded
this note to the Megaco list because I believe there is a fundamental point
to be discussed on the nature of packages.&nbsp; I have not sent it to
the SG 11 BICC list because that list is closed to non-members.&nbsp; If
someone thinks it is worth forwarding they are free to do so.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>I have held the
intent in my own mind that it should be possible within packages to define
properties that are realized within Local and Remote.&nbsp; This would
be consistent with Annex C usage and would also imply that packages can
specify additions to SDP detailed syntax.&nbsp; If this is the consensus
view, then it won't be necessary to modify H.248 to accommodate BICC.&nbsp;
Instead, Local and Remote would be stripped out at the MGC and forwarded
via the tunnel, in exact accordance with H.248 design intent.</font></font></font>
<br>&nbsp;</ul>
</ul>
</blockquote>

<p>--
<br>Flemming Andreasen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Phone: +1 732 452 1667
<br>Cisco Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax:&nbsp;&nbsp; +1 240 359 5839
<br>&nbsp;</html>

--------------9BE39720C948001B5AA3C7F9--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 10:22:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02933
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 10:22:36 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.424E88B0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 10:13:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2512 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 10:12:01 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.98602490@standards.nortelnetworks.com>; Fri, 2 Jun 2000 10:02:00
          -0400
Received: from cisco.com (rtp-dial-2-44.cisco.com [10.83.96.44]) by
          mailman.cisco.com (8.9.3/8.9.1) with ESMTP id HAA27356; Fri, 2 Jun
          2000 07:09:59 -0700 (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD110385854F@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3937EB2B.90C4E8CB@cisco.com>
Date:         Fri, 2 Jun 2000 10:13:15 -0700
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Subject:      Re: MGC-Initiated Control
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Sounds reasonable.

-- Flemming

Tom-PT Taylor wrote:

> There are cases where an MG will not be able to initiate a control session
> (e.g. it has gone through its list of MGCs without success).  Can we agree
> on principle that an MG that is not currently in a control session will
> respond to an MGC-sent ServiceChange command directing it to initiate a
> session at a given address?  If so, we could add this to the Implementor's
> Guide and our IETF equivalent.
>
> The exact text that would go into the Implementor's Guide would be as
> follows:
>
>         If an MG is not currently in a control association with an MGC and
> it receives a ServiceChange command from an authorized source with
> ServiceChangeMethod equal to Handoff, it will attempt to initiate a control
> association as directed by that command.  To make this possible, an MG not
> currently in a control session shall listen for incoming commands at the
> default transport address corresponding to its supported transport and
> encoding (e.g. UDP port 2944 for text-encoded UDP/ALF).
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 10:31:54 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03179
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 10:31:53 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.84A0E090@standards.nortelnetworks.com>; Fri, 2 Jun 2000 10:22:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2597 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 10:21:03 -0400
Received: from qhars002.nortel.com (47.101.112.102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.3E8974F0@standards.nortelnetworks.com>; Fri, 2 Jun 2000
          10:20:58 -0400
Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com;
          Fri, 2 Jun 2000 15:28:15 +0100
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          smtprich.nortel.com; Fri, 2 Jun 2000 09:19:16 -0500
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Fri, 2 Jun 2000 10:27:19 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <L3HQBBF3>; Fri, 2 Jun 2000 10:27:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCC9E.A7F04A28"
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1103858553@zcard00g.ca.nortel.com>
Date:         Fri, 2 Jun 2000 10:27:17 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: H.248/BICC discussions
X-To:         Flemming Andreasen <fandreas@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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_01BFCC9E.A7F04A28
Content-Type: text/plain

The simplest thing to do here is for me to reproduce Scott's note to me.
Definitely we will NOT violate SDP.  I think I may have posted to the ATMSDP
list and MMUSIC rather than the general Megaco list (Sorry!).

From Scott Bradner to me, received last Tuesday:

tom - Allison & I have talked about the megaco SDP extensions and
have agreed that megaco should go ahead and take the token but
coordinate with mmusic

> -----Original Message-----
> From: Flemming Andreasen [SMTP:fandreas@CISCO.COM]
> Sent: Friday, June 02, 2000 1:09 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: H.248/BICC discussions
>
>
> Tom-PT Taylor wrote:
>
>
>
>       As I noted in a previous posting, our Area Directors have agreed
> that when it comes to detailed changes to SDP (not involving new
> principles), Megaco can go ahead and do the job on its own.  MMUSIC, of
> course, has to be kept informed.
>
> Please refresh my mind - which posting was this ?
>
> If all you are saying is, that Megaco, just like anybody else, is free to
> "extend" SDP as per the Appendix B procedures in RFC 2327, then I have no
> problem with that, provided existing SDP field names and values do not do
> the job.
>
> If on the other hand you are saying that Megaco has gotten approval to
> violate SDP (in the MG=>MGC direction that is, as the MGC=>MG direction is
> not RFC 2327 SDP), then I'm both confused and concerned.
>
>
>
>
>       While I'm being cooperative with MGCP, that shouldn't get in the way
> of a logical evolution of the standard.
>
> Agreed, however if we start violating RFC 2327, then we will have
> interworking problems with several protocols. Megaco should not try and
> operate in a vacuum IMHO.
>
> -- Flemming
>
>
>
>               -----Original Message-----
>       From:   Rosen, Brian [SMTP:Brian.Rosen@MARCONI.COM]
>       Sent:   Friday, June 02, 2000 8:47 AM
>       To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject:        Re: H.248/BICC discussions
>
>               Well, I'm having a problem with the idea that a package can
> extend SDP.
>
>               For one thing, that's a non-trivial change to the protocol
> document, as it describes what
>       is in a package.  For another, SDP is described in a separate RFC
> and is under
>       control of a different group.  For a third, the mechanism wouldn't
> work with SIP (or really
>       MGCP).
>
>               Brian
>
>                       -----Original Message-----
>               From: Tom-PT Taylor [ <mailto:taylor@nortelnetworks.com>]
>               Sent: Friday, June 02, 2000 8:41 AM
>               To: Mark Watson; 'Christian.Groves@ericsson.com'
>               Cc: Sophia Scoggins; megaco-interop@fore.com;
> megaco@standards.nortelnetworks.com
>               Subject: RE: H.248/BICC discussions
>
>
>                       I have forwarded this note to the Megaco list
> because I believe there is a fundamental point to be discussed on the
> nature of packages.  I have not sent it to the SG 11 BICC list because
> that list is closed to non-members.  If someone thinks it is worth
> forwarding they are free to do so.
>
>                       I have held the intent in my own mind that it should
> be possible within packages to define properties that are realized within
> Local and Remote.  This would be consistent with Annex C usage and would
> also imply that packages can specify additions to SDP detailed syntax.  If
> this is the consensus view, then it won't be necessary to modify H.248 to
> accommodate BICC.  Instead, Local and Remote would be stripped out at the
> MGC and forwarded via the tunnel, in exact accordance with H.248 design
> intent.
>
>
> --
> Flemming Andreasen                Phone: +1 732 452 1667
> Cisco Systems                     Fax:   +1 240 359 5839
>

------_=_NextPart_001_01BFCC9E.A7F04A28
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-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: H.248/BICC discussions</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The simplest thing =
to do here is for me to reproduce Scott's note to me.&nbsp; Definitely =
we will NOT violate SDP.&nbsp; I think I may have posted to the ATMSDP =
list and MMUSIC rather than the general Megaco list =
(Sorry!).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">From Scott Bradner =
to me, received last Tuesday:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">tom - Allison &amp; I have talked =
about the megaco SDP extensions and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">have agreed that megaco should go =
ahead and take the token but </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">coordinate with mmusic</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Flemming Andreasen =
[SMTP:fandreas@CISCO.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, June 02, 2000 1:09 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: H.248/BICC discussions</FONT>
</P>

<P><FONT FACE=3D"Arial">=A0<BR>
Tom-PT Taylor wrote: </FONT>
</P>
<UL>
<P><FONT FACE=3D"Arial">=A0 </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">As I noted in a =
previous posting, our Area Directors have agreed that when it comes to =
detailed changes to SDP (not involving new principles), Megaco can go =
ahead and do the job on its own.=A0 MMUSIC, of course, has to be kept =
informed.</FONT></P>
</UL>
<P><FONT FACE=3D"Arial">Please refresh my mind - which posting was this =
? </FONT>
</P>

<P><FONT FACE=3D"Arial">If all you are saying is, that Megaco, just =
like anybody else, is free to &quot;extend&quot; SDP as per the =
Appendix B procedures in RFC 2327, then I have no problem with that, =
provided existing SDP field names and values do not do the job. =
</FONT></P>

<P><FONT FACE=3D"Arial">If on the other hand you are saying that Megaco =
has gotten approval to violate SDP (in the MG=3D&gt;MGC direction that =
is, as the MGC=3D&gt;MG direction is not RFC 2327 SDP), then I'm both =
confused and concerned.<BR>
=A0 </FONT>
</P>
<UL>
<P><FONT FACE=3D"Arial">=A0 </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">While I'm being =
cooperative with MGCP, that shouldn't get in the way of a logical =
evolution of the standard.</FONT>
</P>
</UL>
<P><FONT FACE=3D"Arial">Agreed, however if we start violating RFC 2327, =
then we will have interworking problems with several protocols. Megaco =
should not try and operate in a vacuum IMHO. </FONT></P>

<P><FONT FACE=3D"Arial">-- Flemming </FONT>
</P>
<UL>
<P><FONT FACE=3D"Arial">=A0 </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 =
FACE=3D"Arial">-----Original Message-----</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">From:=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Rosen, Brian =
[SMTP:Brian.Rosen@MARCONI.COM]</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Friday, June 02, =
2000 8:47 AM</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">To:=A0=A0=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">Subject:=A0=A0=A0=A0=A0=A0=A0</F=
ONT></B><FONT FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Re: =
H.248/BICC discussions</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">Well, I'm having a problem with the idea that a =
package can extend SDP.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">For one thing, that's a non-trivial change to =
the protocol document, as it describes what</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">is in a =
package.=A0 For another, SDP is described in a separate RFC and is =
under</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">control of a =
different group.=A0 For a third, the mechanism wouldn't work with SIP =
(or really</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">MGCP).</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">Brian</FONT><FONT FACE=3D"Arial"> </FONT>
</P>
<UL>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Tahoma">-----Original Message-----</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><B></B><B><FONT SIZE=3D2 FACE=3D"Tahoma">From:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Tahoma"> Tom-PT Taylor [<U></U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Tahoma"></FONT> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Tahoma">&lt;<A =
HREF=3D"mailto:taylor@nortelnetworks.com">mailto:taylor@nortelnetworks.c=
om</A>&gt;</FONT></U><FONT SIZE=3D2 FACE=3D"Tahoma">]</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><B></B><B><FONT SIZE=3D2 FACE=3D"Tahoma">Sent:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Tahoma"> Friday, June 02, 2000 8:41 AM</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><B></B><B><FONT SIZE=3D2 FACE=3D"Tahoma">To:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Tahoma"> Mark Watson; =
'Christian.Groves@ericsson.com'</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B></B><B><FONT SIZE=3D2 FACE=3D"Tahoma">Cc:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Tahoma"> Sophia Scoggins; megaco-interop@fore.com; =
megaco@standards.nortelnetworks.com</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B></B><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Subject:</FONT></B><FONT SIZE=3D2 FACE=3D"Tahoma"> RE: =
H.248/BICC discussions</FONT><FONT FACE=3D"Arial"><BR>
=A0 </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">I have forwarded this note to the Megaco list =
because I believe there is a fundamental point to be discussed on the =
nature of packages.=A0 I have not sent it to the SG 11 BICC list =
because that list is closed to non-members.=A0 If someone thinks it is =
worth forwarding they are free to do so.</FONT><FONT FACE=3D"Arial"> =
</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">I have held the intent in my own mind that it =
should be possible within packages to define properties that are =
realized within Local and Remote.=A0 This would be consistent with =
Annex C usage and would also imply that packages can specify additions =
to SDP detailed syntax.=A0 If this is the consensus view, then it won't =
be necessary to modify H.248 to accommodate BICC.=A0 Instead, Local and =
Remote would be stripped out at the MGC and forwarded via the tunnel, =
in exact accordance with H.248 design intent.</FONT><FONT =
FACE=3D"Arial"><BR>
=A0</FONT>
</P>
</UL></UL>
<P><FONT FACE=3D"Arial">--<BR>
Flemming Andreasen=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Phone: =
+1 732 452 1667<BR>
Cisco =
Systems=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Fax:=A0=A0 +1 240 359 5839<BR>
=A0</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCC9E.A7F04A28--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 10:41:41 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03375
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 10:41:41 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ED1B2260@standards.nortelnetworks.com>; Fri, 2 Jun 2000 10:33:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2641 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 10:32:00 -0400
Received: from qhars002.nortel.com (47.101.112.102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C62D2950@standards.nortelnetworks.com>; Fri, 2 Jun 2000
          10:31:55 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Fri, 2 Jun 2000 15:36:35 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Fri, 2 Jun 2000 10:22:30 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <L3HQBA9P>; Fri, 2 Jun 2000 10:22:30 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1103858552@zcard00g.ca.nortel.com>
Date:         Fri, 2 Jun 2000 10:22:29 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Package Overlaps With Annex C
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Annex C is in my mind an interim measure until packages catch up to provide
both a text and binary encoding.  of course, this view partly requires a few
more people to enter the discussion on whether packages can define
properties which go into Local and Remote.  Annex C certainly does.

That editorializing aside, we already have our first examples of collision
between Annex C and specific packages.  Here they are:

 C.1 Echocanc has codepoints for: Off, G.165, G.168.
 E.13 TDMC package has the echo cancellation property with codepoints On and
Off.

 C.1 Gain does not allow negative values (which are needed in practice to
dampen echo)
 E.13 TDMC package gain control property allows positive and negative
values.

There are other examples of duplicate definitions which are at least
consistent.

I propose that the following override to Annex C be added to the
Implementor's Guide:

"Where the same property is defined in Annex C and in a package supported by
both the MGC and the MG, the package definition shall be used in
communications between them."


Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 10:49:49 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03504
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 10:49:49 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0B6032F0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 10:41:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2690 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 10:39:42 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.DBA08920@standards.nortelnetworks.com>; Fri, 2 Jun 2000 10:39:41
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id KAA00968; Fri, 2 Jun 2000 10:47:47 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id KAA05700; Fri, 2 Jun 2000 10:47:49 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <K07X578K>; Fri, 2 Jun 2000 10:47:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678413@whq-msgusr-02.fore.com>
Date:         Fri, 2 Jun 2000 10:47:45 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: MGC-Initiated Control
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It's a potential security problem, because any arbitrary MGC that
stumbles across an otherwise unmarried MG can take it over.  In the
present model the MGC has to be someone you are provisioned to trust,
or someone one of the MGCs you trust told you to trust.

Not a really big deal.  I think the circumstance is so rare as to be
not worth worrying about.  I did think about a circumstance where
the MG lost connectivity to all MGCs.  It went through its list in
vain.  The real correct response, when connectivity is restored, is
to restart the search, and not to have some MGC simply step up and
take it.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Friday, June 02, 2000 9:45 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: MGC-Initiated Control
>
>
> There are cases where an MG will not be able to initiate a
> control session
> (e.g. it has gone through its list of MGCs without success).
> Can we agree
> on principle that an MG that is not currently in a control
> session will
> respond to an MGC-sent ServiceChange command directing it to
> initiate a
> session at a given address?  If so, we could add this to the
> Implementor's
> Guide and our IETF equivalent.
>
> The exact text that would go into the Implementor's Guide would be as
> follows:
>
>         If an MG is not currently in a control association
> with an MGC and
> it receives a ServiceChange command from an authorized source with
> ServiceChangeMethod equal to Handoff, it will attempt to
> initiate a control
> association as directed by that command.  To make this
> possible, an MG not
> currently in a control session shall listen for incoming
> commands at the
> default transport address corresponding to its supported transport and
> encoding (e.g. UDP port 2944 for text-encoded UDP/ALF).
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 11:00:47 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03717
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 11:00:47 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.94FAFC60@standards.nortelnetworks.com>; Fri, 2 Jun 2000 10:52:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2736 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 10:51:27 -0400
Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.805A1250@standards.nortelnetworks.com>; Fri, 2 Jun 2000 10:51:27
          -0400
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by
          sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA12356; Fri, 2
          Jun 2000 07:59:44 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id HAA00367; Fri, 2 Jun 2000 07:59:36 -0700
          (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <C51ED84B6F47D211917A0000F8BCBD110385854D@zcard00g.ca.nortel.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
        @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
        bUcI'1!
Message-ID:  <14647.52184.436828.467676@thomasm-u1.cisco.com>
Date:         Fri, 2 Jun 2000 07:59:36 -0700
Reply-To: Michael Thomas <mat@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael Thomas <mat@CISCO.COM>
Subject:      Re: H.248/BICC discussions
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <C51ED84B6F47D211917A0000F8BCBD110385854D@zcard00g.ca.nortel.com>
Content-Transfer-Encoding: 7bit

Tom-PT Taylor writes:
 > As I noted in a previous posting, our Area Directors have agreed that when
 > it comes to detailed changes to SDP (not involving new principles), Megaco
 > can go ahead and do the job on its own.  MMUSIC, of course, has to be kept
 > informed.
 >
 > While I'm being cooperative with MGCP, that shouldn't get in the way of a
 > logical evolution of the standard.

   It seems that pitting this as MGCP vs MEGACO
   problem is wrongheaded. The real problem with
   H.248 packages "extending" SDP willy-nilly is
   what that does to other SDP aware endpoints.
   If we end up with mutually exclusive varieties
   of SDP where there needs to be some agreement
   on the outer transport layer protocol (MEGACO,
   MGCP, SIP, SAP, etc) then that's a real
   problem. We need to preserve the ability to
   have, say, a H.248 endpoint sources a multicast
   session which is transported to its MGC which sends
   an INVITE to a conference server which sends
   the same SDP announcement out in SAP, etc, etc.
   The SAP receiver shouldn't know or care who
   originated the SDP annoucement.

   If we extend SDP, we should extend SDP in the
   context of MMUSIC to make certain that there
   aren't gratitous collisions. Where the work
   originates from is another matter, but what
   we don't want is "H.248's version of SDP";
   we want "SDP".

           Mike


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 11:06:50 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04089
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 11:06:48 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6BC58EE0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 10:58:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2773 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 10:56:07 -0400
Received: from newdev.harvard.edu (140.247.60.212) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.273C3D50@standards.nortelnetworks.com>; Fri, 2 Jun 2000
          10:56:07 -0400
Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id LAA02644;
          Fri, 2 Jun 2000 11:04:02 -0400 (EDT)
Message-ID:  <200006021504.LAA02644@newdev.harvard.edu>
Date:         Fri, 2 Jun 2000 11:04:02 -0400
Reply-To: Scott Bradner <sob@HARVARD.EDU>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Scott Bradner <sob@HARVARD.EDU>
Subject:      Re: H.248/BICC discussions
X-To:         mat@CISCO.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

   we don't want is "H.248's version of SDP";
   we want "SDP".

fully agree


Scott


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 11:50:52 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05705
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 11:50:51 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.79C5A330@standards.nortelnetworks.com>; Fri, 2 Jun 2000 11:41:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2830 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 11:39:25 -0400
Received: from qhars002.nortel.com (47.101.112.102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.312A72E0@standards.nortelnetworks.com>; Fri, 2 Jun 2000
          11:39:20 -0400
Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com;
          Fri, 2 Jun 2000 16:16:36 +0100
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          smtprich.nortel.com; Fri, 2 Jun 2000 10:03:11 -0500
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Fri, 2 Jun 2000 11:10:49 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <L3HQBDA8>; Fri, 2 Jun 2000 11:10:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCCA4.BA82F752"
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD110385855B@zcard00g.ca.nortel.com>
Date:         Fri, 2 Jun 2000 11:10:45 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: H.248/BICC discussions
X-To:         Michael Thomas <mat@cisco.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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_01BFCCA4.BA82F752
Content-Type: text/plain

You make excellent points and I accept them in principle, meaning that
anything we document in Megaco would be coordinated with MMUSIC as Scott
advised.  The reason for using the Megaco documentation process is because
Megaco is likely to be the earliest consumer of a lot of this work.

RFC 2327 requires RFC documentation to support extensions to SDP.  The
Megaco process provides this.

> -----Original Message-----
> From: Michael Thomas [SMTP:mat@cisco.com]
> Sent: Friday, June 02, 2000 11:00 AM
> To:   Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: H.248/BICC discussions
>
> Tom-PT Taylor writes:
>  > As I noted in a previous posting, our Area Directors have agreed that
> when
>  > it comes to detailed changes to SDP (not involving new principles),
> Megaco
>  > can go ahead and do the job on its own.  MMUSIC, of course, has to be
> kept
>  > informed.
>  >
>  > While I'm being cooperative with MGCP, that shouldn't get in the way of
> a
>  > logical evolution of the standard.
>
>    It seems that pitting this as MGCP vs MEGACO
>    problem is wrongheaded. The real problem with
>    H.248 packages "extending" SDP willy-nilly is
>    what that does to other SDP aware endpoints.
>    If we end up with mutually exclusive varieties
>    of SDP where there needs to be some agreement
>    on the outer transport layer protocol (MEGACO,
>    MGCP, SIP, SAP, etc) then that's a real
>    problem. We need to preserve the ability to
>    have, say, a H.248 endpoint sources a multicast
>    session which is transported to its MGC which sends
>    an INVITE to a conference server which sends
>    the same SDP announcement out in SAP, etc, etc.
>    The SAP receiver shouldn't know or care who
>    originated the SDP annoucement.
>
>    If we extend SDP, we should extend SDP in the
>    context of MMUSIC to make certain that there
>    aren't gratitous collisions. Where the work
>    originates from is another matter, but what
>    we don't want is "H.248's version of SDP";
>    we want "SDP".
>
>          Mike

------_=_NextPart_001_01BFCCA4.BA82F752
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.2651.65">
<TITLE>RE: H.248/BICC discussions</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">You make excellent =
points and I accept them in principle, meaning that anything we =
document in Megaco would be coordinated with MMUSIC as Scott =
advised.&nbsp; The reason for using the Megaco documentation process is =
because Megaco is likely to be the earliest consumer of a lot of this =
work.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">RFC 2327 requires =
RFC documentation to support extensions to SDP.&nbsp; The Megaco =
process provides this.</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Michael Thomas [SMTP:mat@cisco.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, June 02, 2000 11:00 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Taylor, Tom-PT [NORSE:B901:EXCH]</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: H.248/BICC discussions</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Tom-PT Taylor writes:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; As I noted in a previous =
posting, our Area Directors have agreed that when</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; it comes to detailed =
changes to SDP (not involving new principles), Megaco</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; can go ahead and do the =
job on its own.&nbsp; MMUSIC, of course, has to be kept</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; informed.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; While I'm being =
cooperative with MGCP, that shouldn't get in the way of a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; logical evolution of the =
standard.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; It seems that pitting =
this as MGCP vs MEGACO</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; problem is wrongheaded. =
The real problem with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; H.248 packages =
&quot;extending&quot; SDP willy-nilly is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; what that does to other =
SDP aware endpoints.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; If we end up with =
mutually exclusive varieties</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; of SDP where there needs =
to be some agreement</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; on the outer transport =
layer protocol (MEGACO,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; MGCP, SIP, SAP, etc) =
then that's a real</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; problem. We need to =
preserve the ability to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; have, say, a H.248 =
endpoint sources a multicast </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; session which is =
transported to its MGC which sends</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; an INVITE to a =
conference server which sends</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; the same SDP =
announcement out in SAP, etc, etc.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; The SAP receiver =
shouldn't know or care who</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; originated the SDP =
annoucement.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; If we extend SDP, we =
should extend SDP in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; context of MMUSIC to =
make certain that there </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; aren't gratitous =
collisions. Where the work</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; originates from is =
another matter, but what</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; we don't want is =
&quot;H.248's version of SDP&quot;;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; we want =
&quot;SDP&quot;.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp; Mike</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCCA4.BA82F752--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 11:50:52 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05707
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 11:50:52 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.79D18A10@standards.nortelnetworks.com>; Fri, 2 Jun 2000 11:41:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2835 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 11:39:34 -0400
Received: from qhars002.nortel.com (47.101.112.102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.31340FD0@standards.nortelnetworks.com>; Fri, 2 Jun 2000
          11:39:20 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Fri, 2 Jun 2000 16:42:05 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Fri, 2 Jun 2000 10:58:25 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <L3HQBCPL>; Fri, 2 Jun 2000 10:58:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCCA3.012F8DD4"
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1103858558@zcard00g.ca.nortel.com>
Date:         Fri, 2 Jun 2000 10:58:25 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: MGC-Initiated Control
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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_01BFCCA3.012F8DD4
Content-Type: text/plain

I agree with the "potential security problem" -- that's why I said it would
have to be an authorized source.  In what you say below: how does the MG
know that connectivity has been restored?  The ServiceChange command is one
way of doing that.

> -----Original Message-----
> From: Rosen, Brian [SMTP:Brian.Rosen@marconi.com]
> Sent: Friday, June 02, 2000 10:48 AM
> To:   Taylor, Tom-PT [NORSE:B901:EXCH];
> MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      RE: MGC-Initiated Control
>
> It's a potential security problem, because any arbitrary MGC that
> stumbles across an otherwise unmarried MG can take it over.  In the
> present model the MGC has to be someone you are provisioned to trust,
> or someone one of the MGCs you trust told you to trust.
>
> Not a really big deal.  I think the circumstance is so rare as to be
> not worth worrying about.  I did think about a circumstance where
> the MG lost connectivity to all MGCs.  It went through its list in
> vain.  The real correct response, when connectivity is restored, is
> to restart the search, and not to have some MGC simply step up and
> take it.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Friday, June 02, 2000 9:45 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: MGC-Initiated Control
> >
> >
> > There are cases where an MG will not be able to initiate a
> > control session
> > (e.g. it has gone through its list of MGCs without success).
> > Can we agree
> > on principle that an MG that is not currently in a control
> > session will
> > respond to an MGC-sent ServiceChange command directing it to
> > initiate a
> > session at a given address?  If so, we could add this to the
> > Implementor's
> > Guide and our IETF equivalent.
> >
> > The exact text that would go into the Implementor's Guide would be as
> > follows:
> >
> >         If an MG is not currently in a control association
> > with an MGC and
> > it receives a ServiceChange command from an authorized source with
> > ServiceChangeMethod equal to Handoff, it will attempt to
> > initiate a control
> > association as directed by that command.  To make this
> > possible, an MG not
> > currently in a control session shall listen for incoming
> > commands at the
> > default transport address corresponding to its supported transport and
> > encoding (e.g. UDP port 2944 for text-encoded UDP/ALF).
> >
> > Tom Taylor
> > Phone and FAX: +1 613 736 0961
> > E-mail: taylor@nortelnetworks.com
> >

------_=_NextPart_001_01BFCCA3.012F8DD4
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.2651.65">
<TITLE>RE: MGC-Initiated Control</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I agree with the =
&quot;potential security problem&quot; -- that's why I said it would =
have to be an authorized source.&nbsp; In what you say below: how does =
the MG know that connectivity has been restored?&nbsp; The =
ServiceChange command is one way of doing that.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Rosen, Brian =
[SMTP:Brian.Rosen@marconi.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, June 02, 2000 10:48 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Taylor, Tom-PT [NORSE:B901:EXCH]; =
MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: MGC-Initiated Control</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It's a potential security problem, =
because any arbitrary MGC that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">stumbles across an otherwise =
unmarried MG can take it over.&nbsp; In the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">present model the MGC has to be =
someone you are provisioned to trust,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">or someone one of the MGCs you trust =
told you to trust.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Not a really big deal.&nbsp; I think =
the circumstance is so rare as to be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">not worth worrying about.&nbsp; I did =
think about a circumstance where</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the MG lost connectivity to all =
MGCs.&nbsp; It went through its list in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">vain.&nbsp; The real correct =
response, when connectivity is restored, is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to restart the search, and not to =
have some MGC simply step up and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">take it.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Brian</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; From: Tom-PT Taylor =
[<U></U></FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:taylor@NORTELNETWORKS.COM">mailto:taylor@NORTELNETWORKS.C=
OM</A></FONT></U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Sent: Friday, June 02, 2000 9:45 =
AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; To: =
MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Subject: MGC-Initiated =
Control</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; There are cases where an MG will =
not be able to initiate a </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; control session</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; (e.g. it has gone through its =
list of MGCs without success).&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Can we agree</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; on principle that an MG that is =
not currently in a control </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; session will</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; respond to an MGC-sent =
ServiceChange command directing it to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; initiate a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; session at a given =
address?&nbsp; If so, we could add this to the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Implementor's</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Guide and our IETF =
equivalent.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The exact text that would go =
into the Implementor's Guide would be as</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; follows:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If =
an MG is not currently in a control association </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; with an MGC and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; it receives a ServiceChange =
command from an authorized source with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; ServiceChangeMethod equal to =
Handoff, it will attempt to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; initiate a control</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; association as directed by that =
command.&nbsp; To make this </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; possible, an MG not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; currently in a control session =
shall listen for incoming </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; commands at the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; default transport address =
corresponding to its supported transport and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; encoding (e.g. UDP port 2944 for =
text-encoded UDP/ALF).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Tom Taylor</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Phone and FAX: +1 613 736 =
0961</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; E-mail: =
taylor@nortelnetworks.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCCA3.012F8DD4--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 11:50:53 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05714
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 11:50:52 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.79DD70F0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 11:41:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2840 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 11:40:12 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.500EC620@standards.nortelnetworks.com>; Fri, 2 Jun 2000 11:40:12
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id LAA07190; Fri, 2 Jun 2000 11:48:19 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id LAA21778; Fri, 2 Jun 2000 11:48:21 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <K07X50RT>; Fri, 2 Jun 2000 11:48:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCCA9.F9A66838"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678416@whq-msgusr-02.fore.com>
Date:         Fri, 2 Jun 2000 11:48:18 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: MGC-Initiated Control
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

I don't know what "authorized source" would be, unless it was one of the
provisioned MGCs
it had already tried.

It does occur to me that you could add a reason which equated to "start
looking again"
Then any MGC could trigger the MG to start again, if it was in the state you
are positing.

Again, I don't really think this is very important, and I don't feel
strongly negative about your
proposal.

In my connectivity lost scenario, I would have the MG wait and then start
again after some delay,
and I would make the delay backoff exponentially.

Brian

 -----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, June 02, 2000 10:58 AM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: MGC-Initiated Control



I agree with the "potential security problem" -- that's why I said it would
have to be an authorized source.  In what you say below: how does the MG
know that connectivity has been restored?  The ServiceChange command is one
way of doing that.

        -----Original Message-----
From:   Rosen, Brian [SMTP:Brian.Rosen@marconi.com]
Sent:   Friday, June 02, 2000 10:48 AM
To:     Taylor, Tom-PT [NORSE:B901:EXCH];
MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        RE: MGC-Initiated Control

        It's a potential security problem, because any arbitrary MGC that
stumbles across an otherwise unmarried MG can take it over.  In the
present model the MGC has to be someone you are provisioned to trust,
or someone one of the MGCs you trust told you to trust.

        Not a really big deal.  I think the circumstance is so rare as to be

not worth worrying about.  I did think about a circumstance where
the MG lost connectivity to all MGCs.  It went through its list in
vain.  The real correct response, when connectivity is restored, is
to restart the search, and not to have some MGC simply step up and
take it.

        Brian

        > -----Original Message-----
> From: Tom-PT Taylor [ mailto:taylor@NORTELNETWORKS.COM
<mailto:taylor@NORTELNETWORKS.COM> ]
> Sent: Friday, June 02, 2000 9:45 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: MGC-Initiated Control
>
>
> There are cases where an MG will not be able to initiate a
> control session
> (e.g. it has gone through its list of MGCs without success).
> Can we agree
> on principle that an MG that is not currently in a control
> session will
> respond to an MGC-sent ServiceChange command directing it to
> initiate a
> session at a given address?  If so, we could add this to the
> Implementor's
> Guide and our IETF equivalent.
>
> The exact text that would go into the Implementor's Guide would be as
> follows:
>
>         If an MG is not currently in a control association
> with an MGC and
> it receives a ServiceChange command from an authorized source with
> ServiceChangeMethod equal to Handoff, it will attempt to
> initiate a control
> association as directed by that command.  To make this
> possible, an MG not
> currently in a control session shall listen for incoming
> commands at the
> default transport address corresponding to its supported transport and
> encoding (e.g. UDP port 2944 for text-encoded UDP/ALF).
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com
>


------_=_NextPart_001_01BFCCA9.F9A66838
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: MGC-Initiated Control</TITLE>

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970083315-02062000>I
don't know what "authorized source" would be, unless it was one of the
provisioned MGCs</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970083315-02062000>it had
already tried.</SPAN></FONT></DIV>
<DIV><SPAN class=970083315-02062000></SPAN><FONT color=#0000ff face=Arial
size=2>&nbsp;</FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970083315-02062000>It
does occur to me that you could add a reason which equated to "start looking
again"</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970083315-02062000>Then
any MGC could trigger the MG to start again, if it was in the state you are
positing.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=970083315-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970083315-02062000><SPAN
class=910443515-02062000>Again, I don't really think this is very important, and
I don't feel strongly negative about your</SPAN></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970083315-02062000><SPAN
class=910443515-02062000>proposal.</SPAN></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970083315-02062000><SPAN
class=910443515-02062000></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970083315-02062000><SPAN
class=910443515-02062000>In my connectivity lost scenario, I would have the MG
wait and then start again after some delay,</SPAN></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970083315-02062000><SPAN
class=910443515-02062000>and I would make the delay backoff
exponentially.</SPAN></SPAN></FONT></DIV>
<DIV><SPAN class=970083315-02062000></SPAN><FONT color=#0000ff face=Arial
size=2>&nbsp;</FONT></DIV><FONT color=#0000ff><FONT size=2><FONT face=Arial>
<DIV><SPAN class=970083315-02062000>Brian<SPAN
class=910443515-02062000>&nbsp;</SPAN></SPAN></DIV>
<DIV><SPAN class=970083315-02062000><SPAN
class=910443515-02062000></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=970083315-02062000><SPAN
class=910443515-02062000>&nbsp;</SPAN></SPAN></FONT></FONT><FONT
face=Tahoma></FONT><FONT size=2>-----Original Message-----<BR><B>From:</B>
Tom-PT Taylor [mailto:taylor@nortelnetworks.com]<BR><B>Sent:</B> Friday, June
02, 2000 10:58 AM<BR><B>To:</B> Rosen, Brian;
megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: MGC-Initiated
Control<BR><BR></DIV></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"></FONT>
  <P><FONT color=#0000ff face=Arial size=2>I agree with the "potential security
  problem" -- that's why I said it would have to be an authorized source.&nbsp;
  In what you say below: how does the MG know that connectivity has been
  restored?&nbsp; The ServiceChange command is one way of doing that.</FONT></P>
  <UL>
    <P><FONT face=Arial size=1>-----Original Message-----</FONT> <BR><B><FONT
    face=Arial size=1>From:&nbsp;&nbsp;</FONT></B> <FONT face=Arial
    size=1>Rosen, Brian [SMTP:Brian.Rosen@marconi.com]</FONT> <BR><B><FONT
    face=Arial size=1>Sent:&nbsp;&nbsp;</FONT></B> <FONT face=Arial
    size=1>Friday, June 02, 2000 10:48 AM</FONT> <BR><B><FONT face=Arial
    size=1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial
    size=1>Taylor, Tom-PT [NORSE:B901:EXCH];
    MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><B><FONT face=Arial
    size=1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT
    face=Arial size=1>RE: MGC-Initiated Control</FONT> </P>
    <P><FONT face=Arial size=2>It's a potential security problem, because any
    arbitrary MGC that</FONT> <BR><FONT face=Arial size=2>stumbles across an
    otherwise unmarried MG can take it over.&nbsp; In the</FONT> <BR><FONT
    face=Arial size=2>present model the MGC has to be someone you are
    provisioned to trust,</FONT> <BR><FONT face=Arial size=2>or someone one of
    the MGCs you trust told you to trust.</FONT> </P>
    <P><FONT face=Arial size=2>Not a really big deal.&nbsp; I think the
    circumstance is so rare as to be</FONT> <BR><FONT face=Arial size=2>not
    worth worrying about.&nbsp; I did think about a circumstance where</FONT>
    <BR><FONT face=Arial size=2>the MG lost connectivity to all MGCs.&nbsp; It
    went through its list in</FONT> <BR><FONT face=Arial size=2>vain.&nbsp; The
    real correct response, when connectivity is restored, is</FONT> <BR><FONT
    face=Arial size=2>to restart the search, and not to have some MGC simply
    step up and</FONT> <BR><FONT face=Arial size=2>take it.</FONT> </P>
    <P><FONT face=Arial size=2>Brian</FONT> </P>
    <P><FONT face=Arial size=2>&gt; -----Original Message-----</FONT> <BR><FONT
    face=Arial size=2>&gt; From: Tom-PT Taylor [<U></U></FONT><U><FONT
    color=#0000ff face=Arial size=2><A
    href="mailto:taylor@NORTELNETWORKS.COM">mailto:taylor@NORTELNETWORKS.COM</A></FONT></U><FONT
    face=Arial size=2>]</FONT> <BR><FONT face=Arial size=2>&gt; Sent: Friday,
    June 02, 2000 9:45 AM</FONT> <BR><FONT face=Arial size=2>&gt; To:
    MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT face=Arial size=2>&gt;
    Subject: MGC-Initiated Control</FONT> <BR><FONT face=Arial size=2>&gt;
    </FONT><BR><FONT face=Arial size=2>&gt; </FONT><BR><FONT face=Arial
    size=2>&gt; There are cases where an MG will not be able to initiate a
    </FONT><BR><FONT face=Arial size=2>&gt; control session</FONT> <BR><FONT
    face=Arial size=2>&gt; (e.g. it has gone through its list of MGCs without
    success).&nbsp; </FONT><BR><FONT face=Arial size=2>&gt; Can we agree</FONT>
    <BR><FONT face=Arial size=2>&gt; on principle that an MG that is not
    currently in a control </FONT><BR><FONT face=Arial size=2>&gt; session
    will</FONT> <BR><FONT face=Arial size=2>&gt; respond to an MGC-sent
    ServiceChange command directing it to </FONT><BR><FONT face=Arial
    size=2>&gt; initiate a</FONT> <BR><FONT face=Arial size=2>&gt; session at a
    given address?&nbsp; If so, we could add this to the </FONT><BR><FONT
    face=Arial size=2>&gt; Implementor's</FONT> <BR><FONT face=Arial size=2>&gt;
    Guide and our IETF equivalent.</FONT> <BR><FONT face=Arial size=2>&gt;
    </FONT><BR><FONT face=Arial size=2>&gt; The exact text that would go into
    the Implementor's Guide would be as</FONT> <BR><FONT face=Arial size=2>&gt;
    follows:</FONT> <BR><FONT face=Arial size=2>&gt; </FONT><BR><FONT face=Arial
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If an MG is not
    currently in a control association </FONT><BR><FONT face=Arial size=2>&gt;
    with an MGC and</FONT> <BR><FONT face=Arial size=2>&gt; it receives a
    ServiceChange command from an authorized source with</FONT> <BR><FONT
    face=Arial size=2>&gt; ServiceChangeMethod equal to Handoff, it will attempt
    to </FONT><BR><FONT face=Arial size=2>&gt; initiate a control</FONT>
    <BR><FONT face=Arial size=2>&gt; association as directed by that
    command.&nbsp; To make this </FONT><BR><FONT face=Arial size=2>&gt;
    possible, an MG not</FONT> <BR><FONT face=Arial size=2>&gt; currently in a
    control session shall listen for incoming </FONT><BR><FONT face=Arial
    size=2>&gt; commands at the</FONT> <BR><FONT face=Arial size=2>&gt; default
    transport address corresponding to its supported transport and</FONT>
    <BR><FONT face=Arial size=2>&gt; encoding (e.g. UDP port 2944 for
    text-encoded UDP/ALF).</FONT> <BR><FONT face=Arial size=2>&gt;
    </FONT><BR><FONT face=Arial size=2>&gt; Tom Taylor</FONT> <BR><FONT
    face=Arial size=2>&gt; Phone and FAX: +1 613 736 0961</FONT> <BR><FONT
    face=Arial size=2>&gt; E-mail: taylor@nortelnetworks.com</FONT> <BR><FONT
    face=Arial size=2>&gt; </FONT></P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFCCA9.F9A66838--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 11:54:42 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05855
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 11:54:41 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C43B11C0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 11:43:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2853 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 11:41:48 -0400
Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.890942C0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 11:41:48
          -0400
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by
          sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA22793; Fri, 2
          Jun 2000 08:50:06 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id IAA00374; Fri, 2 Jun 2000 08:49:57 -0700
          (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4FBEA8857476D311A03300204840E1CF678413@whq-msgusr-02.fore.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
        @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
        bUcI'1!
Message-ID:  <14647.55205.590753.795398@thomasm-u1.cisco.com>
Date:         Fri, 2 Jun 2000 08:49:57 -0700
Reply-To: Michael Thomas <mat@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael Thomas <mat@CISCO.COM>
Subject:      Re: MGC-Initiated Control
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF678413@whq-msgusr-02.fore.com>
Content-Transfer-Encoding: 7bit

Rosen, Brian writes:
 > It's a potential security problem, because any arbitrary MGC that
 > stumbles across an otherwise unmarried MG can take it over.  In the
 > present model the MGC has to be someone you are provisioned to trust,
 > or someone one of the MGCs you trust told you to trust.

   I wouldn't think that that should be a problem
   if you require an SA to be established first.
   Regardless of which side initiates the SA, you
   still need to authenticate the remote side to
   determine whether they are who they claim they
   are.

                Mike


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 12:40:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06969
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 12:40:19 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7EDC6AA0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 12:31:37 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3036 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 12:30:00 -0400
Received: from qhars002.nortel.com (47.101.112.102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.44C189E0@standards.nortelnetworks.com>; Fri, 2 Jun 2000
          12:30:00 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Fri, 2 Jun 2000 17:34:22 +0100
Received: from zcard015.ca.nortel.com (actually zcard015) by
          ertpg14e1.nortelnetworks.com; Fri, 2 Jun 2000 12:00:38 -0400
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id L1WNPVM8; Fri, 2 Jun 2000 12:00:41
          -0400
Received: from americasm10.nt.com (pnc1d070.us.nortel.com [47.142.209.170]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id LQ815884; Fri, 2 Jun 2000 12:00:39
          -0400
X-Sybari-Space: 00000000 00000000 00000000
X-Sender: "Sophia Scoggins" <scoggins@zrtpd00z>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678414@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3937DA2A.9B6CF4CA@americasm10.nt.com>
Date:         Fri, 2 Jun 2000 12:00:42 -0400
Reply-To: Sophia Scoggins <scoggins@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sophia Scoggins <scoggins@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: H.248/BICC discussions
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
X-cc:         Mark Watson <mwatson@nortelnetworks.com>,
              "Christian.Groves@ericsson.com" <Christian.Groves@ericsson.com>,
              "tsg11bicc@ties.itu.int" <tsg11bicc@ties.itu.ch>,
              megaco-interop@fore.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

It would be better that we have just one cohesive coding mechanism to
carry information end-to-end for all MGCs and MGs.

There are indeed too many parameters in the Annex C. I am not sure if
many of them will ever be used. Somewhere I heard or saw that the
average length of SDP messages is only 60 bytes. How much of info do we
really want to carry in the SDP? Many of the Q.9XX parameters need not
to carry through the path MG --> MGC --> MGC --> MG. ISUP trunks would
be choking by large packets -- SIP has less issues with big packets.

However, in Nortel's contribution to SG11, we have identified two
parameters that are needed but not included in the Annex C:

-- eecid or bnc-id (this is included in Rajesh Kumar's ATM SDP)
-- use RTCP or not (RTCP is optional to RTP. We need to specify to use
RTCP or not.)


Regards, SOphia


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 14:03:40 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08678
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 14:03:40 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1AF69220@standards.nortelnetworks.com>; Fri, 2 Jun 2000 13:54:43 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3172 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 13:53:42 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.90530B40@standards.nortelnetworks.com>; Fri, 2 Jun 2000 13:43:41
          -0400
Received: from cisco.com (rtp-dial-2-45.cisco.com [10.83.96.45]) by
          mailman.cisco.com (8.9.3/8.9.1) with ESMTP id KAA02696; Fri, 2 Jun
          2000 10:51:45 -0700 (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678413@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3937F4F0.224AA713@cisco.com>
Date:         Fri, 2 Jun 2000 13:54:56 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Subject:      Re: MGC-Initiated Control
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:

> It's a potential security problem, because any arbitrary MGC that
> stumbles across an otherwise unmarried MG can take it over.  In the
> present model the MGC has to be someone you are provisioned to trust,
> or someone one of the MGCs you trust told you to trust.

Are you saying that the protocol does not allow an MG to talk to an MGC
that's not part of a pre-provisioned list of MGCs, or are you simply
referring to proper security credentials being presented ?

-- Flemming



>
>
> Not a really big deal.  I think the circumstance is so rare as to be
> not worth worrying about.  I did think about a circumstance where
> the MG lost connectivity to all MGCs.  It went through its list in
> vain.  The real correct response, when connectivity is restored, is
> to restart the search, and not to have some MGC simply step up and
> take it.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Friday, June 02, 2000 9:45 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: MGC-Initiated Control
> >
> >
> > There are cases where an MG will not be able to initiate a
> > control session
> > (e.g. it has gone through its list of MGCs without success).
> > Can we agree
> > on principle that an MG that is not currently in a control
> > session will
> > respond to an MGC-sent ServiceChange command directing it to
> > initiate a
> > session at a given address?  If so, we could add this to the
> > Implementor's
> > Guide and our IETF equivalent.
> >
> > The exact text that would go into the Implementor's Guide would be as
> > follows:
> >
> >         If an MG is not currently in a control association
> > with an MGC and
> > it receives a ServiceChange command from an authorized source with
> > ServiceChangeMethod equal to Handoff, it will attempt to
> > initiate a control
> > association as directed by that command.  To make this
> > possible, an MG not
> > currently in a control session shall listen for incoming
> > commands at the
> > default transport address corresponding to its supported transport and
> > encoding (e.g. UDP port 2944 for text-encoded UDP/ALF).
> >
> > Tom Taylor
> > Phone and FAX: +1 613 736 0961
> > E-mail: taylor@nortelnetworks.com
> >

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 14:13:33 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08892
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 14:13:31 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8109BF00@standards.nortelnetworks.com>; Fri, 2 Jun 2000 14:04:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3178 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 14:03:37 -0400
Received: from qhars002.nortel.com (47.101.112.102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F08F50D0@standards.nortelnetworks.com>; Fri, 2 Jun 2000
          13:53:32 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Fri, 2 Jun 2000 19:01:18 +0100
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprch1.nortel.com; Fri, 2 Jun 2000 12:53:22 -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id L1WNPV06; Fri, 2 Jun 2000 13:53:18
          -0400
Received: from americasm10.nt.com (pnc1m006.us.nortel.com [47.142.208.218]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id LQ8159GD; Fri, 2 Jun 2000 13:53:16
          -0400
X-Sybari-Space: 00000000 00000000 00000000
X-Sender: "Brown, Michael [NC1:3T19:EXCH]" <mahubard@zrtpd00z>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678413@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3937F5A8.6583BB46@americasm10.nt.com>
Date:         Fri, 2 Jun 2000 13:58:01 -0400
Reply-To: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: MGC-Initiated Control
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I agree with the overall response, because the protocol doesn't specifically
prohibit it but had one other thought about the proposal.

The question I have is how the new MGC would know that the MG is
"stranded".  What is  the mechanism that would be used to trigger an MGC to
initiate the connection in the first place?  The MGC has to know somehow
that it is supposed to initiate control. This to me implies that some
network management function identifies the MG as stranded and then messages
to the MGC telling it to initiate the control handoff. If that's the case,
why wouldn't the NM function just tell the gateway to add the new MGC to its
list and then the model for initiating the control association doesn't
change.

As mentioned though, I don't suppose it really matters too much since the
trigger mechanism is outside the scope of Megaco and the protocol doesn't
prohibit the suggested behavior.

Mike

"Rosen, Brian" wrote:

> It's a potential security problem, because any arbitrary MGC that
> stumbles across an otherwise unmarried MG can take it over.  In the
> present model the MGC has to be someone you are provisioned to trust,
> or someone one of the MGCs you trust told you to trust.
>
> Not a really big deal.  I think the circumstance is so rare as to be
> not worth worrying about.  I did think about a circumstance where
> the MG lost connectivity to all MGCs.  It went through its list in
> vain.  The real correct response, when connectivity is restored, is
> to restart the search, and not to have some MGC simply step up and
> take it.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Friday, June 02, 2000 9:45 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: MGC-Initiated Control
> >
> >
> > There are cases where an MG will not be able to initiate a
> > control session
> > (e.g. it has gone through its list of MGCs without success).
> > Can we agree
> > on principle that an MG that is not currently in a control
> > session will
> > respond to an MGC-sent ServiceChange command directing it to
> > initiate a
> > session at a given address?  If so, we could add this to the
> > Implementor's
> > Guide and our IETF equivalent.
> >
> > The exact text that would go into the Implementor's Guide would be as
> > follows:
> >
> >         If an MG is not currently in a control association
> > with an MGC and
> > it receives a ServiceChange command from an authorized source with
> > ServiceChangeMethod equal to Handoff, it will attempt to
> > initiate a control
> > association as directed by that command.  To make this
> > possible, an MG not
> > currently in a control session shall listen for incoming
> > commands at the
> > default transport address corresponding to its supported transport and
> > encoding (e.g. UDP port 2944 for text-encoded UDP/ALF).
> >
> > Tom Taylor
> > Phone and FAX: +1 613 736 0961
> > E-mail: taylor@nortelnetworks.com
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 14:34:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09328
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 14:34:54 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2C844BF0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 14:23:51 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3332 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 14:22:01 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.EACFEC50@standards.nortelnetworks.com>; Fri, 2 Jun 2000 14:22:01
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id OAA23331; Fri, 2 Jun 2000 14:30:07 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id OAA07788; Fri, 2 Jun 2000 14:30:10 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <K07X6258>; Fri, 2 Jun 2000 14:30:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678419@whq-msgusr-02.fore.com>
Date:         Fri, 2 Jun 2000 14:29:59 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: MGC-Initiated Control
X-To:         Flemming Andreasen <fandreas@cisco.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

As the protocol is documented now, it is true that an MG could not
establish an association with an MGC not on it's pre-provisioned
list.

Tom's suggestion undoes this restriction, but it would only take
effect if none of the preprovisioned MGCs would accept the MG
for service.

Brian

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Friday, June 02, 2000 1:55 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: MGC-Initiated Control
>
>
>
>
> "Rosen, Brian" wrote:
>
> > It's a potential security problem, because any arbitrary MGC that
> > stumbles across an otherwise unmarried MG can take it over.  In the
> > present model the MGC has to be someone you are provisioned
> to trust,
> > or someone one of the MGCs you trust told you to trust.
>
> Are you saying that the protocol does not allow an MG to talk
> to an MGC
> that's not part of a pre-provisioned list of MGCs, or are you simply
> referring to proper security credentials being presented ?
>
> -- Flemming
>
>
>
> >
> >
> > Not a really big deal.  I think the circumstance is so rare as to be
> > not worth worrying about.  I did think about a circumstance where
> > the MG lost connectivity to all MGCs.  It went through its list in
> > vain.  The real correct response, when connectivity is restored, is
> > to restart the search, and not to have some MGC simply step up and
> > take it.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > > Sent: Friday, June 02, 2000 9:45 AM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: MGC-Initiated Control
> > >
> > >
> > > There are cases where an MG will not be able to initiate a
> > > control session
> > > (e.g. it has gone through its list of MGCs without success).
> > > Can we agree
> > > on principle that an MG that is not currently in a control
> > > session will
> > > respond to an MGC-sent ServiceChange command directing it to
> > > initiate a
> > > session at a given address?  If so, we could add this to the
> > > Implementor's
> > > Guide and our IETF equivalent.
> > >
> > > The exact text that would go into the Implementor's Guide
> would be as
> > > follows:
> > >
> > >         If an MG is not currently in a control association
> > > with an MGC and
> > > it receives a ServiceChange command from an authorized source with
> > > ServiceChangeMethod equal to Handoff, it will attempt to
> > > initiate a control
> > > association as directed by that command.  To make this
> > > possible, an MG not
> > > currently in a control session shall listen for incoming
> > > commands at the
> > > default transport address corresponding to its supported
> transport and
> > > encoding (e.g. UDP port 2944 for text-encoded UDP/ALF).
> > >
> > > Tom Taylor
> > > Phone and FAX: +1 613 736 0961
> > > E-mail: taylor@nortelnetworks.com
> > >
>
> --
> Flemming Andreasen                Phone: +1 732 452 1667
> Cisco Systems                     Fax:   +1 240 359 5839
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 14:34:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09330
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 14:34:56 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2C9032D0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 14:23:51 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3337 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 14:22:42 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.03662C70@standards.nortelnetworks.com>; Fri, 2 Jun 2000 14:22:42
          -0400
Received: from aiglos.trillium.com (unverified) by turin.trillium.com (Content
          Technologies SMTPRS 4.1.5) with ESMTP id
          <Tced86cda834c8da8cab2@turin.trillium.com>; Fri, 2 Jun 2000 11:42:43
          -0700
Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by
          aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id LAA05949; Fri, 2 Jun
          2000 11:30:35 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <LSLFY6NF>; Fri, 2 Jun 2000 11:29:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCCC0.7594A048"
Message-ID:  <8BBD33A986C5D311804000902719FF5D320118@aega.trillium.com>
Date:         Fri, 2 Jun 2000 11:29:16 -0700
Reply-To: Bharat Kaul <bharat@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Bharat Kaul <bharat@TRILLIUM.COM>
Subject:      Re: MGC-Initiated Control
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

I was under the impression till now that, in principle, it will always be an
MG initiating a conversation with the MGC.

In TCP world it implied MG establishes connection with the MGC and sent a
ServiceChange command (and thereby negating the need to have a listening
server in MG).....Right ?

In UDP world, life was simpler but still MG initiates the conversation with
the MGC by sending a ServiceChange.

If my understanding is wrong, I would appreciate clarifications.

Assuming my understanding is wrong, then with the approach suggested there
are a couple of issues listed below

1. In principle, MGC are not supposed to knowing unmarried MG's. If so, then
how does MGC sending the ServiceChange figure out that the MG is unmarried ?
The only option seems network management. And then it can be argued that
network management can also intervene on MG side and make MG initiate
conversation with a new MGC.

2. Additionally, it enforces that MGC contacting the MG should now know the
encoding schemes supported at the MG ..how does MGC figure that out ?

3. Also, do people on here expect MG's to be using both TCP and UDP
simulataneously for communication to MGC. I would think that an MG will
choose either one. If that is true, then how will the contacting MGC in
suggested approach pick transport type.

Thanks
Bharat

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Friday, June 02, 2000 8:48 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: MGC-Initiated Control


I don't know what "authorized source" would be, unless it was one of the
provisioned MGCs
it had already tried.

It does occur to me that you could add a reason which equated to "start
looking again"
Then any MGC could trigger the MG to start again, if it was in the state you
are positing.

Again, I don't really think this is very important, and I don't feel
strongly negative about your
proposal.

In my connectivity lost scenario, I would have the MG wait and then start
again after some delay,
and I would make the delay backoff exponentially.


Brian

 -----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, June 02, 2000 10:58 AM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: MGC-Initiated Control



I agree with the "potential security problem" -- that's why I said it would
have to be an authorized source.  In what you say below: how does the MG
know that connectivity has been restored?  The ServiceChange command is one
way of doing that.

        -----Original Message-----
From:   Rosen, Brian [SMTP:Brian.Rosen@marconi.com]
Sent:   Friday, June 02, 2000 10:48 AM
To:     Taylor, Tom-PT [NORSE:B901:EXCH];
MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        RE: MGC-Initiated Control

        It's a potential security problem, because any arbitrary MGC that
stumbles across an otherwise unmarried MG can take it over.  In the
present model the MGC has to be someone you are provisioned to trust,
or someone one of the MGCs you trust told you to trust.

        Not a really big deal.  I think the circumstance is so rare as to be

not worth worrying about.  I did think about a circumstance where
the MG lost connectivity to all MGCs.  It went through its list in
vain.  The real correct response, when connectivity is restored, is
to restart the search, and not to have some MGC simply step up and
take it.

        Brian

        > -----Original Message-----
> From: Tom-PT Taylor [ mailto:taylor@NORTELNETWORKS.COM
<mailto:taylor@NORTELNETWORKS.COM> ]
> Sent: Friday, June 02, 2000 9:45 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: MGC-Initiated Control
>
>
> There are cases where an MG will not be able to initiate a
> control session
> (e.g. it has gone through its list of MGCs without success).
> Can we agree
> on principle that an MG that is not currently in a control
> session will
> respond to an MGC-sent ServiceChange command directing it to
> initiate a
> session at a given address?  If so, we could add this to the
> Implementor's
> Guide and our IETF equivalent.
>
> The exact text that would go into the Implementor's Guide would be as
> follows:
>
>         If an MG is not currently in a control association
> with an MGC and
> it receives a ServiceChange command from an authorized source with
> ServiceChangeMethod equal to Handoff, it will attempt to
> initiate a control
> association as directed by that command.  To make this
> possible, an MG not
> currently in a control session shall listen for incoming
> commands at the
> default transport address corresponding to its supported transport and
> encoding (e.g. UDP port 2944 for text-encoded UDP/ALF).
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com
>


------_=_NextPart_001_01BFCCC0.7594A048
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: MGC-Initiated Control</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=100260918-02062000>I was
under the impression till now that, in&nbsp;principle, it will always be an MG
initiating a conversation with the MGC. </SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=100260918-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=100260918-02062000>In TCP
world it implied MG establishes connection with the MGC and sent a ServiceChange
command (and thereby negating the need to have a listening server in
MG).....Right ?</SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=100260918-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=100260918-02062000>In UDP
world, life was simpler but still MG initiates the conversation with the MGC by
sending a ServiceChange.</SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=100260918-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=100260918-02062000>If my
understanding is wrong, I would appreciate clarifications.</SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=100260918-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=100260918-02062000>Assuming my understanding is wrong, then with the
approach suggested there are a couple of issues listed below</SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=100260918-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=100260918-02062000>1. In
principle, MGC are not supposed to knowing unmarried MG's. If so, then how does
MGC sending the ServiceChange figure out that the MG is unmarried ? The only
option seems network management. And then it can be argued that network
management can also intervene on MG side and make MG initiate conversation with
a new MGC.</SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=100260918-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=100260918-02062000>2.&nbsp;Additionally, it enforces that MGC contacting
the MG should now know the encoding schemes supported at the MG ..how does MGC
figure that out ?&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=100260918-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=100260918-02062000>3.
Also, do&nbsp;people on here expect MG's to be using both TCP and UDP
simulataneously for communication to MGC. I would think that an MG will choose
either one. If that is true, then how will the contacting MGC in suggested
approach pick transport type.</SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=100260918-02062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=100260918-02062000>Thanks</SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=100260918-02062000>Bharat</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Rosen, Brian
  [mailto:Brian.Rosen@MARCONI.COM]<BR><B>Sent:</B> Friday, June 02, 2000 8:48
  AM<BR><B>To:</B> MEGACO@standards.nortelnetworks.com<BR><B>Subject:</B> Re:
  MGC-Initiated Control<BR><BR></DIV></FONT>
  <DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970083315-02062000>I
  don't know what "authorized source" would be, unless it was one of the
  provisioned MGCs</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970083315-02062000>it
  had already tried.</SPAN></FONT></DIV>
  <DIV><SPAN class=970083315-02062000></SPAN><FONT color=#0000ff face=Arial
  size=2>&nbsp;</FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970083315-02062000>It
  does occur to me that you could add a reason which equated to "start looking
  again"</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970083315-02062000>Then
  any MGC could trigger the MG to start again, if it was in the state you are
  positing.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=970083315-02062000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=970083315-02062000><SPAN class=910443515-02062000>Again, I don't really
  think this is very important, and I don't feel strongly negative about
  your</SPAN></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=970083315-02062000><SPAN
  class=910443515-02062000>proposal.</SPAN></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=970083315-02062000><SPAN
  class=910443515-02062000></SPAN></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=970083315-02062000><SPAN class=910443515-02062000>In my connectivity
  lost scenario, I would have the MG wait and then start again after some
  delay,</SPAN></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=970083315-02062000><SPAN class=910443515-02062000>and I would make the
  delay backoff exponentially.</SPAN></SPAN></FONT></DIV>
  <DIV><SPAN class=970083315-02062000></SPAN><FONT color=#0000ff face=Arial
  size=2>&nbsp;</FONT></DIV><FONT color=#0000ff><FONT size=2><FONT face=Arial>
  <DIV><SPAN class=970083315-02062000>Brian<SPAN
  class=910443515-02062000>&nbsp;</SPAN></SPAN></DIV>
  <DIV><SPAN class=970083315-02062000><SPAN
  class=910443515-02062000></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=970083315-02062000><SPAN
  class=910443515-02062000>&nbsp;</SPAN></SPAN></FONT></FONT><FONT
  face=Tahoma></FONT><FONT size=2>-----Original Message-----<BR><B>From:</B>
  Tom-PT Taylor [mailto:taylor@nortelnetworks.com]<BR><B>Sent:</B> Friday, June
  02, 2000 10:58 AM<BR><B>To:</B> Rosen, Brian;
  megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: MGC-Initiated
  Control<BR><BR></DIV></FONT></DIV>
  <BLOCKQUOTE
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"></FONT>
    <P><FONT color=#0000ff face=Arial size=2>I agree with the "potential
    security problem" -- that's why I said it would have to be an authorized
    source.&nbsp; In what you say below: how does the MG know that connectivity
    has been restored?&nbsp; The ServiceChange command is one way of doing
    that.</FONT></P>
    <UL>
      <P><FONT face=Arial size=1>-----Original Message-----</FONT> <BR><B><FONT
      face=Arial size=1>From:&nbsp;&nbsp;</FONT></B> <FONT face=Arial
      size=1>Rosen, Brian [SMTP:Brian.Rosen@marconi.com]</FONT> <BR><B><FONT
      face=Arial size=1>Sent:&nbsp;&nbsp;</FONT></B> <FONT face=Arial
      size=1>Friday, June 02, 2000 10:48 AM</FONT> <BR><B><FONT face=Arial
      size=1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial
      size=1>Taylor, Tom-PT [NORSE:B901:EXCH];
      MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><B><FONT face=Arial
      size=1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT
      face=Arial size=1>RE: MGC-Initiated Control</FONT> </P>
      <P><FONT face=Arial size=2>It's a potential security problem, because any
      arbitrary MGC that</FONT> <BR><FONT face=Arial size=2>stumbles across an
      otherwise unmarried MG can take it over.&nbsp; In the</FONT> <BR><FONT
      face=Arial size=2>present model the MGC has to be someone you are
      provisioned to trust,</FONT> <BR><FONT face=Arial size=2>or someone one of
      the MGCs you trust told you to trust.</FONT> </P>
      <P><FONT face=Arial size=2>Not a really big deal.&nbsp; I think the
      circumstance is so rare as to be</FONT> <BR><FONT face=Arial size=2>not
      worth worrying about.&nbsp; I did think about a circumstance where</FONT>
      <BR><FONT face=Arial size=2>the MG lost connectivity to all MGCs.&nbsp; It
      went through its list in</FONT> <BR><FONT face=Arial size=2>vain.&nbsp;
      The real correct response, when connectivity is restored, is</FONT>
      <BR><FONT face=Arial size=2>to restart the search, and not to have some
      MGC simply step up and</FONT> <BR><FONT face=Arial size=2>take it.</FONT>
      </P>
      <P><FONT face=Arial size=2>Brian</FONT> </P>
      <P><FONT face=Arial size=2>&gt; -----Original Message-----</FONT>
      <BR><FONT face=Arial size=2>&gt; From: Tom-PT Taylor
      [<U></U></FONT><U><FONT color=#0000ff face=Arial size=2><A
      href="mailto:taylor@NORTELNETWORKS.COM">mailto:taylor@NORTELNETWORKS.COM</A></FONT></U><FONT
      face=Arial size=2>]</FONT> <BR><FONT face=Arial size=2>&gt; Sent: Friday,
      June 02, 2000 9:45 AM</FONT> <BR><FONT face=Arial size=2>&gt; To:
      MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT face=Arial
      size=2>&gt; Subject: MGC-Initiated Control</FONT> <BR><FONT face=Arial
      size=2>&gt; </FONT><BR><FONT face=Arial size=2>&gt; </FONT><BR><FONT
      face=Arial size=2>&gt; There are cases where an MG will not be able to
      initiate a </FONT><BR><FONT face=Arial size=2>&gt; control session</FONT>
      <BR><FONT face=Arial size=2>&gt; (e.g. it has gone through its list of
      MGCs without success).&nbsp; </FONT><BR><FONT face=Arial size=2>&gt; Can
      we agree</FONT> <BR><FONT face=Arial size=2>&gt; on principle that an MG
      that is not currently in a control </FONT><BR><FONT face=Arial size=2>&gt;
      session will</FONT> <BR><FONT face=Arial size=2>&gt; respond to an
      MGC-sent ServiceChange command directing it to </FONT><BR><FONT face=Arial
      size=2>&gt; initiate a</FONT> <BR><FONT face=Arial size=2>&gt; session at
      a given address?&nbsp; If so, we could add this to the </FONT><BR><FONT
      face=Arial size=2>&gt; Implementor's</FONT> <BR><FONT face=Arial
      size=2>&gt; Guide and our IETF equivalent.</FONT> <BR><FONT face=Arial
      size=2>&gt; </FONT><BR><FONT face=Arial size=2>&gt; The exact text that
      would go into the Implementor's Guide would be as</FONT> <BR><FONT
      face=Arial size=2>&gt; follows:</FONT> <BR><FONT face=Arial size=2>&gt;
      </FONT><BR><FONT face=Arial
      size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If an MG is
      not currently in a control association </FONT><BR><FONT face=Arial
      size=2>&gt; with an MGC and</FONT> <BR><FONT face=Arial size=2>&gt; it
      receives a ServiceChange command from an authorized source with</FONT>
      <BR><FONT face=Arial size=2>&gt; ServiceChangeMethod equal to Handoff, it
      will attempt to </FONT><BR><FONT face=Arial size=2>&gt; initiate a
      control</FONT> <BR><FONT face=Arial size=2>&gt; association as directed by
      that command.&nbsp; To make this </FONT><BR><FONT face=Arial size=2>&gt;
      possible, an MG not</FONT> <BR><FONT face=Arial size=2>&gt; currently in a
      control session shall listen for incoming </FONT><BR><FONT face=Arial
      size=2>&gt; commands at the</FONT> <BR><FONT face=Arial size=2>&gt;
      default transport address corresponding to its supported transport
      and</FONT> <BR><FONT face=Arial size=2>&gt; encoding (e.g. UDP port 2944
      for text-encoded UDP/ALF).</FONT> <BR><FONT face=Arial size=2>&gt;
      </FONT><BR><FONT face=Arial size=2>&gt; Tom Taylor</FONT> <BR><FONT
      face=Arial size=2>&gt; Phone and FAX: +1 613 736 0961</FONT> <BR><FONT
      face=Arial size=2>&gt; E-mail: taylor@nortelnetworks.com</FONT> <BR><FONT
      face=Arial size=2>&gt; </FONT></P></UL></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFCCC0.7594A048--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 15:31:44 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11410
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 15:31:43 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6F5608D0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 15:22:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3778 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 15:21:13 -0400
Received: from newdev.harvard.edu (140.247.60.212) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.2FEE7F60@standards.nortelnetworks.com>; Fri, 2 Jun 2000
          15:21:13 -0400
Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id PAA03414;
          Fri, 2 Jun 2000 15:29:02 -0400 (EDT)
Message-ID:  <200006021929.PAA03414@newdev.harvard.edu>
Date:         Fri, 2 Jun 2000 15:29:02 -0400
Reply-To: Scott Bradner <sob@HARVARD.EDU>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Scott Bradner <sob@HARVARD.EDU>
Subject:      Re: H.248/BICC discussions
X-To:         Brian.Rosen@MARCONI.COM
X-cc:         mankin@isi.edu
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> Well, I'm having a problem with the idea that a package can extend SDP.

SDP is designed to be extensible - it is reasonable for other IETF working
groups to suggest extensions, the mmusic WG should be in the loop during
the discussions but having the group that has the best knowledge of
what the extensions are for be in the drivers seat means it is more
likly to get done in a reasonable period of time - mmusic can provide
feedback if they think that the proposed extensions run counter to the
SDP design goals or feel that there is a better way to do the function.

Scott


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 16:00:42 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11954
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 16:00:42 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7D5E9380@standards.nortelnetworks.com>; Fri, 2 Jun 2000 15:52:00 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3878 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 15:50:20 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.418A9110@standards.nortelnetworks.com>; Fri, 2 Jun 2000 15:50:20
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id PAA03343; Fri, 2 Jun 2000 15:58:27 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id PAA13746; Fri, 2 Jun 2000 15:58:27 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <K07X6M20>; Fri, 2 Jun 2000 15:58:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678420@whq-msgusr-02.fore.com>
Date:         Fri, 2 Jun 2000 15:57:57 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: H.248/BICC discussions
X-To:         Scott Bradner <sob@harvard.edu>
X-cc:         mankin@isi.edu
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It's not the idea that Megaco can extend SDP with MMUSIC in the loop.
It's whether the form to do this is a package.  It's probably all
in the details.

I agree that Tom's basic premise, that a Megaco sponsored standards
track RFC that defines an extension is a perfectly appropriate way
to define an extension.  The package mechanism is defined as pretty
general, and of course is useable by parties other than the IETF (as
is the SDP extension mechanism).  If we made such a decision than
anyone could come along, define a megaco package that added a media
parameter, and have the result be an extension to SDP.

Now, it's certainly true that anyone can define an extension to SDP
by just doing an IANA registration of a tag, so this isn't very much
different, it's just that doing it as a Megaco package makes the SDP
extension indirect -- is that what we want?

Consider the alternative - what we are doing now.  We are writing
an I-D, with the intention of getting it published as an MMUSIC RFC
that defines an ATM extension to SDP.  Then we have another I-D that will be
published as a Megaco RFC that defines a Megaco package using that
SDP extension.  We also have an MGCP package, but that is outside the
scope of this discussion at the moment.  Is that not a preferable way
to get the job done?

Brian

> -----Original Message-----
> From: Scott Bradner [mailto:sob@harvard.edu]
> Sent: Friday, June 02, 2000 3:29 PM
> To: Rosen, Brian
> Cc: mankin@isi.edu; megaco@standards.nortelnetworks.com
> Subject: Re: H.248/BICC discussions
>
>
> > Well, I'm having a problem with the idea that a package can
> extend SDP.
>
> SDP is designed to be extensible - it is reasonable for other
> IETF working
> groups to suggest extensions, the mmusic WG should be in the
> loop during
> the discussions but having the group that has the best knowledge of
> what the extensions are for be in the drivers seat means it is more
> likly to get done in a reasonable period of time - mmusic can provide
> feedback if they think that the proposed extensions run
> counter to the
> SDP design goals or feel that there is a better way to do the
> function.
>
> Scott
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  2 17:54:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15666
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 2 Jun 2000 17:54:10 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6A79E520@standards.nortelnetworks.com>; Fri, 2 Jun 2000 17:46:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4018 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 17:44:21 -0400
Received: from qhars002.nortel.com (47.101.112.102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.2740E150@standards.nortelnetworks.com>; Fri, 2 Jun 2000
          17:44:08 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Fri, 2 Jun 2000 22:47:13 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Fri, 2 Jun 2000 17:12:39 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <L3HQBQHP>; Fri, 2 Jun 2000 17:12:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCCD7.488D4AFC"
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1103858566@zcard00g.ca.nortel.com>
Date:         Fri, 2 Jun 2000 17:12:37 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: MGC-Initiated Control
X-To:         Bharat Kaul <bharat@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

First, let me apologize for never completing a response to your queries in
March.  My response sat half-finished on my machine until my hard drive
died, and then it seemed a bit late to say anything.

Agreed that I am proposing a change in that the MG would have to listen when
not in a control session.  It is up to the list to decide whether this is an
acceptable solution to a potential problem.

On your further questions:

(1) There may be network situations where network management is able to
contact the MGC but not the MG (e.g. when they have different owners.

(2) and (3) There is no intention of forcing the MG to support multiple
transports or multiple coding schemes.  Assuming that the MGC knows through
network management that the MG needs a controller and that it (the MGC)
should be the one, it could try all possibilities until it gets a response,
or it could have cached the necessary information from an earlier control
session, or it may know what it has to from network management.  This is an
implementation detail.

> -----Original Message-----
> From: Bharat Kaul [SMTP:bharat@TRILLIUM.COM]
> Sent: Friday, June 02, 2000 2:29 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: MGC-Initiated Control
>
> I was under the impression till now that, in principle, it will always be
> an MG initiating a conversation with the MGC.
>
> In TCP world it implied MG establishes connection with the MGC and sent a
> ServiceChange command (and thereby negating the need to have a listening
> server in MG).....Right ?
>
> In UDP world, life was simpler but still MG initiates the conversation
> with the MGC by sending a ServiceChange.
>
> If my understanding is wrong, I would appreciate clarifications.
>
> Assuming my understanding is wrong, then with the approach suggested there
> are a couple of issues listed below
>
> 1. In principle, MGC are not supposed to knowing unmarried MG's. If so,
> then how does MGC sending the ServiceChange figure out that the MG is
> unmarried ? The only option seems network management. And then it can be
> argued that network management can also intervene on MG side and make MG
> initiate conversation with a new MGC.
>
> 2. Additionally, it enforces that MGC contacting the MG should now know
> the encoding schemes supported at the MG ..how does MGC figure that out ?
>
> 3. Also, do people on here expect MG's to be using both TCP and UDP
> simulataneously for communication to MGC. I would think that an MG will
> choose either one. If that is true, then how will the contacting MGC in
> suggested approach pick transport type.
>
> Thanks
> Bharat
>
>       -----Original Message-----
>       From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
>       Sent: Friday, June 02, 2000 8:48 AM
>       To: MEGACO@standards.nortelnetworks.com
>       Subject: Re: MGC-Initiated Control
>
>
>       I don't know what "authorized source" would be, unless it was one of
> the provisioned MGCs
>       it had already tried.
>
>       It does occur to me that you could add a reason which equated to
> "start looking again"
>       Then any MGC could trigger the MG to start again, if it was in the
> state you are positing.
>
>       Again, I don't really think this is very important, and I don't feel
> strongly negative about your
>       proposal.
>
>       In my connectivity lost scenario, I would have the MG wait and then
> start again after some delay,
>       and I would make the delay backoff exponentially.
>
>
>       Brian
>
>        -----Original Message-----
>       From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>       Sent: Friday, June 02, 2000 10:58 AM
>       To: Rosen, Brian; megaco@standards.nortelnetworks.com
>       Subject: RE: MGC-Initiated Control
>
>
>
>               I agree with the "potential security problem" -- that's why
> I said it would have to be an authorized source.  In what you say below:
> how does the MG know that connectivity has been restored?  The
> ServiceChange command is one way of doing that.
>
>                       -----Original Message-----
>               From:   Rosen, Brian [SMTP:Brian.Rosen@marconi.com]
>               Sent:   Friday, June 02, 2000 10:48 AM
>               To:     Taylor, Tom-PT [NORSE:B901:EXCH];
> MEGACO@STANDARDS.NORTELNETWORKS.COM
>               Subject:        RE: MGC-Initiated Control
>
>                       It's a potential security problem, because any
> arbitrary MGC that
>               stumbles across an otherwise unmarried MG can take it over.
> In the
>               present model the MGC has to be someone you are provisioned
> to trust,
>               or someone one of the MGCs you trust told you to trust.
>
>                       Not a really big deal.  I think the circumstance is
> so rare as to be
>               not worth worrying about.  I did think about a circumstance
> where
>               the MG lost connectivity to all MGCs.  It went through its
> list in
>               vain.  The real correct response, when connectivity is
> restored, is
>               to restart the search, and not to have some MGC simply step
> up and
>               take it.
>
>                       Brian
>
>                       > -----Original Message-----
>               > From: Tom-PT Taylor [ <mailto:taylor@NORTELNETWORKS.COM>]
>               > Sent: Friday, June 02, 2000 9:45 AM
>               > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>               > Subject: MGC-Initiated Control
>               >
>               >
>               > There are cases where an MG will not be able to initiate a
>
>               > control session
>               > (e.g. it has gone through its list of MGCs without
> success).
>               > Can we agree
>               > on principle that an MG that is not currently in a control
>
>               > session will
>               > respond to an MGC-sent ServiceChange command directing it
> to
>               > initiate a
>               > session at a given address?  If so, we could add this to
> the
>               > Implementor's
>               > Guide and our IETF equivalent.
>               >
>               > The exact text that would go into the Implementor's Guide
> would be as
>               > follows:
>               >
>               >         If an MG is not currently in a control association
>
>               > with an MGC and
>               > it receives a ServiceChange command from an authorized
> source with
>               > ServiceChangeMethod equal to Handoff, it will attempt to
>               > initiate a control
>               > association as directed by that command.  To make this
>               > possible, an MG not
>               > currently in a control session shall listen for incoming
>               > commands at the
>               > default transport address corresponding to its supported
> transport and
>               > encoding (e.g. UDP port 2944 for text-encoded UDP/ALF).
>               >
>               > Tom Taylor
>               > Phone and FAX: +1 613 736 0961
>               > E-mail: taylor@nortelnetworks.com
>               >
>

------_=_NextPart_001_01BFCCD7.488D4AFC
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-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: MGC-Initiated Control</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">First, let me =
apologize for never completing a response to your queries in =
March.&nbsp; My response sat half-finished on my machine until my hard =
drive died, and then it seemed a bit late to say anything.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Agreed that I am =
proposing a change in that the MG would have to listen when not in a =
control session.&nbsp; It is up to the list to decide whether this is =
an acceptable solution to a potential problem.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">On your further =
questions:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">(1) There may be =
network situations where network management is able to contact the MGC =
but not the MG (e.g. when they have different owners.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">(2) and (3) There is =
no intention of forcing the MG to support multiple transports or =
multiple coding schemes.&nbsp; Assuming that the MGC knows through =
network management that the MG needs a controller and that it (the MGC) =
should be the one, it could try all possibilities until it gets a =
response, or it could have cached the necessary information from an =
earlier control session, or it may know what it has to from network =
management.&nbsp; This is an implementation detail.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Bharat Kaul [SMTP:bharat@TRILLIUM.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, June 02, 2000 2:29 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: MGC-Initiated Control</FONT>
</P>

<P><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">I was under the =
impression till now that, in=A0principle, it will always be an MG =
initiating a conversation with the MGC.</FONT> </P>

<P><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">In TCP world it =
implied MG establishes connection with the MGC and sent a ServiceChange =
command (and thereby negating the need to have a listening server in =
MG).....Right ?</FONT></P>

<P><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">In UDP world, life =
was simpler but still MG initiates the conversation with the MGC by =
sending a ServiceChange.</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">If my understanding =
is wrong, I would appreciate clarifications.</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">Assuming my =
understanding is wrong, then with the approach suggested there are a =
couple of issues listed below</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">1. In principle, =
MGC are not supposed to knowing unmarried MG's. If so, then how does =
MGC sending the ServiceChange figure out that the MG is unmarried ? The =
only option seems network management. And then it can be argued that =
network management can also intervene on MG side and make MG initiate =
conversation with a new MGC.</FONT></P>

<P><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">2.=A0Additionally, =
it enforces that MGC contacting the MG should now know the encoding =
schemes supported at the MG ..how does MGC figure that out ?=A0</FONT></=
P>

<P><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">3. Also, =
do=A0people on here expect MG's to be using both TCP and UDP =
simulataneously for communication to MGC. I would think that an MG will =
choose either one. If that is true, then how will the contacting MGC in =
suggested approach pick transport type.</FONT></P>

<P><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">Thanks</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">Bharat</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Tahoma">-----Original Message-----<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">From:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Rosen, Brian [<U></U></FONT><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Tahoma"><A =
HREF=3D"mailto:Brian.Rosen@MARCONI.COM">mailto:Brian.Rosen@MARCONI.COM</=
A></FONT></U><FONT SIZE=3D2 FACE=3D"Tahoma">]<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Sent:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Friday, June 02, 2000 8:48 AM<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">To:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> MEGACO@standards.nortelnetworks.com<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Subject:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Tahoma"> Re: MGC-Initiated Control<BR>
<BR>
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I don't know what =
&quot;authorized source&quot; would be, unless it was one of the =
provisioned MGCs</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">it had already =
tried.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">It does occur to me =
that you could add a reason which equated to &quot;start looking =
again&quot;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Then any MGC could =
trigger the MG to start again, if it was in the state you are =
positing.</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Again, I don't =
really think this is very important, and I don't feel strongly negative =
about your</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">proposal.</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In my connectivity =
lost scenario, I would have the MG wait and then start again after some =
delay,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">and I would make =
the delay backoff exponentially.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=A0</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Brian=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=A0-----Original =
Message-----<BR>
</FONT><B><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">From:</FONT></B><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> Tom-PT Taylor [</FONT><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:taylor@nortelnetworks.com">mailto:taylor@nortelnetworks.c=
om</A></FONT></U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">]<BR>
</FONT><B><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">Sent:</FONT></B><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> Friday, June 02, 2000 10:58 AM<BR>
</FONT><B><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">To:</FONT></B><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> Rosen, Brian; megaco@standards.nortelnetworks.com<BR>
</FONT><B><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">Subject:</FONT></B><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> RE: MGC-Initiated Control<BR>
<BR>
</FONT>
</P>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I agree with the =
&quot;potential security problem&quot; -- that's why I said it would =
have to be an authorized source.=A0 In what you say below: how does the =
MG know that connectivity has been restored?=A0 The ServiceChange =
command is one way of doing that.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 =
FACE=3D"Arial">-----Original Message-----</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">From:=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Rosen, Brian =
[SMTP:Brian.Rosen@marconi.com]</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Friday, June 02, =
2000 10:48 AM</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">To:=A0=A0=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Taylor, Tom-PT =
[NORSE:B901:EXCH]; MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:=A0=A0=A0=A0=A0=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">RE: MGC-Initiated =
Control</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">It's a potential security problem, because any arbitrary =
MGC that</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">stumbles across an otherwise =
unmarried MG can take it over.=A0 In the</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">present model the MGC has to be =
someone you are provisioned to trust,</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">or someone one of the MGCs you =
trust told you to trust.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Not a really big deal.=A0 I think the circumstance is so =
rare as to be</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">not worth worrying about.=A0 I did =
think about a circumstance where</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">the MG lost connectivity to all =
MGCs.=A0 It went through its list in</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">vain.=A0 The real correct =
response, when connectivity is restored, is</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">to restart the search, and not to =
have some MGC simply step up and</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">take it.</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Brian</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">&gt; -----Original Message-----</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; From: Tom-PT Taylor =
[</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"> &lt;<A =
HREF=3D"mailto:taylor@NORTELNETWORKS.COM">mailto:taylor@NORTELNETWORKS.C=
OM</A>&gt;</FONT></U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; Sent: Friday, June 02, 2000 =
9:45 AM</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; To: =
MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; Subject: MGC-Initiated =
Control</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; There are cases where an MG will not =
be able to initiate a</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; control session</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; (e.g. it has gone through its =
list of MGCs without success).=A0</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; Can we agree</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; on principle that an MG that =
is not currently in a control</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; session will</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; respond to an MGC-sent =
ServiceChange command directing it to</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; initiate a</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; session at a given =
address?=A0 If so, we could add this to the</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; Implementor's</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; Guide and our IETF =
equivalent.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; The exact text that would go into =
the Implementor's Guide would be as</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; follows:</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt;=A0=A0=A0=A0=A0=A0=A0=A0 If an MG is =
not currently in a control association</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; with an MGC and</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; it receives a ServiceChange =
command from an authorized source with</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; ServiceChangeMethod equal to =
Handoff, it will attempt to</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; initiate a control</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; association as directed by =
that command.=A0 To make this</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; possible, an MG not</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; currently in a control =
session shall listen for incoming</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; commands at the</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; default transport address =
corresponding to its supported transport and</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; encoding (e.g. UDP port 2944 =
for text-encoded UDP/ALF).</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; Tom Taylor</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; Phone and FAX: +1 613 736 =
0961</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; E-mail: =
taylor@nortelnetworks.com</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>=20
</P>
</UL></UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCCD7.488D4AFC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Jun  3 01:35:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25843
	for <megaco-archive@LISTS.IETF.ORG>; Sat, 3 Jun 2000 01:35:15 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B94E9B10@standards.nortelnetworks.com>; Sat, 3 Jun 2000 1:26:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4453 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 3 Jun 2000 01:24:49 -0400
Received: from ctsincsisxia.DBSS.COM (202.54.64.137) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.7F46CD20@standards.nortelnetworks.com>; Sat, 3 Jun 2000 1:24:43
          -0400
Received: from 162.44.9.80 by ctsincsisxia.DBSS.COM (InterScan E-Mail VirusWall
          NT); Sat, 03 Jun 2000 10:58:24 +0530
Received: from rnd.cts-corp.com (206.136.109.204 [206.136.109.204]) by
          ctsincsisxic.cts-corp.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2448.0) id MAHLCFR1; Sat, 3 Jun 2000 11:06:08
          +0530
Received: from 9a4-gnd ([206.136.109.229]) by rnd.cts-corp.com (8.9.3/8.8.7)
          with SMTP id LAA26146; Sat, 3 Jun 2000 11:08:35 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0053_01BFCD4B.9E09B1E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Message-ID:  <005601bfcd75$86eefc20$e56d88ce@9a4-gnd>
Date:         Sat, 3 Jun 2000 11:05:24 -0500
Reply-To: Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
Subject:      Implementors' guide
X-To:         taylor@NORTELNETWORKS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0053_01BFCD4B.9E09B1E0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Where can I find the Implementors' Guide for Megaco?

Thank you.

Regards,
Sameer

------=_NextPart_000_0053_01BFCD4B.9E09B1E0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3612.1706"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Where can I find the Implementors' =
Guide for=20
Megaco?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Thank you.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Regards,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Sameer</FONT></DIV></BODY></HTML>

------=_NextPart_000_0053_01BFCD4B.9E09B1E0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jun  4 16:26:08 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09719
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 4 Jun 2000 16:26:07 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.48DC9E30@standards.nortelnetworks.com>; 4 Jun 2000 16:16:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5442 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 4 Jun 2000 16:15:13 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.AA737210@standards.nortelnetworks.com>; 4 Jun 2000 16:05:13 -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          PAA13677 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 4 Jun 2000
          15:11:50 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay1.usa.alcatel.com
          [143.209.238.6]) by fw7 via smap (V2.1) id xma013665; Sun, 4 Jun 00
          15:11:30 -0500
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id PAA23913 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 4 Jun 2000 15:13:29 -0500
          (CDT)
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id PAA00385 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 4
          Jun 2000 15:12:13 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA12091
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 4 Jun 2000 15:12:13
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD1103858566@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------2C382840B5A028020792B5F3"
Message-ID:  <393AB81A.C9A5637B@usa.alcatel.com>
Date:         Sun, 4 Jun 2000 15:12:11 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: MGC-Initiated Control
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------2C382840B5A028020792B5F3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Tom

I think Bharat brings up a good points.

For TCP there were some discussions on the list way back that MG always
has to initiated the TCP
connect to MGC before any ServiceChange can be sent from MG to MGC.
Also that MGC is the one that should initiate a TCP accept and MG never
initiates a TCP
accept.

Your proposal of having MGC sends a ServiceChange to MG would require
MGC to initiate
a TCP connect to the MG which means MG has to initiate a TCP accept by
default to listen
for MGC trying to connect to MG.

Can't we just leave everything as is and let MG through NM or other
schema to determine
whose its controlling MGC has to be and it is up to the MG to connect to
MGC?
If all else fails, there is always the human out there to intervene and
make thing right.

If you really think your proposal is needed, then some words should be
added to clarify TCP
implementation before any ServiceChange is sent.

This also complicate our design, our implementation is that MGC does not
need to know
before registration whether MG is text or binary encoding.  It is by
virtual of which port the
MG uses to registrate w/MGC determines its encoding.

Chuong


Tom-PT Taylor wrote:

>
>
> First, let me apologize for never completing a response to your
> queries in March.  My response sat half-finished on my machine until
> my hard drive died, and then it seemed a bit late to say anything.
>
> Agreed that I am proposing a change in that the MG would have to
> listen when not in a control session.  It is up to the list to decide
> whether this is an acceptable solution to a potential problem.
>
> On your further questions:
>
> (1) There may be network situations where network management is able
> to contact the MGC but not the MG (e.g. when they have different
> owners.
>
> (2) and (3) There is no intention of forcing the MG to support
> multiple transports or multiple coding schemes.  Assuming that the MGC
> knows through network management that the MG needs a controller and
> that it (the MGC) should be the one, it could try all possibilities
> until it gets a response, or it could have cached the necessary
> information from an earlier control session, or it may know what it
> has to from network management.  This is an implementation detail.
>
>      -----Original Message-----
>      From:  Bharat Kaul [SMTP:bharat@TRILLIUM.COM]
>      Sent:  Friday, June 02, 2000 2:29 PM
>      To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:       Re: MGC-Initiated Control
>
>      I was under the impression till now that, in principle, it will
>      always be an MG initiating a conversation with the MGC.
>
>
>      In TCP world it implied MG establishes connection with the MGC
>      and sent a ServiceChange command (and thereby negating the need
>      to have a listening server in MG).....Right ?
>
>
>      In UDP world, life was simpler but still MG initiates the
>      conversation with the MGC by sending a ServiceChange.
>
>      If my understanding is wrong, I would appreciate clarifications.
>
>      Assuming my understanding is wrong, then with the approach
>      suggested there are a couple of issues listed below
>
>      1. In principle, MGC are not supposed to knowing unmarried MG's.
>      If so, then how does MGC sending the ServiceChange figure out
>      that the MG is unmarried ? The only option seems network
>      management. And then it can be argued that network management can
>      also intervene on MG side and make MG initiate conversation with
>      a new MGC.
>
>
>      2. Additionally, it enforces that MGC contacting the MG should
>      now know the encoding schemes supported at the MG ..how does MGC
>      figure that out ?
>
>
>      3. Also, do people on here expect MG's to be using both TCP and
>      UDP simulataneously for communication to MGC. I would think that
>      an MG will choose either one. If that is true, then how will the
>      contacting MGC in suggested approach pick transport type.
>
>
>      Thanks
>      Bharat
>           -----Original Message-----
>           From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
>           Sent: Friday, June 02, 2000 8:48 AM
>           To: MEGACO@standards.nortelnetworks.com
>           Subject: Re: MGC-Initiated Control
>
>
>           I don't know what "authorized source" would be, unless it
>           was one of the provisioned MGCs
>           it had already tried.
>
>           It does occur to me that you could add a reason which
>           equated to "start looking again"
>           Then any MGC could trigger the MG to start again, if it was
>           in the state you are positing.
>
>           Again, I don't really think this is very important, and I
>           don't feel strongly negative about your
>           proposal.
>
>           In my connectivity lost scenario, I would have the MG wait
>           and then start again after some delay,
>           and I would make the delay backoff exponentially.
>
>
>           Brian
>
>            -----Original Message-----
>           From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>           Sent: Friday, June 02, 2000 10:58 AM
>           To: Rosen, Brian; megaco@standards.nortelnetworks.com
>           Subject: RE: MGC-Initiated Control
>
>                I agree with the "potential security problem" -- that's
>                why I said it would have to be an authorized source.
>                In what you say below: how does the MG know that
>                connectivity has been restored?  The ServiceChange
>                command is one way of doing that.
>
>                        -----Original Message-----
>                From:   Rosen, Brian [SMTP:Brian.Rosen@marconi.com]
>                Sent:   Friday, June 02, 2000 10:48 AM
>                To:    Taylor, Tom-PT [NORSE:B901:EXCH];
>                MEGACO@STANDARDS.NORTELNETWORKS.COM
>                Subject:       RE: MGC-Initiated Control
>
>                        It's a potential security problem, because any
>                arbitrary MGC that
>                stumbles across an otherwise unmarried MG can take it
>                over.  In the
>                present model the MGC has to be someone you are
>                provisioned to trust,
>                or someone one of the MGCs you trust told you to trust.
>
>                        Not a really big deal.  I think the
>                circumstance is so rare as to be
>                not worth worrying about.  I did think about a
>                circumstance where
>                the MG lost connectivity to all MGCs.  It went through
>                its list in
>                vain.  The real correct response, when connectivity is
>                restored, is
>                to restart the search, and not to have some MGC simply
>                step up and
>                take it.
>
>                        Brian
>
>                        > -----Original Message-----
>                > From: Tom-PT Taylor [
>                <mailto:taylor@NORTELNETWORKS.COM>]
>                > Sent: Friday, June 02, 2000 9:45 AM
>                > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>                > Subject: MGC-Initiated Control
>                >
>                >
>                > There are cases where an MG will not be able to
>                initiate a
>                > control session
>                > (e.g. it has gone through its list of MGCs without
>                success).
>                > Can we agree
>                > on principle that an MG that is not currently in a
>                control
>                > session will
>                > respond to an MGC-sent ServiceChange command
>                directing it to
>                > initiate a
>                > session at a given address?  If so, we could add this
>                to the
>                > Implementor's
>                > Guide and our IETF equivalent.
>                >
>                > The exact text that would go into the Implementor's
>                Guide would be as
>                > follows:
>                >
>                >         If an MG is not currently in a control
>                association
>                > with an MGC and
>                > it receives a ServiceChange command from an
>                authorized source with
>                > ServiceChangeMethod equal to Handoff, it will attempt
>                to
>                > initiate a control
>                > association as directed by that command.  To make
>                this
>                > possible, an MG not
>                > currently in a control session shall listen for
>                incoming
>                > commands at the
>                > default transport address corresponding to its
>                supported transport and
>                > encoding (e.g. UDP port 2944 for text-encoded
>                UDP/ALF).
>                >
>                > Tom Taylor
>                > Phone and FAX: +1 613 736 0961
>                > E-mail: taylor@nortelnetworks.com
>                >
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------2C382840B5A028020792B5F3
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Tom
<p>I&nbsp;think Bharat brings up a good points.
<p>For TCP there were some discussions on the list way back that MG always
has to initiated the TCP
<br>connect to MGC before any ServiceChange can be sent from MG to MGC.
<br>Also that MGC is the one that should initiate a TCP accept and MG never
initiates a TCP
<br>accept.
<p>Your proposal of having MGC sends a ServiceChange to MG would require
MGC to initiate
<br>a TCP&nbsp;connect to the MG which means MG has to initiate a TCP&nbsp;accept
by default to listen
<br>for MGC trying to connect to MG.
<p>Can't we just leave everything as is and let MG through NM or other
schema to determine
<br>whose its controlling MGC&nbsp;has to be and it is up to the MG to
connect to MGC?
<br>If all else fails, there is always the human out there to intervene
and make thing right.
<p>If you really think your proposal is needed, then some words should
be added to clarify TCP
<br>implementation before any ServiceChange is sent.
<p>This also complicate our design, our implementation is that MGC does
not need to know
<br>before registration whether MG is text or binary encoding.&nbsp; It
is by virtual of which port the
<br>MG uses to registrate w/MGC determines its encoding.
<p>Chuong
<br>&nbsp;
<p>Tom-PT Taylor wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>First, let me
apologize for never completing a response to your queries in March.&nbsp;
My response sat half-finished on my machine until my hard drive died, and
then it seemed a bit late to say anything.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>Agreed that I
am proposing a change in that the MG would have to listen when not in a
control session.&nbsp; It is up to the list to decide whether this is an
acceptable solution to a potential problem.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>On your further
questions:</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>(1) There may
be network situations where network management is able to contact the MGC
but not the MG (e.g. when they have different owners.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>(2) and (3) There
is no intention of forcing the MG to support multiple transports or multiple
coding schemes.&nbsp; Assuming that the MGC knows through network management
that the MG needs a controller and that it (the MGC) should be the one,
it could try all possibilities until it gets a response, or it could have
cached the necessary information from an earlier control session, or it
may know what it has to from network management.&nbsp; This is an implementation
detail.</font></font></font>
<ul><font face="Arial"><font size=-2>-----Original Message-----</font></font>
<br><font face="Arial"><font size=-2><b>From:&nbsp; </b>Bharat Kaul [SMTP:bharat@TRILLIUM.COM]</font></font>
<br><font face="Arial"><font size=-2><b>Sent:&nbsp; </b>Friday, June 02,
2000 2:29 PM</font></font>
<br><font face="Arial"><font size=-2><b>To:&nbsp;&nbsp;&nbsp; </b>MEGACO@STANDARDS.NORTELNETWORKS.COM</font></font>
<br><font face="Arial"><font size=-2><b>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</b>Re: MGC-Initiated Control</font></font>
<p><font face="Arial"><font color="#FF0000"><font size=-1>I was under the
impression till now that, in principle, it will always be an MG initiating
a conversation with the MGC.</font></font></font>
<br>&nbsp;
<p><font face="Arial"><font color="#FF0000"><font size=-1>In TCP world
it implied MG establishes connection with the MGC and sent a ServiceChange
command (and thereby negating the need to have a listening server in MG).....Right
?</font></font></font>
<br>&nbsp;
<p><font face="Arial"><font color="#FF0000"><font size=-1>In UDP world,
life was simpler but still MG initiates the conversation with the MGC by
sending a ServiceChange.</font></font></font>
<p><font face="Arial"><font color="#FF0000"><font size=-1>If my understanding
is wrong, I would appreciate clarifications.</font></font></font>
<p><font face="Arial"><font color="#FF0000"><font size=-1>Assuming my understanding
is wrong, then with the approach suggested there are a couple of issues
listed below</font></font></font>
<p><font face="Arial"><font color="#FF0000"><font size=-1>1. In principle,
MGC are not supposed to knowing unmarried MG's. If so, then how does MGC
sending the ServiceChange figure out that the MG is unmarried ? The only
option seems network management. And then it can be argued that network
management can also intervene on MG side and make MG initiate conversation
with a new MGC.</font></font></font>
<br>&nbsp;
<p><font face="Arial"><font color="#FF0000"><font size=-1>2. Additionally,
it enforces that MGC contacting the MG should now know the encoding schemes
supported at the MG ..how does MGC figure that out ?</font></font></font>
<br>&nbsp;
<p><font face="Arial"><font color="#FF0000"><font size=-1>3. Also, do people
on here expect MG's to be using both TCP and UDP simulataneously for communication
to MGC. I would think that an MG will choose either one. If that is true,
then how will the contacting MGC in suggested approach pick transport type.</font></font></font>
<br>&nbsp;
<p><font face="Arial"><font color="#FF0000"><font size=-1>Thanks</font></font></font>
<br><font face="Arial"><font color="#FF0000"><font size=-1>Bharat</font></font></font>
<ul><font face="Tahoma"><font size=-1>-----Original Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Rosen, Brian [<u><font color="#0000FF"><a href="mailto:Brian.Rosen@MARCONI.COM">mailto:Brian.Rosen@MARCONI.COM</a></font></u>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Friday, June 02, 2000
8:48 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> MEGACO@standards.nortelnetworks.com</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: MGC-Initiated
Control</font></font>
<br>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>I don't know
what "authorized source" would be, unless it was one of the provisioned
MGCs</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>it had already
tried.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>It does occur
to me that you could add a reason which equated to "start looking again"</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>Then any MGC
could trigger the MG to start again, if it was in the state you are positing.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>Again, I don't
really think this is very important, and I don't feel strongly negative
about your</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>proposal.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>In my connectivity
lost scenario, I would have the MG wait and then start again after some
delay,</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>and I would
make the delay backoff exponentially.</font></font></font>
<br>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>Brian</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;-----Original
Message-----</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1><b>From:</b>
Tom-PT Taylor [<u><a href="mailto:taylor@nortelnetworks.com">mailto:taylor@nortelnetworks.com</a></u>]</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1><b>Sent:</b>
Friday, June 02, 2000 10:58 AM</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1><b>To:</b> Rosen,
Brian; megaco@standards.nortelnetworks.com</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1><b>Subject:</b>
RE: MGC-Initiated Control</font></font></font>
<br>&nbsp;
<ul><font face="Arial"><font color="#0000FF"><font size=-1>I agree with
the "potential security problem" -- that's why I said it would have to
be an authorized source.&nbsp; In what you say below: how does the MG know
that connectivity has been restored?&nbsp; The ServiceChange command is
one way of doing that.</font></font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-2>-----Original
Message-----</font></font>
<br><font face="Arial"><b><font size=-2>From:&nbsp;&nbsp;</font></b> <font size=-2>Rosen,
Brian [SMTP:Brian.Rosen@marconi.com]</font></font>
<br><font face="Arial"><b><font size=-2>Sent:&nbsp;&nbsp;</font></b> <font size=-2>Friday,
June 02, 2000 10:48 AM</font></font>
<br><font face="Arial"><font size=-2><b>To:&nbsp;&nbsp;&nbsp; </b>Taylor,
Tom-PT [NORSE:B901:EXCH]; MEGACO@STANDARDS.NORTELNETWORKS.COM</font></font>
<br><font face="Arial"><font size=-2><b>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</b>RE: MGC-Initiated Control</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>It's
a potential security problem, because any arbitrary MGC that</font></font>
<br><font face="Arial"><font size=-1>stumbles across an otherwise unmarried
MG can take it over.&nbsp; In the</font></font>
<br><font face="Arial"><font size=-1>present model the MGC has to be someone
you are provisioned to trust,</font></font>
<br><font face="Arial"><font size=-1>or someone one of the MGCs you trust
told you to trust.</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>Not
a really big deal.&nbsp; I think the circumstance is so rare as to be</font></font>
<br><font face="Arial"><font size=-1>not worth worrying about.&nbsp; I
did think about a circumstance where</font></font>
<br><font face="Arial"><font size=-1>the MG lost connectivity to all MGCs.&nbsp;
It went through its list in</font></font>
<br><font face="Arial"><font size=-1>vain.&nbsp; The real correct response,
when connectivity is restored, is</font></font>
<br><font face="Arial"><font size=-1>to restart the search, and not to
have some MGC simply step up and</font></font>
<br><font face="Arial"><font size=-1>take it.</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>Brian</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>>
-----Original Message-----</font></font>
<br><font face="Arial"><font size=-1>> From: Tom-PT Taylor [<u><font color="#0000FF">
&lt;<a href="mailto:taylor@NORTELNETWORKS.COM">mailto:taylor@NORTELNETWORKS.COM</a>></font></u>]</font></font>
<br><font face="Arial"><font size=-1>> Sent: Friday, June 02, 2000 9:45
AM</font></font>
<br><font face="Arial"><font size=-1>> To: MEGACO@STANDARDS.NORTELNETWORKS.COM</font></font>
<br><font face="Arial"><font size=-1>> Subject: MGC-Initiated Control</font></font>
<br><font face="Arial"><font size=-1>></font></font>
<br><font face="Arial"><font size=-1>></font></font>
<br><font face="Arial"><font size=-1>> There are cases where an MG will
not be able to initiate a</font></font>
<br><font face="Arial"><font size=-1>> control session</font></font>
<br><font face="Arial"><font size=-1>> (e.g. it has gone through its list
of MGCs without success).</font></font>
<br><font face="Arial"><font size=-1>> Can we agree</font></font>
<br><font face="Arial"><font size=-1>> on principle that an MG that is
not currently in a control</font></font>
<br><font face="Arial"><font size=-1>> session will</font></font>
<br><font face="Arial"><font size=-1>> respond to an MGC-sent ServiceChange
command directing it to</font></font>
<br><font face="Arial"><font size=-1>> initiate a</font></font>
<br><font face="Arial"><font size=-1>> session at a given address?&nbsp;
If so, we could add this to the</font></font>
<br><font face="Arial"><font size=-1>> Implementor's</font></font>
<br><font face="Arial"><font size=-1>> Guide and our IETF equivalent.</font></font>
<br><font face="Arial"><font size=-1>></font></font>
<br><font face="Arial"><font size=-1>> The exact text that would go into
the Implementor's Guide would be as</font></font>
<br><font face="Arial"><font size=-1>> follows:</font></font>
<br><font face="Arial"><font size=-1>></font></font>
<br><font face="Arial"><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
If an MG is not currently in a control association</font></font>
<br><font face="Arial"><font size=-1>> with an MGC and</font></font>
<br><font face="Arial"><font size=-1>> it receives a ServiceChange command
from an authorized source with</font></font>
<br><font face="Arial"><font size=-1>> ServiceChangeMethod equal to Handoff,
it will attempt to</font></font>
<br><font face="Arial"><font size=-1>> initiate a control</font></font>
<br><font face="Arial"><font size=-1>> association as directed by that
command.&nbsp; To make this</font></font>
<br><font face="Arial"><font size=-1>> possible, an MG not</font></font>
<br><font face="Arial"><font size=-1>> currently in a control session shall
listen for incoming</font></font>
<br><font face="Arial"><font size=-1>> commands at the</font></font>
<br><font face="Arial"><font size=-1>> default transport address corresponding
to its supported transport and</font></font>
<br><font face="Arial"><font size=-1>> encoding (e.g. UDP port 2944 for
text-encoded UDP/ALF).</font></font>
<br><font face="Arial"><font size=-1>></font></font>
<br><font face="Arial"><font size=-1>> Tom Taylor</font></font>
<br><font face="Arial"><font size=-1>> Phone and FAX: +1 613 736 0961</font></font>
<br><font face="Arial"><font size=-1>> E-mail: taylor@nortelnetworks.com</font></font>
<br><font face="Arial"><font size=-1>></font></font></ul>
</ul>
</ul>
</blockquote>

<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------2C382840B5A028020792B5F3--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun  5 00:02:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13868
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 5 Jun 2000 00:02:21 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.16312B00@standards.nortelnetworks.com>; 4 Jun 2000 23:53:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5611 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 4 Jun 2000 23:52:29 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.8ACA2D10@standards.nortelnetworks.com>; 4 Jun 2000 23:42:27
          -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA21267; Mon, 5
          Jun 2000 13:49:09 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA10379; Mon, 5
          Jun 2000 13:49:49 +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA00599; Mon,
          5 Jun 2000 13:50:11 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678414@whq-msgusr-02.fore.com>
            <3937DA2A.9B6CF4CA@americasm10.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <393B2348.6BC80331@ericsson.com>
Date:         Mon, 5 Jun 2000 13:49:28 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: H.248/BICC discussions
X-To:         Sophia Scoggins <scoggins@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Sophia,

BNC-ID is included in Annex C - see table 3 BIR - Binding Reference.
Use RTCP or not could be added as an extension to the RTP Package.

Whilst using SDP as the cohesive glue in MGC-MG architectures is
admirable MG to MG parameters are typically used as a mechanism to set
up a bearer/connection. There are other protocols today to do this work
so I suspect that when adding parameters to SDP you'll have a superset a
properties not used by all applications, as per Annex C. The challenge
will be to define to one's you want in a certain scenario so that every
can interoperate. In H.248 it will be a package and optionally a
profile.

Regards, Christian

Sophia Scoggins wrote:
>
> It would be better that we have just one cohesive coding mechanism to
> carry information end-to-end for all MGCs and MGs.
>
> There are indeed too many parameters in the Annex C. I am not sure if
> many of them will ever be used. Somewhere I heard or saw that the
> average length of SDP messages is only 60 bytes. How much of info do we
> really want to carry in the SDP? Many of the Q.9XX parameters need not
> to carry through the path MG --> MGC --> MGC --> MG. ISUP trunks would
> be choking by large packets -- SIP has less issues with big packets.
>
> However, in Nortel's contribution to SG11, we have identified two
> parameters that are needed but not included in the Annex C:
>
> -- eecid or bnc-id (this is included in Rajesh Kumar's ATM SDP)
> -- use RTCP or not (RTCP is optional to RTP. We need to specify to use
> RTCP or not.)
>
> Regards, SOphia


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun  5 00:14:18 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13890
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 5 Jun 2000 00:14:18 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C3DB85B0@standards.nortelnetworks.com>; Mon, 5 Jun 2000 0:05:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5621 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Jun 2000 00:03:36 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.183D9CD0@standards.nortelnetworks.com>; 4 Jun 2000 23:53:34
          -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA22136; Mon, 5
          Jun 2000 13:59:35 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA11508; Mon, 5
          Jun 2000 14:00:16 +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA00701; Mon,
          5 Jun 2000 14:00:32 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678420@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <393B25B4.DE4517F7@ericsson.com>
Date:         Mon, 5 Jun 2000 13:59:48 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: H.248/BICC discussions
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

I support the idea that you're updating SDP and then writing a Package.
I gather that as the properties will be defined in a package that
they'll be able to be used by both binary and text forms of H.248. I
think that having several packages extending each as proposed by Mike
Brown is a good way of approaching things.

In the future though I don't know that people will want to go through
the effort of setting up email exploders/ writing drafts/ packages etc.
for what may amount to 2 values. A package could be a way of doing this.

Cheers, Christian

PS: What's MGCP??? ;-)

"Rosen, Brian" wrote:
>
> It's not the idea that Megaco can extend SDP with MMUSIC in the loop.
> It's whether the form to do this is a package.  It's probably all
> in the details.
>
> I agree that Tom's basic premise, that a Megaco sponsored standards
> track RFC that defines an extension is a perfectly appropriate way
> to define an extension.  The package mechanism is defined as pretty
> general, and of course is useable by parties other than the IETF (as
> is the SDP extension mechanism).  If we made such a decision than
> anyone could come along, define a megaco package that added a media
> parameter, and have the result be an extension to SDP.
>
> Now, it's certainly true that anyone can define an extension to SDP
> by just doing an IANA registration of a tag, so this isn't very much
> different, it's just that doing it as a Megaco package makes the SDP
> extension indirect -- is that what we want?
>
> Consider the alternative - what we are doing now.  We are writing
> an I-D, with the intention of getting it published as an MMUSIC RFC
> that defines an ATM extension to SDP.  Then we have another I-D that will be
> published as a Megaco RFC that defines a Megaco package using that
> SDP extension.  We also have an MGCP package, but that is outside the
> scope of this discussion at the moment.  Is that not a preferable way
> to get the job done?
>
> Brian
>
> > -----Original Message-----
> > From: Scott Bradner [mailto:sob@harvard.edu]
> > Sent: Friday, June 02, 2000 3:29 PM
> > To: Rosen, Brian
> > Cc: mankin@isi.edu; megaco@standards.nortelnetworks.com
> > Subject: Re: H.248/BICC discussions
> >
> >
> > > Well, I'm having a problem with the idea that a package can
> > extend SDP.
> >
> > SDP is designed to be extensible - it is reasonable for other
> > IETF working
> > groups to suggest extensions, the mmusic WG should be in the
> > loop during
> > the discussions but having the group that has the best knowledge of
> > what the extensions are for be in the drivers seat means it is more
> > likly to get done in a reasonable period of time - mmusic can provide
> > feedback if they think that the proposed extensions run
> > counter to the
> > SDP design goals or feel that there is a better way to do the
> > function.
> >
> > Scott
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun  5 06:47:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27784
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 5 Jun 2000 06:47:20 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A3ED5E90@standards.nortelnetworks.com>; Mon, 5 Jun 2000 6:38:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5939 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Jun 2000 06:37:01 -0400
Received: from hd2.dot.net.in (202.54.30.2) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.0E4F0560@standards.nortelnetworks.com>; Mon, 5 Jun 2000 6:27:00
          -0400
Received: from hyd.chiplogic.com ([203.197.20.98]) by hd2.dot.net.in
          (8.8.8/8.8.8) with ESMTP id QAA19906 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 5 Jun 2000 16:02:49 +0530
          (IST)
Received: from chiplogic.com ([192.168.2.61]) by hyd.chiplogic.com
          (8.8.7/8.8.7) with ESMTP id PAA19584 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 5 Jun 2000 15:56:23 +0530
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL}  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <393B82D2.C3E8CA1F@chiplogic.com>
Date:         Mon, 5 Jun 2000 16:07:06 +0530
Reply-To: SSMudholkar <ssm@CHIPLOGIC.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: SSMudholkar <ssm@CHIPLOGIC.COM>
Organization: CHIPLOGIC
Subject:      About Packages..
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi ,
    A newbee question.
 When an MG comes up is it required that all it's
physical terminations (which will be in null context ) have to support
some
packages by default or all the packages it has to support will be
specified
by the MGC when a termination is created through ADD command.

Thanks in advance
-sanjeev


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun  5 10:18:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02912
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 5 Jun 2000 10:18:17 -0400 (EDT)
Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.189A93D0@standards.nortelnetworks.com>; Mon, 5 Jun 2000 10:09:12 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6156 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Jun 2000 10:07:27 -0400
Received: from qhars002.nortel.com (47.101.112.102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.D9FB6370@standards.nortelnetworks.com>; Mon, 5 Jun 2000
          10:07:27 -0400
Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com;
          Mon, 5 Jun 2000 15:10:05 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Mon, 5 Jun 2000 08:58:25 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <LW2CC69B>; Mon, 5 Jun 2000 09:06:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCEF7.3FDA70AC"
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1103858569@zcard00g.ca.nortel.com>
Date:         Mon, 5 Jun 2000 09:06:44 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Implementors' guide
X-To:         Sameer Kaikini <ksameer@rnd.cts-corp.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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_01BFCEF7.3FDA70AC
Content-Type: text/plain

It doesn't exist yet.

I should also say that the ITU-T "Implementor's Guide" is actually more of a
bug report.  I intend to go back over our discussions since the beginning of
March and pull out the "clarification only" issues that didn't make it into
the Errata document.  I'll forward them to the ITU-T for consiideration as
material to include in the ITU-T Implementor's Guide.  I suppose we should
start an I-D which is less formal but records information useful to
implementors.

> -----Original Message-----
> From: Sameer Kaikini [SMTP:ksameer@rnd.cts-corp.com]
> Sent: Saturday, June 03, 2000 12:05 PM
> To:   Taylor, Tom-PT [NORSE:B901:EXCH]; MEGACO
> Subject:      Implementors' guide
>
> Where can I find the Implementors' Guide for Megaco?
>
> Thank you.
>
> Regards,
> Sameer

------_=_NextPart_001_01BFCEF7.3FDA70AC
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-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Implementors' guide</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">It doesn't exist =
yet.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I should also say =
that the ITU-T &quot;Implementor's Guide&quot; is actually more of a =
bug report.&nbsp; I intend to go back over our discussions since the =
beginning of March and pull out the &quot;clarification only&quot; =
issues that didn't make it into the Errata document.&nbsp; I'll forward =
them to the ITU-T for consiideration as material to include in the =
ITU-T Implementor's Guide.&nbsp; I suppose we should start an I-D which =
is less formal but records information useful to =
implementors.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Sameer Kaikini =
[SMTP:ksameer@rnd.cts-corp.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Saturday, June 03, 2000 12:05 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Taylor, Tom-PT [NORSE:B901:EXCH]; MEGACO</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Implementors' guide</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Where can I find the =
Implementors' Guide for Megaco?</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Thank you.</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Sameer</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCEF7.3FDA70AC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun  5 15:22:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08983
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 5 Jun 2000 15:22:02 -0400 (EDT)
Received: from standards (47.234.32.16:2287) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7328D@standards.nortelnetworks.com>; Mon, 5 Jun 2000 15:13:00 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0059 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Jun 2000 15:13:00 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB7328C@standards.nortelnetworks.com>; Mon, 5 Jun 2000 15:12:55
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id PAA18844; Mon, 5 Jun 2000 15:21:13 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id PAA25703; Mon, 5 Jun 2000 15:21:14 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <M2VDNJ1Z>; Mon, 5 Jun 2000 15:21:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678428@whq-msgusr-02.fore.com>
Date:         Mon, 5 Jun 2000 15:21:10 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: H.248/BICC discussions
X-To:         Christian Groves <Christian.Groves@ericsson.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Christian

The Package we propose has little more than events for
setup failure and codec change, as well as statistics.  It has
no parameters.  We are trying to align the parameters in the
SDP extension to Annex C, but we do that entirely in SDP,
not in the Package.

If you need two more parameters in the future, I think you
write a document and add them to SDP.  I'm not really sure
how you add things to Annex C.  I understand that it would
be nice to get the whole thing into a package, but I don't
see how to reconcile that with the SDP extension process,
especially when, as we are hear, the effort is defined to
be a one-document-for-all H.248/MGCP/SIP/RTSP/...

There are discussions of reworking SDP (SDPng).  I plan to
participate in that process to make sure that things get
better with respect to this issue.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Monday, June 05, 2000 12:00 AM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: H.248/BICC discussions
>
>
> G'Day Brian,
>
> I support the idea that you're updating SDP and then writing
> a Package.
> I gather that as the properties will be defined in a package that
> they'll be able to be used by both binary and text forms of H.248. I
> think that having several packages extending each as proposed by Mike
> Brown is a good way of approaching things.
>
> In the future though I don't know that people will want to go through
> the effort of setting up email exploders/ writing drafts/
> packages etc.
> for what may amount to 2 values. A package could be a way of
> doing this.
>
> Cheers, Christian
>
> PS: What's MGCP??? ;-)
>
> "Rosen, Brian" wrote:
> >
> > It's not the idea that Megaco can extend SDP with MMUSIC in
> the loop.
> > It's whether the form to do this is a package.  It's probably all
> > in the details.
> >
> > I agree that Tom's basic premise, that a Megaco sponsored standards
> > track RFC that defines an extension is a perfectly appropriate way
> > to define an extension.  The package mechanism is defined as pretty
> > general, and of course is useable by parties other than the IETF (as
> > is the SDP extension mechanism).  If we made such a decision than
> > anyone could come along, define a megaco package that added a media
> > parameter, and have the result be an extension to SDP.
> >
> > Now, it's certainly true that anyone can define an extension to SDP
> > by just doing an IANA registration of a tag, so this isn't very much
> > different, it's just that doing it as a Megaco package makes the SDP
> > extension indirect -- is that what we want?
> >
> > Consider the alternative - what we are doing now.  We are writing
> > an I-D, with the intention of getting it published as an MMUSIC RFC
> > that defines an ATM extension to SDP.  Then we have another
> I-D that will be
> > published as a Megaco RFC that defines a Megaco package using that
> > SDP extension.  We also have an MGCP package, but that is
> outside the
> > scope of this discussion at the moment.  Is that not a
> preferable way
> > to get the job done?
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Scott Bradner [mailto:sob@harvard.edu]
> > > Sent: Friday, June 02, 2000 3:29 PM
> > > To: Rosen, Brian
> > > Cc: mankin@isi.edu; megaco@standards.nortelnetworks.com
> > > Subject: Re: H.248/BICC discussions
> > >
> > >
> > > > Well, I'm having a problem with the idea that a package can
> > > extend SDP.
> > >
> > > SDP is designed to be extensible - it is reasonable for other
> > > IETF working
> > > groups to suggest extensions, the mmusic WG should be in the
> > > loop during
> > > the discussions but having the group that has the best
> knowledge of
> > > what the extensions are for be in the drivers seat means
> it is more
> > > likly to get done in a reasonable period of time - mmusic
> can provide
> > > feedback if they think that the proposed extensions run
> > > counter to the
> > > SDP design goals or feel that there is a better way to do the
> > > function.
> > >
> > > Scott
> > >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun  5 20:13:51 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12888
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 5 Jun 2000 20:13:50 -0400 (EDT)
Received: from standards (47.234.32.16:1131) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7336B@standards.nortelnetworks.com>; Mon, 5 Jun 2000 20:04:54 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0328 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Jun 2000 20:04:53 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB7336A@standards.nortelnetworks.com>; Mon, 5 Jun 2000 19:54:53
          -0400
Received: from aiglos.trillium.com (unverified) by turin.trillium.com (Content
          Technologies SMTPRS 4.1.5) with ESMTP id
          <Tced86cda834c9e4c5e0d@turin.trillium.com>; Mon, 5 Jun 2000 17:15:19
          -0700
Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by
          aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id RAA11127; Mon, 5 Jun
          2000 17:02:58 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <LSLFY7F2>; Mon, 5 Jun 2000 17:01:31 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5D41ADB4@aega.trillium.com>
Date:         Mon, 5 Jun 2000 17:01:29 -0700
Reply-To: Naren Tulpule <naren@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Naren Tulpule <naren@TRILLIUM.COM>
Subject:      Binary encoding for SDP?
X-cc:         "atmsdp@eng.fore.com" <atmsdp@eng.fore.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,
  in annex A of draft-ietf-megaco-protocol-08.txt (5/2/2000); binary
encoding for LocalRemoteDescriptor is given as below. I am having
difficulties in relating this to the text encoding (annex B) where local and
remote descriptors are octetstrings (representing SDP description).
  Can anyone clarify what goes in a property group and a propertyParm?

   LocalRemoteDescriptor ::= SEQUENCE
   {
        propGrps        SEQUENCE OF PropertyGroup,
        ...
   }

   PropertyGroup ::= SEQUENCE OF PropertyParm
where
  PropertyParm ::= SEQUENCE
   {
        name            PkgdName,
        value           SEQUENCE OF OCTET STRING,
        extraInfo       CHOICE
                {
                        relation        Relation,
                        range           BOOLEAN
                } OPTIONAL

   }
   PkgdName ::= OCTET STRING(SIZE(4))

-- Naren.
Narendra C. Tulpule
SMTS, Trillium Digital Systems Inc
12100 Wilshire Bl #1800 LA CA 90025
Ph:  +1-310-442-9222
Fax: +1-310-442-1162


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun  5 21:29:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13272
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 5 Jun 2000 21:29:32 -0400 (EDT)
Received: from standards (47.234.32.16:2711) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB733AE@standards.nortelnetworks.com>; Mon, 5 Jun 2000 21:20:46 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0416 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Jun 2000 21:20:46 -0400
Received: from ish7.ericsson.com.au (203.61.155.111:54607) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB733AD@standards.nortelnetworks.com>; Mon, 5 Jun 2000
          21:10:44 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA07766; Tue, 6
          Jun 2000 11:17:30 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA01780; Tue, 6
          Jun 2000 11:18:10 +1000 (EST)
Received: from ericsson.com (7-147.epa.ericsson.se [146.11.7.147]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA11925; Tue,
          6 Jun 2000 11:18:21 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678428@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <393C4F46.BA145D@ericsson.com>
Date:         Tue, 6 Jun 2000 11:09:26 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      H.248 Packages - what goal?
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

What I miss from the whole effort of using SDP (and Annex C for that
matter) is how you specify a subset of properties that a MG must
implement?

If I have a package then I know I must implement all the properties.
However with SDP and Annex C I'm left with a bucket of
properties/values, which one's do I implement for a particular function?
how can I extend these?

The required SDP properties should at least be mentioned in the package
that would use them. This would be aside from the global issue of adding
ATM parameters to SDP for SIP/RTSP etc....

Cheers, Christian

"Rosen, Brian" wrote:
>
> Christian
>
> The Package we propose has little more than events for
> setup failure and codec change, as well as statistics.  It has
> no parameters.  We are trying to align the parameters in the
> SDP extension to Annex C, but we do that entirely in SDP,
> not in the Package.
>
> If you need two more parameters in the future, I think you
> write a document and add them to SDP.  I'm not really sure
> how you add things to Annex C.  I understand that it would
> be nice to get the whole thing into a package, but I don't
> see how to reconcile that with the SDP extension process,
> especially when, as we are hear, the effort is defined to
> be a one-document-for-all H.248/MGCP/SIP/RTSP/...
>
> There are discussions of reworking SDP (SDPng).  I plan to
> participate in that process to make sure that things get
> better with respect to this issue.
>
> Brian
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Monday, June 05, 2000 12:00 AM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: H.248/BICC discussions
> >
> >
> > G'Day Brian,
> >
> > I support the idea that you're updating SDP and then writing
> > a Package.
> > I gather that as the properties will be defined in a package that
> > they'll be able to be used by both binary and text forms of H.248. I
> > think that having several packages extending each as proposed by Mike
> > Brown is a good way of approaching things.
> >
> > In the future though I don't know that people will want to go through
> > the effort of setting up email exploders/ writing drafts/
> > packages etc.
> > for what may amount to 2 values. A package could be a way of
> > doing this.
> >
> > Cheers, Christian
> >
> > PS: What's MGCP??? ;-)
> >
> > "Rosen, Brian" wrote:
> > >
> > > It's not the idea that Megaco can extend SDP with MMUSIC in
> > the loop.
> > > It's whether the form to do this is a package.  It's probably all
> > > in the details.
> > >
> > > I agree that Tom's basic premise, that a Megaco sponsored standards
> > > track RFC that defines an extension is a perfectly appropriate way
> > > to define an extension.  The package mechanism is defined as pretty
> > > general, and of course is useable by parties other than the IETF (as
> > > is the SDP extension mechanism).  If we made such a decision than
> > > anyone could come along, define a megaco package that added a media
> > > parameter, and have the result be an extension to SDP.
> > >
> > > Now, it's certainly true that anyone can define an extension to SDP
> > > by just doing an IANA registration of a tag, so this isn't very much
> > > different, it's just that doing it as a Megaco package makes the SDP
> > > extension indirect -- is that what we want?
> > >
> > > Consider the alternative - what we are doing now.  We are writing
> > > an I-D, with the intention of getting it published as an MMUSIC RFC
> > > that defines an ATM extension to SDP.  Then we have another
> > I-D that will be
> > > published as a Megaco RFC that defines a Megaco package using that
> > > SDP extension.  We also have an MGCP package, but that is
> > outside the
> > > scope of this discussion at the moment.  Is that not a
> > preferable way
> > > to get the job done?
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Scott Bradner [mailto:sob@harvard.edu]
> > > > Sent: Friday, June 02, 2000 3:29 PM
> > > > To: Rosen, Brian
> > > > Cc: mankin@isi.edu; megaco@standards.nortelnetworks.com
> > > > Subject: Re: H.248/BICC discussions
> > > >
> > > >
> > > > > Well, I'm having a problem with the idea that a package can
> > > > extend SDP.
> > > >
> > > > SDP is designed to be extensible - it is reasonable for other
> > > > IETF working
> > > > groups to suggest extensions, the mmusic WG should be in the
> > > > loop during
> > > > the discussions but having the group that has the best
> > knowledge of
> > > > what the extensions are for be in the drivers seat means
> > it is more
> > > > likly to get done in a reasonable period of time - mmusic
> > can provide
> > > > feedback if they think that the proposed extensions run
> > > > counter to the
> > > > SDP design goals or feel that there is a better way to do the
> > > > function.
> > > >
> > > > Scott
> > > >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun  5 21:45:49 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13932
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 5 Jun 2000 21:45:49 -0400 (EDT)
Received: from standards (47.234.32.16:2711) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB733E6@standards.nortelnetworks.com>; Mon, 5 Jun 2000 21:37:00 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0480 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Jun 2000 21:37:00 -0400
Received: from ish7.ericsson.com.au (203.61.155.111:55018) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB733DF@standards.nortelnetworks.com>; Mon, 5 Jun 2000
          21:26:59 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA09174; Tue, 6
          Jun 2000 11:34:25 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA03799; Tue, 6
          Jun 2000 11:35:05 +1000 (EST)
Received: from ericsson.com (7-147.epa.ericsson.se [146.11.7.147]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA12140; Tue,
          6 Jun 2000 11:35:26 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <8BBD33A986C5D311804000902719FF5D41ADB4@aega.trillium.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <393C5531.A396F561@ericsson.com>
Date:         Tue, 6 Jun 2000 11:34:41 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Binary encoding for SDP?
X-To:         Naren Tulpule <naren@trillium.com>
X-cc:         "atmsdp@eng.fore.com" <atmsdp@eng.fore.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Naren,

A PropertyGroup could be seen as a Single Session Description,
PropertyParm are the parameters of that description. Thus the
PropertyGroup allows multiple SessionDescriptions to be sent in one
command. The PropertyGroup is a way delimiting different
SessionDescriptions in the binary version of the protocol. In the text
protocol the "v=" gives you this same functionality.

Cheers, Christian

Naren Tulpule wrote:
>
> Hi,
>   in annex A of draft-ietf-megaco-protocol-08.txt (5/2/2000); binary
> encoding for LocalRemoteDescriptor is given as below. I am having
> difficulties in relating this to the text encoding (annex B) where local and
> remote descriptors are octetstrings (representing SDP description).
>   Can anyone clarify what goes in a property group and a propertyParm?
>
>    LocalRemoteDescriptor ::= SEQUENCE
>    {
>         propGrps        SEQUENCE OF PropertyGroup,
>         ...
>    }
>
>    PropertyGroup ::= SEQUENCE OF PropertyParm
> where
>   PropertyParm ::= SEQUENCE
>    {
>         name            PkgdName,
>         value           SEQUENCE OF OCTET STRING,
>         extraInfo       CHOICE
>                 {
>                         relation        Relation,
>                         range           BOOLEAN
>                 } OPTIONAL
>
>    }
>    PkgdName ::= OCTET STRING(SIZE(4))
>
> -- Naren.
> Narendra C. Tulpule
> SMTS, Trillium Digital Systems Inc
> 12100 Wilshire Bl #1800 LA CA 90025
> Ph:  +1-310-442-9222
> Fax: +1-310-442-1162


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 00:05:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16515
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 00:05:02 -0400 (EDT)
Received: from standards (47.234.32.16:4807) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB734CB@standards.nortelnetworks.com>; Mon, 5 Jun 2000 23:55:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0780 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Jun 2000 23:55:55 -0400
Received: from qhars002.nortel.com (47.101.112.102:58259) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB734CA@standards.nortelnetworks.com>; Mon, 5 Jun 2000
          23:55:55 -0400
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          qhars002.nortel.com; Tue, 6 Jun 2000 04:57:13 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Mon, 5 Jun 2000 23:56:58 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <L3HQDB5A>; Mon, 5 Jun 2000 23:57:01 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480A1C@zcard00g.ca.nortel.com>
Date:         Mon, 5 Jun 2000 23:56:58 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      MGC-Initiated Handoff
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Discussion with my colleagues has indicated that the issue as I raised it is
only the tip of a large iceberg.  In fact, Megaco development has focussed
on a set of possible control arrangements which admits of some variety but
does not cover all the cases of practical interest.  One of my colleagues is
preparing an I-D which will propose a new set of control arrangements for
study based on our experience with deployment of a softswitch-based carrier
network.  If the WG is favourable, I will propose that we take up this study
as an extension of the Megaco protocol.  In ITU-T terms, this would be a new
H.248 Annex or the beginnings of H.248v2, preferably the former to make it
easier to specify whether a particular MG supports the alternative
arrangement.

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 02:20:13 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28963
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 02:20:12 -0400 (EDT)
Received: from standards (47.234.32.16:4857) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73540@standards.nortelnetworks.com>; Tue, 6 Jun 2000 2:11:19 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0924 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 02:11:19 -0400
Received: from bfgbhome.inetint.com (tnt-dal-42-243.dallas.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7353F@standards.nortelnetworks.com>; Tue, 6 Jun 2000 2:11:17
          -0400
Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id
          BAA08006; Tue, 6 Jun 2000 01:19:26 -0500
References: <C51ED84B6F47D211917A0000F8BCBD1103858566@zcard00g.ca.nortel.com>
            <393AB81A.C9A5637B@usa.alcatel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Message-ID:  <20000606011922.A7647@inet.com>
Date:         Tue, 6 Jun 2000 01:19:26 -0500
Reply-To: brian.bidulock@inet.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Brian F. G. Bidulock" <brian.bidulock@inet.com>
Organization: Inet Technologies, Inc.
Subject:      Re: MGC-Initiated Control
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <393AB81A.C9A5637B@usa.alcatel.com>; from
              Chuong.Nguyen@USA.ALCATEL.COM on Sun, Jun 04,
              2000 at 03:12:11PM -0500

Chuong,

I don't mean to single out your note, but to continue along this thread.

I have seen a good number of implementations of control protocols where
the client connects to the server in the fashion you and Bharat
describe.  However, consider the practicality of this.  We are faced
with the reality that there are MGC platforms which can sustain tens of
millions of BHCC and support towards a million ports of MG devices.  It
is clearly possible today that one MGC may serve thousands or even
hundreds of thousands of discrete MG devices.  In this arrangement, MGCs
are built for fault-tolerance and extreme reliability.  MGs, due to
their multitude, require far less reliability.

Please, consider the case of a system recovering from a network outage,
where thousands and thousands of MG devices are all hunting through
their (short) lists of MGCs.  Many devices of the same kind can easily
collide in their attempt to open a transport connection to the MGC.

Consider the case where the MGs come up first.  They will be hunting for
an MGC which does not exist.  Several choices come to mind:

  (1) continue hunting indefinitely (because the system MUST come up on
      its own: manually resetting hundreds of thousands of MG devices is
      not an option).

  (2) after hunting for some time, fall back to a procedure which
      permits an MGC to indicate when it is available.

Just the hunting itself causes unnecessary network traffic and
congestion during recovery.  Network outages of sufficient length also
makes the hunting largely futile.

When the MGC comes up first, it must still ascertain the status of each
of the MG devices.  Without the ability to interrogate them (it just
"waits" for them to connect), little information can be had about the
health of the system at the "controller".  Also, if (2) is used at the
MG, as questioned in another message on this thread, how does the MGC
know (or know when) to initiate a connection to any given MG device?
Perhaps after a timeout?  A timeout would delay the recovery of a system
which is already in jeopardy.

Contrast this with the opposite case: where it would be the
responsibility of the MGC to connect to the MG, and the responsibility
of the MG to "listen" for the MGC to connect (i.e.  the "controlled"
device waits for the "controller").

This would permit a recovering MGC or an MGC in a recovering network to
coordinate with its peer MGCs and then establish the connections to
thousands of MGs in an orderly and controlled fashion.

As to whether the MG is "married" or not (i.e., whether it knows of the
MGC before permitting it to connect) is a network management issue.  Who
connects and who listens is clearly an initialization, switch-over and
recovery issue.

Consider also that the MG is really the server in this case anyway: it
is providing specific gateway services to a general purpose controller
client.  It just so happens that the servers are many and the clients
are few.

Also consider that using Berkeley TCP Sockets in the above scenario,
having the MGC "listen" and "accept" requires double the number of file
descriptors for sockets (thousands for the listening socket, thousands
for the accepting socket), already taxing a model which doesn't scale
well.  Having the MG listen means that it only requires a handful of
control sockets (where it may need a plethora of RTP/RTCP sockets,
thankfully UDP or IP, anyways).

Reversing the connection approach altogether would not overly tax even
the smallest of embedded MGs, whereas it permits the MGC and the
resulting system to scale much larger and recover or switch-over in an
orderly fashion.

Also, I can't conceive of a case where one MG would have thousands of
MGCs controlling it.  Can you?

If one really wants loose coupling in the model (such as independent
Mug's having the decision on which controller to connect to at a given
point in time), it is far better to use a registration process rather
than connections.  For example, when a host goes to establish a
connection on the Internet, it performs a DNS query (using a UDP port)
to discover the IP address of the server before connecting.  When a host
goes to access a file share, it checks with a naming service on a UDP
port as well.  This permits the controller to throttle registrations,
the result of which is to establish a connection to the requesting
device.  Even mobile telephone network work this way.  It scales better.

On Sun, 04 Jun 2000, Chuong Nguyen wrote:

> Hi Tom
>
> I think Bharat brings up a good points.
>
> For TCP there were some discussions on the list way back that MG
> always has to initiated the TCP connect to MGC before any
> ServiceChange can be sent from MG to MGC.  Also that MGC is the one
> that should initiate a TCP accept and MG never initiates a TCP accept.
>
> Your proposal of having MGC sends a ServiceChange to MG would require
> MGC to initiate a TCP connect to the MG which means MG has to initiate
> a TCP accept by default to listen for MGC trying to connect to MG.
>
> Can't we just leave everything as is and let MG through NM or other
> schema to determine whose its controlling MGC has to be and it is up
> to the MG to connect to MGC?  If all else fails, there is always the
> human out there to intervene and make thing right.
>
> If you really think your proposal is needed, then some words should be
> added to clarify TCP implementation before any ServiceChange is sent.
>
> This also complicate our design, our implementation is that MGC does
> not need to know before registration whether MG is text or binary
> encoding.  It is by virtual of which port the MG uses to registrate
> w/MGC determines its encoding.
>
> Chuong
>
>
[snip]

--
Brian F. G. Bidulock
Director GeoGate SW Development
Network Products, Inet Technologies Inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 03:46:26 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29410
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 03:46:25 -0400 (EDT)
Received: from standards (47.234.32.16:2579) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73570@standards.nortelnetworks.com>; Tue, 6 Jun 2000 3:37:26 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0980 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 03:37:26 -0400
Received: from ish7.ericsson.com.au (203.61.155.111:63351) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7356D@standards.nortelnetworks.com>; Tue, 6 Jun 2000 3:27:25
          -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id RAA04891; Tue, 6
          Jun 2000 17:34:07 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA12553; Tue, 6
          Jun 2000 17:34:48 +1000 (EST)
Received: from ericsson.com (7-147.epa.ericsson.se [146.11.7.147]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA16081; Tue,
          6 Jun 2000 17:35:10 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480A1C@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <393CA978.E7917992@ericsson.com>
Date:         Tue, 6 Jun 2000 17:34:16 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: MGC-Initiated Handoff
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

Can we decide when we see the draft? Typically people like to see things
before they accept it.

Cheers, Christian

Tom-PT Taylor wrote:
>
> Discussion with my colleagues has indicated that the issue as I raised it is
> only the tip of a large iceberg.  In fact, Megaco development has focussed
> on a set of possible control arrangements which admits of some variety but
> does not cover all the cases of practical interest.  One of my colleagues is
> preparing an I-D which will propose a new set of control arrangements for
> study based on our experience with deployment of a softswitch-based carrier
> network.  If the WG is favourable, I will propose that we take up this study
> as an extension of the Megaco protocol.  In ITU-T terms, this would be a new
> H.248 Annex or the beginnings of H.248v2, preferably the former to make it
> easier to specify whether a particular MG supports the alternative
> arrangement.
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 06:07:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00467
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 06:07:18 -0400 (EDT)
Received: from standards (47.234.32.16:2822) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB735D8@standards.nortelnetworks.com>; Tue, 6 Jun 2000 5:58:26 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1098 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 05:58:26 -0400
Received: from june.idc1.level3.com (209.245.18.7:53344) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB735D0@standards.nortelnetworks.com>; Tue, 6 Jun 2000 5:48:26
          -0400
Received: from f1ee40-03.idc1.level3.com (hme0.f1ee40-03.idc1.oss.level3.com
          [10.1.144.140]) by june.idc1.level3.com (8.9.3/8.9.3) with ESMTP id
          JAA13180; Tue, 6 Jun 2000 09:56:47 GMT
Received: from l3londmail01.l3.com (localhost [127.0.0.1]) by
          f1ee40-03.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id DAA29045;
          Tue, 6 Jun 2000 03:56:46 -0600 (MDT)
Received: by l3londmail01.eu.l3.com with Internet Mail Service (5.5.2650.10) id
          <LSG7GKZ3>; Tue, 6 Jun 2000 10:54:09 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <6FA15EC018C1D211AA4C0008C70D033006A5B131@l3londmail02.eu.l3.com>
Date:         Tue, 6 Jun 2000 10:55:25 +0100
Reply-To: "Quan, Michael" <Michael.Quan@LEVEL3.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Quan, Michael" <Michael.Quan@LEVEL3.COM>
Subject:      subscribe MEGACO Michael Quan
X-To:         "listserv@standards.nortelnetworks.com"
              <listserv@standards.nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Dear Sir/Madam,

Please could put in your distribution list for the MEGACO working group.

Thanks,

Michael Quan

International Voice Engineering
Level (3) Communications
66 Prescot St
London, E1 8HG

Tel:                +44 (0)20 7864 4444
Direct Line:  +44 (0)20 7864 0941
Mobile:         +44 (0)788 0506108
Fax:                +44 (0)20 7864 4488
Email:             michael.quan@level3.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 06:47:29 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00649
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 06:47:28 -0400 (EDT)
Received: from standards (47.234.32.16:4300) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7360E@standards.nortelnetworks.com>; Tue, 6 Jun 2000 6:37:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1171 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 06:37:11 -0400
Received: from relay1.alcatel.be (alc119.alcatel.be) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73608@standards.nortelnetworks.com>; Tue, 6 Jun 2000 6:27:06
          -0400
Received: from btmq9s.rc.bel.alcatel.be (localhost [127.0.0.1]) by
          relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id e56AYL904359; Tue, 6
          Jun 2000 12:34:21 +0200 (MET DST)
Received: from alcatel.be (btm4ds [138.203.66.64]) by btmq9s.rc.bel.alcatel.be
          (8.8.8+Sun/8.8.8/1.1) with ESMTP id MAA22951; Tue, 6 Jun 2000
          12:34:20 +0200 (MET DST)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <393CD39D.C69CFB3C@alcatel.be>
Date:         Tue, 6 Jun 2000 12:34:05 +0200
Reply-To: Bouwen Jan <jan.bouwen@ALCATEL.BE>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Bouwen Jan <jan.bouwen@ALCATEL.BE>
Subject:      Repost: Megaco TerminationID and IUA Interface Identifier
X-To:         Sigtran <SIGTRAN@STANDARDS.NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Reposted because of earlier mail-server problems.

Hi all,

Megaco will be used in combination with SCTP+IUA in Media Gateways
providing ISDN Access. The ISDN terminations are referenced in Megaco
with a TerminationID, and in IUA with an Interface Identifier.

The Megaco TerminationID is
- a string for text encoding;
- a binary identifier of up to 8 octets for binary encoding.

In an earlier version of IUA, the Interface Identifier was a string,
which made it possible to use the same reference in text-encoded-Megaco
and IUA messages (see also draft-bouwen-megaco-isdn-00.txt for
examples).

As Brian Link pointed out to me, the latest version of IUA
(draft-ietf-sigtran-iua-02.txt) specifies that a 4 octet binary
identifier is to be used for the Interface Identifier.

I think it would be practical if the same ID could be used both for
Megaco and IUA. This would mean that IUA would have to be modified to
allow for the Interface Identifier:
- a string, when the text encoded version of Megaco is used;
- a binary identifier of up to 8 octets, for binary encoding of Megaco.

Perhaps we need two different Tags for this: one for a text string,
another one for a binary identifier.

Any thoughts ?

Jan
--
Jan Bouwen                                        ________________
__________________________________________________\              /______
Research Engineer, Network Architecture (DN9)      \   ALCATEL  /
E-mail : jan.bouwen@alcatel.be                  Network Strategy Group
Tel    : +32 3 240 87 72                        Francis Wellesplein  1
Fax    : +32 3 240 99 32                       B-2018 Antwerpen BELGIUM
_______________________________________________________\    /___________
                                                        \  /
                                                         \/


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 07:28:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01005
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 07:28:59 -0400 (EDT)
Received: from standards (47.234.32.16:2127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73643@standards.nortelnetworks.com>; Tue, 6 Jun 2000 7:20:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1240 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 07:20:02 -0400
Received: from bells.cs.ucl.ac.uk by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB73640@standards.nortelnetworks.com>; Tue, 6 Jun 2000 7:10:00
          -0400
Received: from 213.108.4.90 by bells.cs.ucl.ac.uk with Internet SMTP id
          <g.15586-0@bells.cs.ucl.ac.uk>; Tue, 6 Jun 2000 12:18:08 +0100
References: <4FBEA8857476D311A03300204840E1CF678410@whq-msgusr-02.fore.com>
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 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Message-ID:  <003b01bfcfa8$fc7bf260$5a046cd5@kallisto>
Date:         Tue, 6 Jun 2000 12:18:46 +0100
Reply-To: Dimitris Terzis <D.Terzis@CS.UCL.AC.UK>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Dimitris Terzis <D.Terzis@CS.UCL.AC.UK>
Subject:      Re: Gateways and call routing
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Brian...


> > (d) Is there any compelling reason why we should have
> > Signalling Gateways that are (essentially) SCN clients
> > (Signalling Processors), following the H.323 model,
> > and then need mechanisms like SIGTRAN (RFC 2719)
> > to communicate with the MGC?
>
> Oh most definitely.  Suppose that the MG was connected to a PBX.
> Suppose the PBX used ISDN signalling.  In this case, the MGC would
> terminate Q.931.  However, the MG is the one that has the physical
> connection, so the MG would terminate the signalling at Q.921,
> and send the Q.931 to the MGC via SCTP.  In this case the SG is
> collocated with the MG.
>
> The other obvious case is where the MGC is doing interwork to the
> PSTN.  In this case you might have SS7 links which are terminated
> in a device which is not the MGC.  So, the SG terminates SS7 at, say
> MTP2, and sends MTP3 to the MGC via SCTP.

To clarify a bit my initial question, I didn't wonder if we need SIGTRAN,
but rather whether the SG could be something more generic/powerful...


> > Why wouldn't we want to move all the external signalling
> > functions to the SG (i.e., ask _it_ to do the translation
> > between SCN and IP signalling), and only use the
> > MGC as an internal management function, which also
> > collects and advertises the gateway capabilities to the
> > outside world?
>
> We currently define the SG as a relatively dumb device, as we
> define the MG as a relatively dumb device.  Your definition of
> the SG as being a complete signalling interwork function overlaps
> with our current definition of MGC.
>
> Note that your definition could be made to work with the latter example
> of PSTN signalling interwork, but not the former example of ISDN
> signalling interwork.

I don't quite understand this... Why wouldn't it work for ISDN? Unless you
are referring to the need for a SG-MGC protocol (Q.931 in your example),
which is of course true but does not necessarily need to be (part of) the
GSTN signalling protocol, everything else is just a
point of view - i.e., where and how we define the network elements inside
the gateway.

If we don't insist that the SG be just a SCN termination point, I believe it
should work (with perhaps different scaling, path optimisation and
distributed processing needs/behaviour), as a matter of fact I 've
implemented a simple testbed (a GSTN-IP gateway) for the needs of my PhD
that does exactly that...


> At any rate, you are trying to redefine terms that we have
> gradually come to consensus on, and, despite the fact that there
> isn't a "right" or a "wrong" way to define anything, I believe that
> you might be better off accepting the current definition.

Not redefine, just wonder if this is really the best way. Even the current
(H.323-biased) gateway model seems under alteration, as Jonathan Rosenberg
pointed out in a relevant discussion we 've recently had in the IPTEL list.
The idea is to extract the Application Server from the MGC and SoftSwitch,
as he said, does exacltly that...


> > (e) Is the above model suitable for "pure IP" gateways?
> > What happens, for example, when we want to connect an
> > H.323 subnet to a SIP one? Or when we want to use only
> > the media resources of a gateway (e.g., its codecs) in the
> > middle of a call?
>
> In the former case you need a SIP-H.323 interwork function,
> which is neither an MGC or MG.  It could use an SG, but I suspect that
> it would simply interwork H.323 to SIP.  There is effort to define
> such an interworking function underway.

I think that a generic SG model, were the SG does all the signalling
(including conversions) wraps nicely around this.


> In the latter case of codec change in the middle of a call, it would
> be very reasonable to have the codecs in an MG.  The controlling
> MGC would have to somehow be in the middle of a signalling path.

Agreed.


> The SIP/H.323 signalling mechanisms don't have explicit ways to do
> that, but it can be constructed as a set of connections.  Use of
> Megaco for this application is a very good use of the protocol.
> Of course nothing stops you from making a single box with both the
> MG and MGC functions, just like a current H.323 gateway, and then
> you wouldn't need Megaco.  I'd be inclined to keep them separate,
> but that's a product design decision.

I am also of the opinion to have these items separate. As I wrote above,
having a gateway with very few generic internal types of components (SG, MG,
MGC) and well-defined ways (API's, protocols) of interaction among these
components, seems to me as good enough a simplification of the IP Telephony
network model, leaving only Location Servers (Call Routers), Gateways and
Terminals to worry about...

Cheers,

Dimitris

---------------------------------------------------------------
    Dimitris Terzis
    PhD Candidate - Department of Computer Science, UCL
    E-Mail: D.Terzis@cs.ucl.ac.uk
    URL : http://www.cs.ucl.ac.uk/staff/D.Terzis/
---------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 07:41:06 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01166
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 07:41:05 -0400 (EDT)
Received: from standards (47.234.32.16:2127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73671@standards.nortelnetworks.com>; Tue, 6 Jun 2000 7:32:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1306 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 07:32:09 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB73670@standards.nortelnetworks.com>; Tue, 6 Jun 2000 7:32:09
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id HAA06608; Tue, 6 Jun 2000 07:40:24 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id HAA01659; Tue, 6 Jun 2000 07:40:24 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <M2VDNWXC>; Tue, 6 Jun 2000 07:40:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67842D@whq-msgusr-02.fore.com>
Date:         Tue, 6 Jun 2000 07:40:24 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: H.248 Packages - what goal?
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I think that is a good idea, and I will incorporate it into the
the next draft of the ATM package.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Monday, June 05, 2000 9:09 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: H.248 Packages - what goal?
>
>
> G'Day Brian,
>
> What I miss from the whole effort of using SDP (and Annex C for that
> matter) is how you specify a subset of properties that a MG must
> implement?
>
> If I have a package then I know I must implement all the properties.
> However with SDP and Annex C I'm left with a bucket of
> properties/values, which one's do I implement for a
> particular function?
> how can I extend these?
>
> The required SDP properties should at least be mentioned in
> the package
> that would use them. This would be aside from the global
> issue of adding
> ATM parameters to SDP for SIP/RTSP etc....
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > Christian
> >
> > The Package we propose has little more than events for
> > setup failure and codec change, as well as statistics.  It has
> > no parameters.  We are trying to align the parameters in the
> > SDP extension to Annex C, but we do that entirely in SDP,
> > not in the Package.
> >
> > If you need two more parameters in the future, I think you
> > write a document and add them to SDP.  I'm not really sure
> > how you add things to Annex C.  I understand that it would
> > be nice to get the whole thing into a package, but I don't
> > see how to reconcile that with the SDP extension process,
> > especially when, as we are hear, the effort is defined to
> > be a one-document-for-all H.248/MGCP/SIP/RTSP/...
> >
> > There are discussions of reworking SDP (SDPng).  I plan to
> > participate in that process to make sure that things get
> > better with respect to this issue.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > Sent: Monday, June 05, 2000 12:00 AM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: H.248/BICC discussions
> > >
> > >
> > > G'Day Brian,
> > >
> > > I support the idea that you're updating SDP and then writing
> > > a Package.
> > > I gather that as the properties will be defined in a package that
> > > they'll be able to be used by both binary and text forms
> of H.248. I
> > > think that having several packages extending each as
> proposed by Mike
> > > Brown is a good way of approaching things.
> > >
> > > In the future though I don't know that people will want
> to go through
> > > the effort of setting up email exploders/ writing drafts/
> > > packages etc.
> > > for what may amount to 2 values. A package could be a way of
> > > doing this.
> > >
> > > Cheers, Christian
> > >
> > > PS: What's MGCP??? ;-)
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > It's not the idea that Megaco can extend SDP with MMUSIC in
> > > the loop.
> > > > It's whether the form to do this is a package.  It's
> probably all
> > > > in the details.
> > > >
> > > > I agree that Tom's basic premise, that a Megaco
> sponsored standards
> > > > track RFC that defines an extension is a perfectly
> appropriate way
> > > > to define an extension.  The package mechanism is
> defined as pretty
> > > > general, and of course is useable by parties other than
> the IETF (as
> > > > is the SDP extension mechanism).  If we made such a
> decision than
> > > > anyone could come along, define a megaco package that
> added a media
> > > > parameter, and have the result be an extension to SDP.
> > > >
> > > > Now, it's certainly true that anyone can define an
> extension to SDP
> > > > by just doing an IANA registration of a tag, so this
> isn't very much
> > > > different, it's just that doing it as a Megaco package
> makes the SDP
> > > > extension indirect -- is that what we want?
> > > >
> > > > Consider the alternative - what we are doing now.  We
> are writing
> > > > an I-D, with the intention of getting it published as
> an MMUSIC RFC
> > > > that defines an ATM extension to SDP.  Then we have another
> > > I-D that will be
> > > > published as a Megaco RFC that defines a Megaco package
> using that
> > > > SDP extension.  We also have an MGCP package, but that is
> > > outside the
> > > > scope of this discussion at the moment.  Is that not a
> > > preferable way
> > > > to get the job done?
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Scott Bradner [mailto:sob@harvard.edu]
> > > > > Sent: Friday, June 02, 2000 3:29 PM
> > > > > To: Rosen, Brian
> > > > > Cc: mankin@isi.edu; megaco@standards.nortelnetworks.com
> > > > > Subject: Re: H.248/BICC discussions
> > > > >
> > > > >
> > > > > > Well, I'm having a problem with the idea that a package can
> > > > > extend SDP.
> > > > >
> > > > > SDP is designed to be extensible - it is reasonable for other
> > > > > IETF working
> > > > > groups to suggest extensions, the mmusic WG should be in the
> > > > > loop during
> > > > > the discussions but having the group that has the best
> > > knowledge of
> > > > > what the extensions are for be in the drivers seat means
> > > it is more
> > > > > likly to get done in a reasonable period of time - mmusic
> > > can provide
> > > > > feedback if they think that the proposed extensions run
> > > > > counter to the
> > > > > SDP design goals or feel that there is a better way to do the
> > > > > function.
> > > > >
> > > > > Scott
> > > > >
> > >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 07:44:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01177
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 07:44:02 -0400 (EDT)
Received: from standards (47.234.32.16:2127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73683@standards.nortelnetworks.com>; Tue, 6 Jun 2000 7:34:54 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1299 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 07:34:54 -0400
Received: from dns2.spisystems.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB7366A@standards.nortelnetworks.com>; Tue, 6 Jun 2000 7:24:53
          -0400
Received: from david (unverified [63.66.182.150]) by spi16.spisystems.com
          (EMWAC SMTPRS 0.83) with SMTP id <B0001068267@spi16.spisystems.com>;
          Tue, 06 Jun 2000 11:31:04 +0000
X-Distribution: Bulk
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Priority: normal
Message-ID:  <393C9AEA.6299.1EF6928@localhost>
Date:         Tue, 6 Jun 2000 06:32:10 -0700
Reply-To: Dialing Dave at SCI <sci@SERVICECONCEPTSINT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Dialing Dave at SCI <sci@SERVICECONCEPTSINT.COM>
Subject:      WE ARE BLABBERMOUTHS
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7BIT

Dear Fellow Computer Trader.

I obtained your email address by searching the internet for web pages that
included the words "used, Gateway, monitor, & sales". I will assume that I may send
you our requirements and offer broadcasts if you don't return this email with
REMOVE in the subject line. If you are already receiving our broadcasts
than let me take this oppurtunity to thank you for reviewing same.

If you wish to yell at (me) I can be reached at 817-860-7483. My name is Dave Henkin
and I am known among the 13,000 traders that presently receive our list as Dialing Dave.

SCI is a LIST BROKER. What this means is that we have brokers that are on the phone
all day that take phone calls from traders that have items that they want to buy and sell.
We then post these and transmit the requirements and offers to the major computer
trading organizations and to approximately 13,000 traders on our broadcast list. We
also have a 21,000 sq. foot warehouse to store  the products that we purchase and
redistribute. We have a $5,000,000.00 purchase order funding line with Bankers
Mutual of Florida. Of course our bank and trades are available on request

You may feel free to call us and have your requirements and offers posted
AT NO CHARGE as we make our margins on the selling or
buying of your product.

As we go out to +13,000 people nightly, WE ARE BLABBERMOUTHS so please
don't give us a product to list that you are concerned about affecting market
conditions. We couldn't keep a secret if we tried and we will violate the secret
+10,000 times nightly. We use the Hughes Aircraft System Galaxy 4 Satellite
to transmit approximately 3000 emails/second. We also have the capability
to send out fax transmissions at the rate of 20,000 per minute  NO KIDDING
but the cost is prohibitive compared to the internet.

You Will Be Receiving Our First want To Buy /Offer List Shortly


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 07:54:44 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01236
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 07:54:44 -0400 (EDT)
Received: from standards (47.234.32.16:2127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7369E@standards.nortelnetworks.com>; Tue, 6 Jun 2000 7:45:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1364 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 07:45:45 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB7369D@standards.nortelnetworks.com>; Tue, 6 Jun 2000 7:45:44
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id HAA07570; Tue, 6 Jun 2000 07:54:04 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id HAA03523; Tue, 6 Jun 2000 07:54:04 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <M2VDNXBY>; Tue, 6 Jun 2000 07:54:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67842E@whq-msgusr-02.fore.com>
Date:         Tue, 6 Jun 2000 07:54:04 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: MGC-Initiated Control
X-To:         "brian.bidulock@inet.com" <brian.bidulock@inet.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In the development of the protocol, and this particular issue,
all of the points you raised were brought up and discussed.
While there is clearly no single "right" answer, the consensus
opinion, weighing several issues, of which this was a big one,
we decided to have the MG initiate the process of creating
a control association.  If you go through the archives,
you will find several messages on the subject, and there was
a lot of discussion in design team meetings.

Having said that, we also decided that the mechanisms we had
were probably not sufficient to cover all the kinds of networks
users and vendors contemplated, and we expected this area to
undergo significant change.  For example, I believe that it
is not a good idea to provision either the MGs or the MGCs;
rather there should be a directory or discovery protocol.

At the moment, the protocol specifies MG initiated
control establishment.  It doesn't PROHIBIT anything,
but if you want interoperable devices, I suggest you implement
that mechanism, at least.

Brian


> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:brian.bidulock@inet.com]
> Sent: Tuesday, June 06, 2000 2:19 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: MGC-Initiated Control
>
>
> Chuong,
>
> I don't mean to single out your note, but to continue along
> this thread.
>
> I have seen a good number of implementations of control
> protocols where
> the client connects to the server in the fashion you and Bharat
> describe.  However, consider the practicality of this.  We are faced
> with the reality that there are MGC platforms which can
> sustain tens of
> millions of BHCC and support towards a million ports of MG
> devices.  It
> is clearly possible today that one MGC may serve thousands or even
> hundreds of thousands of discrete MG devices.  In this
> arrangement, MGCs
> are built for fault-tolerance and extreme reliability.  MGs, due to
> their multitude, require far less reliability.
>
> Please, consider the case of a system recovering from a
> network outage,
> where thousands and thousands of MG devices are all hunting through
> their (short) lists of MGCs.  Many devices of the same kind can easily
> collide in their attempt to open a transport connection to the MGC.
>
> Consider the case where the MGs come up first.  They will be
> hunting for
> an MGC which does not exist.  Several choices come to mind:
>
>   (1) continue hunting indefinitely (because the system MUST
> come up on
>       its own: manually resetting hundreds of thousands of MG
> devices is
>       not an option).
>
>   (2) after hunting for some time, fall back to a procedure which
>       permits an MGC to indicate when it is available.
>
> Just the hunting itself causes unnecessary network traffic and
> congestion during recovery.  Network outages of sufficient length also
> makes the hunting largely futile.
>
> When the MGC comes up first, it must still ascertain the
> status of each
> of the MG devices.  Without the ability to interrogate them (it just
> "waits" for them to connect), little information can be had about the
> health of the system at the "controller".  Also, if (2) is used at the
> MG, as questioned in another message on this thread, how does the MGC
> know (or know when) to initiate a connection to any given MG device?
> Perhaps after a timeout?  A timeout would delay the recovery
> of a system
> which is already in jeopardy.
>
> Contrast this with the opposite case: where it would be the
> responsibility of the MGC to connect to the MG, and the responsibility
> of the MG to "listen" for the MGC to connect (i.e.  the "controlled"
> device waits for the "controller").
>
> This would permit a recovering MGC or an MGC in a recovering
> network to
> coordinate with its peer MGCs and then establish the connections to
> thousands of MGs in an orderly and controlled fashion.
>
> As to whether the MG is "married" or not (i.e., whether it
> knows of the
> MGC before permitting it to connect) is a network management
> issue.  Who
> connects and who listens is clearly an initialization, switch-over and
> recovery issue.
>
> Consider also that the MG is really the server in this case anyway: it
> is providing specific gateway services to a general purpose controller
> client.  It just so happens that the servers are many and the clients
> are few.
>
> Also consider that using Berkeley TCP Sockets in the above scenario,
> having the MGC "listen" and "accept" requires double the
> number of file
> descriptors for sockets (thousands for the listening socket, thousands
> for the accepting socket), already taxing a model which doesn't scale
> well.  Having the MG listen means that it only requires a handful of
> control sockets (where it may need a plethora of RTP/RTCP sockets,
> thankfully UDP or IP, anyways).
>
> Reversing the connection approach altogether would not overly tax even
> the smallest of embedded MGs, whereas it permits the MGC and the
> resulting system to scale much larger and recover or switch-over in an
> orderly fashion.
>
> Also, I can't conceive of a case where one MG would have thousands of
> MGCs controlling it.  Can you?
>
> If one really wants loose coupling in the model (such as independent
> Mug's having the decision on which controller to connect to at a given
> point in time), it is far better to use a registration process rather
> than connections.  For example, when a host goes to establish a
> connection on the Internet, it performs a DNS query (using a UDP port)
> to discover the IP address of the server before connecting.
> When a host
> goes to access a file share, it checks with a naming service on a UDP
> port as well.  This permits the controller to throttle registrations,
> the result of which is to establish a connection to the requesting
> device.  Even mobile telephone network work this way.  It
> scales better.
>
> On Sun, 04 Jun 2000, Chuong Nguyen wrote:
>
> > Hi Tom
> >
> > I think Bharat brings up a good points.
> >
> > For TCP there were some discussions on the list way back that MG
> > always has to initiated the TCP connect to MGC before any
> > ServiceChange can be sent from MG to MGC.  Also that MGC is the one
> > that should initiate a TCP accept and MG never initiates a
> TCP accept.
> >
> > Your proposal of having MGC sends a ServiceChange to MG
> would require
> > MGC to initiate a TCP connect to the MG which means MG has
> to initiate
> > a TCP accept by default to listen for MGC trying to connect to MG.
> >
> > Can't we just leave everything as is and let MG through NM or other
> > schema to determine whose its controlling MGC has to be and it is up
> > to the MG to connect to MGC?  If all else fails, there is always the
> > human out there to intervene and make thing right.
> >
> > If you really think your proposal is needed, then some
> words should be
> > added to clarify TCP implementation before any
> ServiceChange is sent.
> >
> > This also complicate our design, our implementation is that MGC does
> > not need to know before registration whether MG is text or binary
> > encoding.  It is by virtual of which port the MG uses to registrate
> > w/MGC determines its encoding.
> >
> > Chuong
> >
> >
> [snip]
>
> --
> Brian F. G. Bidulock
> Director GeoGate SW Development
> Network Products, Inet Technologies Inc.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 09:42:15 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01519
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 09:42:14 -0400 (EDT)
Received: from standards (47.234.32.16:2127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB736C5@standards.nortelnetworks.com>; Tue, 6 Jun 2000 8:01:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1413 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 08:01:15 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB736C4@standards.nortelnetworks.com>; Tue, 6 Jun 2000 8:01:11
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id SAA28154 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 6 Jun 2000 18:26:16 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652568F6.004205B2 ; Tue, 6 Jun 2000 17:31:08 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652568F6.00420346.00@sandesh.hss.hns.com>
Date:         Tue, 6 Jun 2000 17:33:24 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sachin Mittal <samittal@HSS.HNS.COM>
Subject:      Characteristics of Properties for Base Root Package
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It is not specified that the properties in base root package are read/write or
read-only

Following should be added :

MaxNrOfContexts - read-only
MaxTerminationsPerContexts - read-only
normalMGExecutionTime - read/write
normalMGCExecutionTime - read/write
ProvisionalResponseTimerValue - read/write


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 09:42:15 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01521
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 09:42:15 -0400 (EDT)
Received: from standards (47.234.32.16:2127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB736DB@standards.nortelnetworks.com>; Tue, 6 Jun 2000 8:10:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1412 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 08:10:57 -0400
Received: from ren.orange.co.uk (news-gw1.orange.co.uk) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB736C3@standards.nortelnetworks.com>; Tue, 6 Jun 2000 8:00:52
          -0400
Received: from ruddick (ruddick.orange.co.uk [172.19.16.129]) by
          ren.orange.co.uk (Pro-8.9.3/8.9.3) with SMTP id NAA12348 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 6 Jun 2000 13:09:13 +0100
          (BST)
Received: by ruddick(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id
          802568F6.00420318 ; Tue, 6 Jun 2000 13:01:01 +0100
X-Lotus-FromDomain: HTLUK
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <802568F6.00420230.00@ruddick>
Date:         Tue, 6 Jun 2000 13:26:46 +0100
Reply-To: Jeni.NOTT@ORANGE.CO.UK
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Jeni.NOTT@ORANGE.CO.UK
Subject:      Please mail back with details of how to undelete the megaco
              service.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Please mail back with details of how to undelete the megaco service.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 09:53:52 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03613
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 09:53:51 -0400 (EDT)
Received: from standards (47.234.32.16:2899) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73744@standards.nortelnetworks.com>; Tue, 6 Jun 2000 9:44:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1566 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 09:44:53 -0400
Received: from qhars002.nortel.com (47.101.112.102:53610) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73743@standards.nortelnetworks.com>; Tue, 6 Jun 2000 9:44:53
          -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Tue, 6 Jun 2000 14:49:13 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Tue, 6 Jun 2000 09:15:33 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <L3HQDHJH>; Tue, 6 Jun 2000 09:15:36 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480A1E@zcard00g.ca.nortel.com>
Date:         Tue, 6 Jun 2000 09:15:30 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Please mail back with details of how to undelete the megaco s
              ervice.
X-To:         "Jeni.NOTT@ORANGE.CO.UK" <Jeni.NOTT@ORANGE.CO.UK>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

To subscribe to Megaco, send an E-mail to
listserv@standards.nortelnetworks.com, containing the single line
"subscribe megaco" (without the quotation marks).

To unsubscribe, send an E-mail to the same address containing the line
"signoff megaco" (without the quotation marks).

> -----Original Message-----
> From: Jeni.NOTT@ORANGE.CO.UK [SMTP:Jeni.NOTT@ORANGE.CO.UK]
> Sent: Tuesday, June 06, 2000 8:27 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Please mail back with details of how to undelete the megaco
> service.
>
> Please mail back with details of how to undelete the megaco service.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 10:15:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07098
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 10:15:01 -0400 (EDT)
Received: from standards (47.234.32.16:2899) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73776@standards.nortelnetworks.com>; Tue, 6 Jun 2000 10:05:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1626 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 10:05:54 -0400
Received: from qhars002.nortel.com (47.101.112.102:56655) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73775@standards.nortelnetworks.com>; Tue, 6 Jun 2000
          10:05:52 -0400
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          qhars002.nortel.com; Tue, 6 Jun 2000 15:13:37 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Tue, 6 Jun 2000 10:09:53 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <L3HQDKG6>; Tue, 6 Jun 2000 10:09:23 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480A22@zcard00g.ca.nortel.com>
Date:         Tue, 6 Jun 2000 10:09:20 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: MGC-Initiated Handoff
X-To:         Christian Groves <Christian.Groves@ericsson.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Of course.

Since my note, Brian Bidulock has done a good job of expanding the
discussion.

> -----Original Message-----
> From: Christian Groves [SMTP:Christian.Groves@ericsson.com]
> Sent: Tuesday, June 06, 2000 3:34 AM
> To:   Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc:   ietf_megaco
> Subject:      Re: MGC-Initiated Handoff
>
> G'Day Tom,
>
> Can we decide when we see the draft? Typically people like to see things
> before they accept it.
>
> Cheers, Christian
>
> Tom-PT Taylor wrote:
> >
> > Discussion with my colleagues has indicated that the issue as I raised
> it is
> > only the tip of a large iceberg.  In fact, Megaco development has
> focussed
> > on a set of possible control arrangements which admits of some variety
> but
> > does not cover all the cases of practical interest.  One of my
> colleagues is
> > preparing an I-D which will propose a new set of control arrangements
> for
> > study based on our experience with deployment of a softswitch-based
> carrier
> > network.  If the WG is favourable, I will propose that we take up this
> study
> > as an extension of the Megaco protocol.  In ITU-T terms, this would be a
> new
> > H.248 Annex or the beginnings of H.248v2, preferably the former to make
> it
> > easier to specify whether a particular MG supports the alternative
> > arrangement.
> >
> > Tom Taylor
> > Phone and FAX: +1 613 736 0961
> > E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 10:21:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07721
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 10:21:36 -0400 (EDT)
Received: from standards (47.234.32.16:2899) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73793@standards.nortelnetworks.com>; Tue, 6 Jun 2000 10:12:40 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1620 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 10:12:40 -0400
Received: from bjsmtp1.163.net (202.108.255.250:33047) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73770@standards.nortelnetworks.com>; Tue, 6 Jun 2000
          10:02:38 -0400
Received: by bjsmtp1.163.net (Postfix, from userid 1005) id CAF441D0ECA1C; Tue,
          6 Jun 2000 22:15:29 +0800 (CST)
MIME-Version: 1.0
X-Priority: 3
X-Originating-IP: [203.197.174.223]
Message-ID:  <393D0781.20233@bjsmtp1.163.net>
Date:         Tue, 6 Jun 2000 22:15:29 +0800
Reply-To: jchristopher@163.NET
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Jean Christopher <jchristopher@163.NET>
Subject:      How many TCP and UDP connections can be established?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello , the list.

 Can we establish more than one TCP connection between
   MGC and MG for  transporting messages?
   (maybe one connection is not enough)
   and the same question for UDP connection.

 If we can , is there is max limit of connections?

Thanks

---------------------------------------------------------------
ÇëÖ§³ÖÖйú»¥ÁªÍø·¢Õ¹£¬²Î¼ÓÖйú»¥ÁªÍøÐÅÏ¢ÖÐÐÄ£¨CNNIC£©µ÷²é»î¶¯£¬
²¢ÉêÇëÆÀÑ¡ÓÅÐãÍøվͶƱȨ£¬Í¶³öÄã×îÄÜÓ°ÏìÖйúÍøÕ¾ÅÅÃûµÄһƱ¡£
ͶƱÍøÖ·£ºhttp://fsurvey.cnnic.net.cn/survey/index.html

http://www.163.net ÿÌ춼ÔÚΪÄú·þÎñµÄµç×ÓÓʾÖ
---------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 10:26:54 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07850
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 10:26:54 -0400 (EDT)
Received: from standards (47.234.32.16:2899) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB737AC@standards.nortelnetworks.com>; Tue, 6 Jun 2000 10:17:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1697 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 10:17:48 -0400
Received: from bjsmtp1.163.net (202.108.255.250:39110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB737AB@standards.nortelnetworks.com>; Tue, 6 Jun 2000
          10:17:46 -0400
Received: by bjsmtp1.163.net (Postfix, from userid 1005) id 512451CE7444C; Tue,
          6 Jun 2000 22:30:38 +0800 (CST)
MIME-Version: 1.0
X-Priority: 3
X-Originating-IP: [203.197.174.223]
Message-ID:  <393D0B0E.22494@bjsmtp1.163.net>
Date:         Tue, 6 Jun 2000 22:30:38 +0800
Reply-To: jchristopher@163.NET
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Jean Christopher <jchristopher@163.NET>
Subject:      Can we identify  calls from  messages ?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello, list

Can we identify  calls from  messages?
For example , just by 2 messages, can we judge if they are from
the same call or not?

Thanks



---------------------------------------------------------------
ÇëÖ§³ÖÖйú»¥ÁªÍø·¢Õ¹£¬²Î¼ÓÖйú»¥ÁªÍøÐÅÏ¢ÖÐÐÄ£¨CNNIC£©µ÷²é»î¶¯£¬
²¢ÉêÇëÆÀÑ¡ÓÅÐãÍøվͶƱȨ£¬Í¶³öÄã×îÄÜÓ°ÏìÖйúÍøÕ¾ÅÅÃûµÄһƱ¡£
ͶƱÍøÖ·£ºhttp://fsurvey.cnnic.net.cn/survey/index.html

http://www.163.net ÿÌ춼ÔÚΪÄú·þÎñµÄµç×ÓÓʾÖ
---------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 10:31:40 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08035
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 10:31:40 -0400 (EDT)
Received: from standards (47.234.32.16:2899) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB737C4@standards.nortelnetworks.com>; Tue, 6 Jun 2000 10:22:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1664 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 10:22:30 -0400
Received: from ogma.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB73792@standards.nortelnetworks.com>; Tue, 6 Jun 2000 10:12:29
          -0400
Received: from munich.cisco.com (munich.cisco.com [144.254.24.45]) by
          ogma.cisco.com (Postfix) with ESMTP id 85A3C22A for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue,  6 Jun 2000 16:20:51
          +0200 (MET DST)
Received: from hdoelz-8kcdt (mun-pan-usr-vlan13-dhcp12.cisco.com
          [144.254.27.148]) by munich.cisco.com (8.8.8+Sun/8.8.8) with SMTP id
          QAA26140 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 6 Jun 2000
          16:20:51 +0200 (MET DST)
X-Sender: hdoelz@munich.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
Mime-Version: 1.0
Content-Type: multipart/alternative; types="text/plain,text/html";
              boundary="=====================_22892796==_.ALT"
Message-ID:  <200006061420.QAA26140@munich.cisco.com>
Date:         Tue, 6 Jun 2000 16:21:15 +0100
Reply-To: Harald Doelz <hdoelz@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Harald Doelz <hdoelz@CISCO.COM>
Subject:      unsubscribe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--=====================_22892796==_.ALT
Content-Type: text/plain; charset="us-ascii"

Please unsubscribe Harald Doelz (hdoelz@cisco.com)
-------------------------------------------
Harald Doelz
Internetworking Consultant

Cisco Systems
Lilienthalstrasse 9
85399 Hallbergmoos

fixed:  +49(0)811 559 5408
mobile: +49(0)170 575 4276
mailto: hdoelz@cisco.com

--=====================_22892796==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Please <b>unsubscribe Harald Doelz (hdoelz@cisco.com)</b><br>
<div>-------------------------------------------</div>
<div>Harald Doelz</div>
<div>Internetworking Consultant</div>
<br>
<div>Cisco Systems</div>
<div>Lilienthalstrasse 9</div>
<div>85399 Hallbergmoos</div>
<br>
<div>fixed:&nbsp; +49(0)811 559 5408</div>
<div>mobile: +49(0)170 575 4276</div>
<div>mailto: hdoelz@cisco.com</div>
</html>

--=====================_22892796==_.ALT--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 10:36:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08147
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 10:36:59 -0400 (EDT)
Received: from standards (47.234.32.16:2899) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB737DC@standards.nortelnetworks.com>; Tue, 6 Jun 2000 10:27:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1759 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 10:27:52 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB737DB@standards.nortelnetworks.com>; Tue, 6 Jun 2000 10:27:52
          -0400
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com
          [171.68.116.221]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id
          HAA02441; Tue, 6 Jun 2000 07:35:57 -0700 (PDT)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Message-ID:  <4.3.1.2.20000606102949.00b44a40@dogwood.cisco.com>
Date:         Tue, 6 Jun 2000 10:34:36 -0400
Reply-To: Chip Sharp <chsharp@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chip Sharp <chsharp@CISCO.COM>
Subject:      Re: How many TCP and UDP connections can be established?
X-To:         jchristopher@163.NET
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <393D0781.20233@bjsmtp1.163.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA08147

At 10:15 PM 6/6/00 +0800, Jean Christopher wrote:
>Hello , the list.
>
>  Can we establish more than one TCP connection between
>    MGC and MG for  transporting messages?
>    (maybe one connection is not enough)
>    and the same question for UDP connection.

I don't know of anything in the spec that forbids the use of multiple TCP 
connections between MGC and MG.  However, I'm not an expert on the startup 
procedures and there may be a tie-in in there somewhere.

There is no connection in UDP, so there is no inherent limit. :-)
If what you mean is you want to run H.248/megaco over multiple port 
numbers, then I have the same answer as for TCP (above).  I don't see any 
advantages of running megaco over multiple UDP ports.


>  If we can , is there is max limit of connections?

I assume it would be the number of connections supported by your 
implementation.  That would be implementation-specific.  Note that if you 
use TCP, the MGC will have to support as many TCP connections as there are 
MGs (potentially).  If you have N TCP connections per MG, then you will 
have to find a MGC that supports N times the number of MGs TCP connections.

Chip


>Thanks
>
>---------------------------------------------------------------
>ÇëÖ§³ÖÖйú»¥ÁªÍø·¢Õ¹£¬²Î¼ÓÖйú»¥ÁªÍøÐÅÏ¢ÖÐÐÄ£¨CNNIC£©µ÷²é»î¶¯£¬
>²¢ÉêÇëÆÀÑ¡ÓÅÐãÍøվͶƱȨ£¬Í¶³öÄã×îÄÜÓ°ÏìÖйúÍøÕ¾ÅÅÃûµÄһƱ¡£
>ͶƱÍøÖ·£ºhttp://fsurvey.cnnic.net.cn/survey/index.html
>
>http://www.163.net ÿÌ춼ÔÚΪÄú·þÎñµÄµç×ÓÓʾÖ
>---------------------------------------------------------------


-------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.	
http://www.netaid.org   	
-------------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 12:30:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13709
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 12:30:20 -0400 (EDT)
Received: from standards (47.234.32.16:2940) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73896@standards.nortelnetworks.com>; Tue, 6 Jun 2000 12:21:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2001 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 12:21:11 -0400
Received: from bfgbhome.inetint.com (tnt-dal-42-241.dallas.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73895@standards.nortelnetworks.com>; Tue, 6 Jun 2000
          12:21:10 -0400
Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id
          LAA15450; Tue, 6 Jun 2000 11:29:22 -0500
Mail-Followup-To: "Rosen, Brian" <Brian.Rosen@marconi.com>,
                  MEGACO@STANDARDS.NORTELNETWORKS.COM
References: <4FBEA8857476D311A03300204840E1CF67842E@whq-msgusr-02.fore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Message-ID:  <20000606112922.A15241@inet.com>
Date:         Tue, 6 Jun 2000 11:29:22 -0500
Reply-To: brian.bidulock@inet.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Brian F. G. Bidulock" <brian.bidulock@inet.com>
Organization: Inet Technologies, Inc.
Subject:      Re: MGC-Initiated Control
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF67842E@whq-msgusr-02.fore.com>;
              from Brian.Rosen@marconi.com on Tue, Jun 06,
              2000 at 07:54:04AM -0400

Brian,

I have 1 MGC and 3000 MGs.  This is a real-world situation which we all
face in implementing PSTN gateways.  It is not a speculative architecture,
it is the predominate architecture: single MGC many MGs.  It would be
helpful if your answer could indicate why it it this way: discussion and
consensus are fine, but what are the technical reasons for taking the
current approach which outweigh the reality of its application?  What are
the known technical limitations of the current approach?  What is the
mechanism for change?

(Also, the WG archives are formidable: could you point to a thread?)

On Tue, 06 Jun 2000, Rosen, Brian wrote:

> In the development of the protocol, and this particular issue,
> all of the points you raised were brought up and discussed.
> While there is clearly no single "right" answer, the consensus
> opinion, weighing several issues, of which this was a big one,
> we decided to have the MG initiate the process of creating
> a control association.  If you go through the archives,
> you will find several messages on the subject, and there was
> a lot of discussion in design team meetings.
>
> Having said that, we also decided that the mechanisms we had
> were probably not sufficient to cover all the kinds of networks
> users and vendors contemplated, and we expected this area to
> undergo significant change.  For example, I believe that it
> is not a good idea to provision either the MGs or the MGCs;
> rather there should be a directory or discovery protocol.
>
> At the moment, the protocol specifies MG initiated
> control establishment.  It doesn't PROHIBIT anything,
> but if you want interoperable devices, I suggest you implement
> that mechanism, at least.
>
> Brian
>
--
Brian F. G. Bidulock


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 13:20:43 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15110
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 13:20:43 -0400 (EDT)
Received: from standards (47.234.32.16:4473) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB738B9@standards.nortelnetworks.com>; Tue, 6 Jun 2000 13:11:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2040 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 13:11:47 -0400
Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB738B2@standards.nortelnetworks.com>; Tue, 6 Jun 2000 13:01:46
          -0400
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall
          NT); Tue, 06 Jun 2000 10:05:05 -0700 (Pacific Daylight Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id
          <MKTFJ2WA>; Tue, 6 Jun 2000 09:57:27 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Message-ID:  <2E3FA0558747934A8F753CC533A3F6DF01FF56A8@red-msg-24.redmond.corp.microsoft.com>
Date:         Tue, 6 Jun 2000 09:56:21 -0700
Reply-To: Christian Huitema <huitema@MICROSOFT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Huitema <huitema@MICROSOFT.COM>
Subject:      Re: MGC-Initiated Control
X-To:         "brian.bidulock@inet.com" <brian.bidulock@inet.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> I have 1 MGC and 3000 MGs.  This is a real-world situation which we all
> face in implementing PSTN gateways.  It is not a speculative architecture,
> it is the predominate architecture: single MGC many MGs...

This is also exactly the scenario for which MGCP and Megaco were designed.
Nothing really new there. I fail to see why having the MGC initiate the
connections would scale any better than the other way around. For security
reasons, you have to parameterize the MG with some information about the
MGC, at least a  shared secret or a certificate. If you can do that, then
providing the domain name of the MGC does not add much constraint.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 13:23:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15128
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 13:23:02 -0400 (EDT)
Received: from standards (47.234.32.16:4473) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB738CA@standards.nortelnetworks.com>; Tue, 6 Jun 2000 13:12:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2069 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 13:12:44 -0400
Received: from bfgbhome.inetint.com (tnt-dal-42-241.dallas.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB738C9@standards.nortelnetworks.com>; Tue, 6 Jun 2000
          13:12:43 -0400
Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id
          MAA16033; Tue, 6 Jun 2000 12:21:00 -0500
Mail-Followup-To: Christian Huitema <huitema@microsoft.com>,
                  MEGACO@STANDARDS.NORTELNETWORKS.COM
References: <2E3FA0558747934A8F753CC533A3F6DF01FF56A8@red-msg-24.redmond.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Message-ID:  <20000606122100.C15241@inet.com>
Date:         Tue, 6 Jun 2000 12:21:00 -0500
Reply-To: brian.bidulock@inet.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Brian F. G. Bidulock" <brian.bidulock@inet.com>
Organization: Inet Technologies, Inc.
Subject:      Re: MGC-Initiated Control
X-To:         Christian Huitema <huitema@microsoft.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <2E3FA0558747934A8F753CC533A3F6DF01FF56A8@red-msg-24.redmond.corp.microsoft.com>; from
              huitema@microsoft.com on Tue, Jun 06, 2000 at 09:56:21AM -0700

Christian,

I understand that you have considerable experience in this area.  How did
you intend to handle the recovery situation where the network between MGC
and MG is interrupted and all MGs attempt to reconnect as soon as the
network is re-established?

On Tue, 06 Jun 2000, Christian Huitema wrote:

> > I have 1 MGC and 3000 MGs.  This is a real-world situation which we all
> > face in implementing PSTN gateways.  It is not a speculative architecture,
> > it is the predominate architecture: single MGC many MGs...
>
> This is also exactly the scenario for which MGCP and Megaco were designed.
> Nothing really new there. I fail to see why having the MGC initiate the
> connections would scale any better than the other way around. For security
> reasons, you have to parameterize the MG with some information about the
> MGC, at least a  shared secret or a certificate. If you can do that, then
> providing the domain name of the MGC does not add much constraint.

--
Brian F. G. Bidulock


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 14:01:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15806
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 14:01:13 -0400 (EDT)
Received: from standards (47.234.32.16:2635) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB738F9@standards.nortelnetworks.com>; Tue, 6 Jun 2000 13:52:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2128 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 13:52:20 -0400
Received: from mail4.microsoft.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB738F8@standards.nortelnetworks.com>; Tue, 6 Jun 2000 13:52:20
          -0400
Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall
          NT); Tue, 06 Jun 2000 11:00:08 -0700 (Pacific Daylight Time)
Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id
          <MKT86CY6>; Tue, 6 Jun 2000 11:00:07 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Message-ID:  <2E3FA0558747934A8F753CC533A3F6DF01FF56AB@red-msg-24.redmond.corp.microsoft.com>
Date:         Tue, 6 Jun 2000 11:00:10 -0700
Reply-To: Christian Huitema <huitema@MICROSOFT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Huitema <huitema@MICROSOFT.COM>
Subject:      Re: MGC-Initiated Control
X-To:         "brian.bidulock@inet.com" <brian.bidulock@inet.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> I understand that you have considerable experience in this
> area.  How did
> you intend to handle the recovery situation where the network
> between MGC
> and MG is interrupted and all MGs attempt to reconnect as soon as the
> network is re-established?

This is discussed at length in the MGCP documentation (ask the Cable Labs).
Basically, you use a random spreading of the [re]connection attempts over an
appropriate time interval, and you skew the spreading so that MG's that
actually need to speak, because they have some change of state to report,
become more impatient than those with nothing special to say. Note that this
second part, providing priority to the MG's that need it most, would be
impossible in an MGC-driven reconnection. Also, doing it "from the MG"
reduces the load at the MGC, which does not need to maintain timers, etc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 14:15:28 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16097
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 14:15:28 -0400 (EDT)
Received: from standards (47.234.32.16:3912) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73910@standards.nortelnetworks.com>; Tue, 6 Jun 2000 14:06:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2158 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 14:06:38 -0400
Received: from bfgbhome.inetint.com (tnt-dal-42-241.dallas.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7390F@standards.nortelnetworks.com>; Tue, 6 Jun 2000
          14:06:37 -0400
Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id
          NAA16665; Tue, 6 Jun 2000 13:14:55 -0500
Mail-Followup-To: Christian Huitema <huitema@microsoft.com>,
                  MEGACO@STANDARDS.NORTELNETWORKS.COM
References: <2E3FA0558747934A8F753CC533A3F6DF01FF56AB@red-msg-24.redmond.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Message-ID:  <20000606131455.F15241@inet.com>
Date:         Tue, 6 Jun 2000 13:14:55 -0500
Reply-To: brian.bidulock@inet.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Brian F. G. Bidulock" <brian.bidulock@inet.com>
Organization: Inet Technologies, Inc.
Subject:      Re: MGC-Initiated Control
X-To:         Christian Huitema <huitema@microsoft.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <2E3FA0558747934A8F753CC533A3F6DF01FF56AB@red-msg-24.redmond.corp.microsoft.com>; from
              huitema@microsoft.com on Tue, Jun 06, 2000 at 11:00:10AM -0700

Christian,

Thanks for the tips.  Are you referring to your v5 draft of MGCP?  Does it
include recommended time intervals and priorities?

Also, I am confused as to which timers do not need to be maintained doing
it "from the MG".

On Tue, 06 Jun 2000, Christian Huitema wrote:

>
> > I understand that you have considerable experience in this
> > area.  How did
> > you intend to handle the recovery situation where the network
> > between MGC
> > and MG is interrupted and all MGs attempt to reconnect as soon as the
> > network is re-established?
>
> This is discussed at length in the MGCP documentation (ask the Cable Labs).
> Basically, you use a random spreading of the [re]connection attempts over an
> appropriate time interval, and you skew the spreading so that MG's that
> actually need to speak, because they have some change of state to report,
> become more impatient than those with nothing special to say. Note that this
> second part, providing priority to the MG's that need it most, would be
> impossible in an MGC-driven reconnection. Also, doing it "from the MG"
> reduces the load at the MGC, which does not need to maintain timers, etc.

--
Brian F. G. Bidulock


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 16:06:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18410
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 16:06:21 -0400 (EDT)
Received: from standards (47.234.32.16:4498) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73992@standards.nortelnetworks.com>; Tue, 6 Jun 2000 15:57:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2333 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 15:57:21 -0400
Received: from bfgbhome.inetint.com (tnt-dal-42-208.dallas.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73991@standards.nortelnetworks.com>; Tue, 6 Jun 2000
          15:57:20 -0400
Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id
          PAA18166; Tue, 6 Jun 2000 15:05:37 -0500
Mail-Followup-To: Amy Pendleton <aspen@nortelnetworks.com>,
                  megaco@STANDARDS.NORTELNETWORKS.COM
References: <C7D2B856AD6BD311989B0000F80930C102369799@zrchb214.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Message-ID:  <20000606150537.I15241@inet.com>
Date:         Tue, 6 Jun 2000 15:05:37 -0500
Reply-To: brian.bidulock@inet.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Brian F. G. Bidulock" <brian.bidulock@inet.com>
Organization: Inet Technologies, Inc.
Subject:      Re: MGC-Initiated Control
X-To:         Amy Pendleton <aspen@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <C7D2B856AD6BD311989B0000F80930C102369799@zrchb214.us.nortel.com>; from aspen@nortelnetworks.com on Tue,
              Jun 06, 2000 at 02:15:37PM -0500

Amy (more eloquently) states a number of my concerns as well.  I am
interested as to how they might be addressed.  I am concerned about
fault-tolerant mated MGCs with separate transport addresses, and load
sharing between the mates.  I also agree that exposure of the MGC
redundancy architecture to the MG should not be necessary.

On Tue, 06 Jun 2000, Amy Pendleton wrote:

> Hi,
>
> I would like to present some more justification for the proposal of which
> Tom Taylor spoke.
>
> (1) The MGC is the central point of control within the network.  All call
> services run through the MGC and only it knows when it is ready to
> receive calls and to establish connections.
>
> (2) MGC failover strategy is exposed to MG's by allowing the MG to
> attempt to "rehouse" itself when it detects an MGC instance has failed.
> The MGC maintains a fault tolerance system between its instances and
> should remain in complete control of which instance is active at a given
> time.  It has always looked to me like by allowing the MG's to hunt for
> their serving MGC, the  specification is suggesting that the MG should
> have some part in the failover of an MGC. In the case where an MG is
> isolated from its serving MGC but the MGC is in fact working fine with
> the rest of the network, what is achieved by having the MG try the next
> MGC instance in its list.
>
> (3) MGC's ability to provide call services will be delayed by waiting for
> the gateways to establish communication with it both on initialization
> and failover.
>
> I recognize that the random spreading of (re)connection from the MG to
> the MGC may work but note that MGC-initiated control does not require
> this to scale -- the MGC will establish connectivity based on it own
> ability to handle call or network traffic.
>
> Thanks,
> Amy
>

--
Brian F. G. Bidulock


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 16:39:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18875
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 16:39:00 -0400 (EDT)
Received: from standards (47.234.32.16:1864) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB739E2@standards.nortelnetworks.com>; Tue, 6 Jun 2000 16:30:07 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2423 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 16:30:07 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB739E1@standards.nortelnetworks.com>; Tue, 6 Jun 2000 16:30:06
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id QAA00723; Tue, 6 Jun 2000 16:38:19 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id QAA14416; Tue, 6 Jun 2000 16:38:20 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <MND2HF4N>; Tue, 6 Jun 2000 16:38:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CFC992E0@whq-msgusr-02.fore.com>
Date:         Tue, 6 Jun 2000 16:38:18 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Gateways and call routing
X-To:         Dimitris Terzis <D.Terzis@CS.UCL.AC.UK>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> > We currently define the SG as a relatively dumb device, as we
> > define the MG as a relatively dumb device.  Your definition of
> > the SG as being a complete signalling interwork function overlaps
> > with our current definition of MGC.
> >
> > Note that your definition could be made to work with the
> latter example
> > of PSTN signalling interwork, but not the former example of ISDN
> > signalling interwork.
>
> I don't quite understand this... Why wouldn't it work for
> ISDN? Unless you
> are referring to the need for a SG-MGC protocol (Q.931 in
> your example),
> which is of course true but does not necessarily need to be
> (part of) the
> GSTN signalling protocol, everything else is just a
> point of view - i.e., where and how we define the network
> elements inside
> the gateway.
The physical SG has to be co-located with the physical MG because the D
channel of the ISDN is the same facility as the B channels.  To work
in your definition, you are moving a lot of intelligence into the MG,
which we both seem to want to get away from.

>
> If we don't insist that the SG be just a SCN termination
> point, I believe it
> should work (with perhaps different scaling, path optimisation and
> distributed processing needs/behaviour), as a matter of fact I 've
> implemented a simple testbed (a GSTN-IP gateway) for the
> needs of my PhD
> that does exactly that...
All kinds of systems are possible, and no one knows what the "right"
answer is -- it's going to be different for different networks.
What works for you may or may not work for small and large network
operators.

I do know that some MGC  vendors plan to co-locate an SG with the MGC.
Part of the reason why SGs are often thought of as simple low level
devices comes from a popular way of making SS7 systems, where local
intelligence on the interface card terminates MTP2, while code in
the host cpu terminates higher layers.  This architecture derives from
the real time nature of the signalling, although with overall faster
processors, this may be less of a driver than it was.  None the less,
many seem comfortable with the definitions.

>
> > At any rate, you are trying to redefine terms that we have
> > gradually come to consensus on, and, despite the fact that there
> > isn't a "right" or a "wrong" way to define anything, I believe that
> > you might be better off accepting the current definition.
>
> Not redefine, just wonder if this is really the best way.
> Even the current
> (H.323-biased) gateway model seems under alteration, as
> Jonathan Rosenberg
> pointed out in a relevant discussion we 've recently had in
> the IPTEL list.
> The idea is to extract the Application Server from the MGC
> and SoftSwitch,
> as he said, does exacltly that...
I think that there is a general agreement that Applications processors
need to be separate functional entities.  One good reference is the
MultiService Switching Forum's architecture (http://www.msforum.org).
When I describe how MGCs work, it is usually a signalling interworking
function - interwork between one subscriber and another, a subscriber
and another MGC, or MGC to external gateway signalling such as SS7.
In this way, your definition and mine tend to converge, but maybe
I think we are talking about the MGC, and you want to call it the SG!


Right at the moment, I think our definitions are well understood, and
generally agreed to, and we have a lot of work to actually build and
field these systems.  There will be better ways that emerge from our
experience.  I'm bent on producing interoperable components right now,
so my push-back on changing architectures may be more reaction to the
state of our efforts than anything else.

The wonderfull thing about protocols, and architectures, is there are
so many to choose from!

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun  6 19:50:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20768
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 6 Jun 2000 19:50:20 -0400 (EDT)
Received: from standards (47.234.32.16:2223) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73A28@standards.nortelnetworks.com>; Tue, 6 Jun 2000 19:41:36 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2516 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 19:41:35 -0400
Received: from redball.dynamicsoft.com (216.173.40.51:34774) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73A27@standards.nortelnetworks.com>; Tue, 6 Jun 2000
          19:31:35 -0400
Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com
          (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA07309; Tue, 6 Jun 2000
          19:41:06 -0400 (EDT)
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <393D8BD8.DDEC1A04@dynamicsoft.com>
Date:         Tue, 6 Jun 2000 19:40:08 -0400
Reply-To: Jonathan Rosenberg <jdrosen@DYNAMICSOFT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Jonathan Rosenberg <jdrosen@DYNAMICSOFT.COM>
Organization: dynamicsoft
Subject:      Availability of RTP library source code in C
X-To:         rem-conf@es.net, sip <sip@lists.bell-labs.com>,
              "iptel, list" <iptel@lists.research.bell-labs.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Folks,

I am pleased to finally announce the availability of source code for
RTPlib, and RTP library in C developed jointly by myself, Daniel
Rubenstein from U.Mass Amherst, and Henning Schulzrinne and Jonathan
Lennox from Columbia University. The library is fairly complete,
implementing some of the harder things, such as SSRC collision, mixers,
and RTCP timer reconsideration, in a transparent manner. It comes with
HTML documentation and example applications.

The library is free for non-commercial and research usage. It has been
run and tested primarily on Solaris, but has also been used on NT.

You can obtain the software at:
http://www.bell-labs.com/topic/swdist/

Thanks!

-Jonathan R.
--
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 04:55:56 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07971
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 04:55:56 -0400 (EDT)
Received: from standards (47.234.32.16:3156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73A99@standards.nortelnetworks.com>; Wed, 7 Jun 2000 4:46:39 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2667 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 04:46:39 -0400
Received: from bfgbhome.inetint.com (tnt-dal-42-221.dallas.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73A98@standards.nortelnetworks.com>; Wed, 7 Jun 2000 4:46:37
          -0400
Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id
          CAA28626; Wed, 7 Jun 2000 02:18:14 -0500
Mail-Followup-To: Matt Holdrege <matt@ipverse.com>,
                  MEGACO@STANDARDS.NORTELNETWORKS.COM
References: <4FBEA8857476D311A03300204840E1CF67842E@whq-msgusr-02.fore.com>
            <4FBEA8857476D311A03300204840E1CF67842E@whq-msgusr-02.fore.com>
            <20000606112922.A15241@inet.com>
            <4.3.1.2.20000606210818.00bf8810@pop3.ipverse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Message-ID:  <20000607021810.A28047@inet.com>
Date:         Wed, 7 Jun 2000 02:18:14 -0500
Reply-To: brian.bidulock@inet.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Brian F. G. Bidulock" <brian.bidulock@inet.com>
Organization: Inet Technologies, Inc.
Subject:      Re: MGC-Initiated Control
X-To:         Matt Holdrege <matt@ipverse.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4.3.1.2.20000606210818.00bf8810@pop3.ipverse.com>; from
              matt@ipverse.com on Tue, Jun 06, 2000 at 09:12:47PM -0700

Matt,

On Tue, 06 Jun 2000, Matt Holdrege wrote:

> At 11:29 AM 6/6/00 -0500, Brian F. G. Bidulock wrote:
> >Brian,
> >
> >I have 1 MGC and 3000 MGs.  This is a real-world situation which we all
> >face in implementing PSTN gateways.
>
> Yes I think we all understand that.

Excellent!  I'm glad I got that point across.

(I really have 2 mirrored SG/MGC combo's and 100,000 MGs on ATM,
but I won't tell anyone if you don't.)

> However you are moving into an area of
> implementations.

You are correct!  Implementation should never be considered in the
design of a protocol.  Protocols are pure and clean things, whereas
implementations are convoluted and dirty.  We should not speak of them.

> Creative designers can overcome this problem with the
> existing protocol.

Yes, I agree: it is important that many restrictions be made so that
only truly creative designers can even contemplate implementation.

> Yes we could be even more creative with allowing either
> side to initiate, but that really hurts interoperability and creates new
> holes in the protocol.

Your logic rings true to me: flexibility ruins interoperability.
TCP is less interoperable because hosts act as both clients and servers.
TCP hosts should be restricted to act solely as a client or solely as a
servers to better ensure interoperability.  All UNIX boxes should either
"listen" all the time or "connect" all the time but never both.  We should
cut the socket interface in half to further interoperability and reduce the
holes at the transport level.  Otherwise, how would the application ever
know when to "listen" and when to "connect"??  A provisioned value???
While were at it, lets completely secure that peer-to-peer IP protocol away
from applications altogether and make client-server the order of the day.

> We have consciously made several restrictive choices
> with MEGACO to get the protocol off the ground.

The more restrictions the better!  Too bad we couldn't have restricted
out those noxious packages and scripts and things.  Extensibility at the
cost of interoperability is what that is.  If it wasn't for that stodgy
ITU process, we could have come to a consensus on MGCP over a year ago.

Making the numerous connect to the few is so obvious a choice--such an
excellent simplifying assumption: we must show protocols like SNMP the
the error of their ways.  All managed devices should be made to connect
to their managers!  They should do this from a provisioned v.....NO, a
Discovery_Process, and search out the managers to connect to!

SNMP should be made to work like NIS: that's what I say.

> This new request to change
> the protocol only hurts the chances of MEGACO ever making it to the market.

I agree: let's cast it in concrete now!  Let's tell the ITU we don't
need no stinkin' annex or addendum or whatever they call it.  It's good
enough how it was.  Every vendor is eager to stuff this protocol in a
product and, well, if a few of them don't like it--tough!  As MEGACO
hits the streets it will knock all other protocols off of their spec
sheets!  Then, they will have no choice but to interoperate--MEGACO
users are waiting.


;) ;) ;)


Matt, (seriously), I don't mean to make light of the efforts of the
MEGACO working group and I understand your frustrations; however, issues
of binding outside the scope of MEGACO has slowed, rather than
facilitated, its rapid introduction.

Some restrictions in the specification impose undue hardships on
practical implementations which surface as "implementation issues."
A change to MEGACO's function is not required, just a removal of
implementation specific bindings in the specification within scopes that
the protocol should not attempt to fully specify.

Who connects to who is a transport `implementation' issue.  How they
connect when they do is a transport protocol issue.  Surely MEGACO can
hit the market without precluding connectionless or peer-to-peer
transports sporting the same or similar semantics at the transport
interface.  MEGACO should not care whether it is runs over an IPX
network, or a native ATM network for that matter, just as long as both
sides interoperate (communicate) when they do.

Surely MEGACO can hit the market without restricting the system
implementation to active/standby.  This is the realm of network and
nodal reliability vs. redundancy and is never a one-suits-all situation.
MEGACO cannot hope to provide all of the messages, syntax and protocol
necessary to coordinate creative designers of load-shared, fault-tolerant
applications, mirrored hosts and redundant networks.

Have faith that the industry can be creative and apply best common
practices in these areas (using the interoperable tools that the IETF
and others have placed at their disposal) without having to be
restricted in how they do it by MEGACO.

Don't change: chop those implementation issues from the spec!  ;)


--
Brian F. G. Bidulock


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 05:22:15 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08127
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 05:22:14 -0400 (EDT)
Received: from standards (47.234.32.16:1716) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73AD9@standards.nortelnetworks.com>; Wed, 7 Jun 2000 5:13:00 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2748 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 05:12:43 -0400
Received: from arianne.ishoni.com (164.164.83.132:1109) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73AD8@standards.nortelnetworks.com>; Wed, 7 Jun 2000 5:02:41
          -0400
Received: from sarunk (sarunk [192.168.1.96]) by arianne.ishoni.com
          (8.9.3/8.9.3) with SMTP id OAA08164 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 7 Jun 2000 14:10:29 +0530
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 CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Message-ID:  <C182A5918209D41190DE00C04F0CCD251083CC@LEONOID>
Date:         Wed, 7 Jun 2000 14:18:04 +0530
Reply-To: sarunk@ishoni.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Arun Kumar S <sarunk@ishoni.com>
Subject:      unsubscribe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

___________________________________________________
Arun Kumar S
ishoni Networks (India) Pvt Ltd (http://www.ishoni.com)
...Broadband for everyone
email: sarunk@ishoni.com
Phone: +91-80-2292125 (Work)
Fax: +91-80-2995545 (Work)


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 05:32:25 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08256
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 05:32:25 -0400 (EDT)
Received: from standards (47.234.32.16:1716) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73B06@standards.nortelnetworks.com>; Wed, 7 Jun 2000 5:20:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2804 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 05:20:15 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB73B05@standards.nortelnetworks.com>; Wed, 7 Jun 2000 5:20:11
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id NAA16715 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 7 Jun 2000 13:48:08 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652568F7.0028F9A9 ; Wed, 7 Jun 2000 12:52:48 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652568F7.002888BA.00@sandesh.hss.hns.com>
Date:         Wed, 7 Jun 2000 12:57:13 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Mode of Stream
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The mode parameter is appearing in Local control, local and remote descriptors.
Is it true that Mode parameter in local control descriptor defines the stream
mode
and  the mode specified in local and remote descriptors is redundant and not
used?


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 05:38:51 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08289
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 05:38:50 -0400 (EDT)
Received: from standards (47.234.32.16:1716) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73B2D@standards.nortelnetworks.com>; Wed, 7 Jun 2000 5:29:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2855 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 05:29:45 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB73B2C@standards.nortelnetworks.com>; Wed, 7 Jun 2000 5:29:33
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id MAA12962 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 7 Jun 2000 12:50:52 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652568F7.00234FA5 ; Wed, 7 Jun 2000 11:55:41 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652568F7.00234E92.00@sandesh.hss.hns.com>
Date:         Wed, 7 Jun 2000 12:00:09 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

What is the significance of adding the Jitter Buffer in Network package?
Network package is extended by both RTP package and TDM package,
which are supported by ephemeral and physical termination, respectively.
Does this mean that jitter buffer shall be implemented by both physical
termination and ephemeral termination ?
This property certainly seems redundant for one type of termination.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 05:59:02 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08337
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 05:59:01 -0400 (EDT)
Received: from standards (47.234.32.16:1716) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73B5B@standards.nortelnetworks.com>; Wed, 7 Jun 2000 5:49:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2895 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 05:49:48 -0400
Received: from sheffield.cnchost.com (sheffield.concentric.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73B4B@standards.nortelnetworks.com>; Wed, 7 Jun 2000 5:39:48
          -0400
Received: from MATT.ascend.com (ts022d46.atl-ga.concentric.net
          [209.220.251.106]) by sheffield.cnchost.com id AAA22924; Wed, 7 Jun
          2000 00:09:17 -0400 (EDT) [ConcentricHost SMTP Relay 1.8]
Errors-To: <matt@ipverse.com>
X-Sender: matt@ipverse.com@pop3.ipverse.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
References: <4FBEA8857476D311A03300204840E1CF67842E@whq-msgusr-02.fore.com>
            <4FBEA8857476D311A03300204840E1CF67842E@whq-msgusr-02.fore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.3.1.2.20000606210818.00bf8810@pop3.ipverse.com>
Date:         Tue, 6 Jun 2000 21:12:47 -0700
Reply-To: Matt Holdrege <matt@ipverse.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Matt Holdrege <matt@ipverse.com>
Subject:      Re: MGC-Initiated Control
X-To:         brian.bidulock@inet.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <20000606112922.A15241@inet.com>

At 11:29 AM 6/6/00 -0500, Brian F. G. Bidulock wrote:
>Brian,
>
>I have 1 MGC and 3000 MGs.  This is a real-world situation which we all
>face in implementing PSTN gateways.

Yes I think we all understand that. However you are moving into an area of
implementations. Creative designers can overcome this problem with the
existing protocol. Yes we could be even more creative with allowing either
side to initiate, but that really hurts interoperability and creates new
holes in the protocol. We have consciously made several restrictive choices
with MEGACO to get the protocol off the ground. This new request to change
the protocol only hurts the chances of MEGACO ever making it to the market.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 06:49:01 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08736
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 06:49:01 -0400 (EDT)
Received: from standards (47.234.32.16:4404) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73B7F@standards.nortelnetworks.com>; Wed, 7 Jun 2000 6:40:00 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2955 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 06:40:00 -0400
Received: from ctsincsisxia.DBSS.COM (202.54.64.137:4880) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73B7E@standards.nortelnetworks.com>; Wed, 7 Jun 2000 6:39:59
          -0400
Received: from 162.44.9.80 by ctsincsisxia.DBSS.COM (InterScan E-Mail VirusWall
          NT); Wed, 07 Jun 2000 09:13:25 +0530
Received: from rnd.cts-corp.com (206.136.109.204 [206.136.109.204]) by
          ctsincsisxic.cts-corp.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2448.0) id MKR1YHTD; Wed, 7 Jun 2000 09:21:46
          +0530
Received: from 9a4-gnd ([206.136.109.229]) by rnd.cts-corp.com (8.9.3/8.8.7)
          with SMTP id JAA24942; Wed, 7 Jun 2000 09:24:16 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Message-ID:  <002401bfd08b$aa01cee0$e56d88ce@9a4-gnd>
Date:         Wed, 7 Jun 2000 09:21:25 -0500
Reply-To: Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
Subject:      Re: Can we identify  calls from  messages ?
X-To:         jchristopher@163.NET
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

A MEGACO meassage may have commands for different calls. But  Commands in
the same action will be for the same call. Actions with the same Context Id
in two different messages will be for the same call.
There wiil be one context per call.

regards,
Sameer
-----Original Message-----
From: Jean Christopher <jchristopher@163.NET>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
<MEGACO@STANDARDS.NORTELNETWORKS.COM>
Date: Tuesday, June 06, 2000 9:32 AM
Subject: Can we identify calls from messages ?


>Hello, list
>
>Can we identify  calls from  messages?
>For example , just by 2 messages, can we judge if they are from
>the same call or not?
>
>Thanks
>
>
>
>---------------------------------------------------------------
>ÇëÖ§³ÖÖйú»¥ÁªÍø·¢Õ¹£¬²Î¼ÓÖйú»¥ÁªÍøÐÅÏ¢ÖÐÐÄ£¨CNNIC£©µ÷²é»î¶¯£¬
>²¢ÉêÇëÆÀÑ¡ÓÅÐãÍøվͶƱȨ£¬Í¶³öÄã×îÄÜÓ°ÏìÖйúÍøÕ¾ÅÅÃûµÄһƱ¡£
>ͶƱÍøÖ·£ºhttp://fsurvey.cnnic.net.cn/survey/index.html
>
>http://www.163.net ÿÌ춼ÔÚΪÄú·þÎñµÄµç×ÓÓʾÖ
>---------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 07:13:26 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08966
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 07:13:25 -0400 (EDT)
Received: from standards (47.234.32.16:1714) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73BA9@standards.nortelnetworks.com>; Wed, 7 Jun 2000 7:04:26 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3011 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 07:04:26 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB73BA8@standards.nortelnetworks.com>; Wed, 7 Jun 2000 7:04:12
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id OAA20636 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 7 Jun 2000 14:51:52 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652568F7.002E742D ; Wed, 7 Jun 2000 13:56:36 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652568F7.002E60CF.00@sandesh.hss.hns.com>
Date:         Wed, 7 Jun 2000 14:01:07 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Significance of Local and Remote descriptors for physical
              termination
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

"The MGC uses Local and remote descriptors to reserve and commit
MG resources for  media decoding and encoding for the given stream..."
 what is the significance of the encoding and decoding for physical termination,
 is it not pertained to ephemeral termination than for physical?
And if SDP is used, what significance does the IP address and
UDP fields for physical terminations? In the example
transaction 9999 specifies local descriptor for physical termination as

v=0
c=IN IP4 $
m=audio $ RTP/AVP 0
a=fmtp:PCMU VAD=X-NNVAD

with two $(CHOOSE) parameters. But the response sent from MG doesnt
specify these values, doesnt this contradict the statement (d) of page 25?


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 12:28:33 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15155
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 12:28:33 -0400 (EDT)
Received: from standards (47.234.32.16:4712) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73D87@standards.nortelnetworks.com>; Wed, 7 Jun 2000 12:19:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3621 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 12:19:35 -0400
Received: from dns2.spisystems.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB73D86@standards.nortelnetworks.com>; Wed, 7 Jun 2000 12:09:34
          -0400
Received: from david (unverified [63.66.182.159]) by spi16.spisystems.com
          (EMWAC SMTPRS 0.83) with SMTP id <B0001070848@spi16.spisystems.com>;
          Wed, 07 Jun 2000 15:13:11 +0000
X-Distribution: Bulk
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Priority: normal
Message-ID:  <393E1FA9.5862.2145DE@localhost>
Date:         Wed, 7 Jun 2000 10:10:49 -0700
Reply-To: Dialing Dave at SCI <sci@SERVICECONCEPTSINT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Dialing Dave at SCI <sci@SERVICECONCEPTSINT.COM>
Subject:      L5, 6/7 WTS AMD K6 2-500 Brand New, Loaded Systems 500@$489
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7BIT

Item #1123:  WTS:  System, Nexar (Mfgd in same factory as Compaq Presarios and IBM Aptivas), , AMD K6 2-500,
64/13.1/48X/Video/Snd/56K/1.44Floppy/Win 98 se/Productivety software, mfgs 1 year depot warranty-shipping for warranty pd
both ways,  500 @ $489







-----------------------------------------------------------------------------
          Service Concepts International
   Computer Software and Hardware Traders
  Home of "Dialing" Dave and "Honest" Jon

10 sq.foot office:               1219 Enclave Way #1211, Arlington,TX 76011
                                       Tel: 817-860-7483 Fax: 817-275-2737
28,000 sq. ft. warehouse: 4425 Simonton Road, Farmers Branch, TX 75244
                                         Tel: 817-860-7543 Fax: 240-524-8364

Email:                     sci@serviceconceptsint.com
URL:                       http://www.serviceconceptsint.com

Further transmissions to you by SCI may be stopped at no cost to
you by replying back with the word "REMOVE" in the subject line
of the E-mail which was sent.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 13:00:52 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16023
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 13:00:51 -0400 (EDT)
Received: from standards (47.234.32.16:2010) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73DC2@standards.nortelnetworks.com>; Wed, 7 Jun 2000 12:51:37 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3694 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 12:51:37 -0400
Received: from qhars002.nortel.com (47.101.112.102:49965) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73DBE@standards.nortelnetworks.com>; Wed, 7 Jun 2000
          12:51:37 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Tue, 6 Jun 2000 19:54:00 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Tue, 6 Jun 2000 13:52:29 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <LW2C11GF>; Tue, 6 Jun 2000 13:52:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCFE8.553D9608"
Message-ID:  <28560036253BD41191A10000F8BCBD11480A25@zcard00g.ca.nortel.com>
Date:         Tue, 6 Jun 2000 13:52:25 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Can we identify calls from messages ?
X-To:         "jchristopher@163.NET" <jchristopher@163.NET>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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_01BFCFE8.553D9608
Content-Type: text/plain;
        charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

There is no necessary connection between Megaco messages and calls.  =
One
Megaco message could contain multiple transactions.  The one thing you =
can
be fairly sure of is that actions related to the same context are =
related to
the same conference, but Megaco/H.248 has no call identifier as such.

> -----Original Message-----
> From: Jean Christopher [SMTP:jchristopher@163.NET]
> Sent: Tuesday, June 06, 2000 10:31 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Can we identify calls from messages ?
>=20
> Hello, list
>=20
> Can we identify  calls from  messages?
> For example , just by 2 messages, can we judge if they are from
> the same call or not?
>=20
> Thanks
>=20
>=20
>=20
> ---------------------------------------------------------------
> =
=C7=EB=D6=A7=B3=D6=D6=D0=B9=FA=BB=A5=C1=AA=CD=F8=B7=A2=D5=B9=A3=AC=B2=CE=
=BC=D3=D6=D0=B9=FA=BB=A5=C1=AA=CD=F8=D0=C5=CF=A2=D6=D0=D0=C4=A3=A8CNNIC=A3=
=A9=B5=F7=B2=E9=BB=EE=B6=AF=A3=AC
> =
=B2=A2=C9=EA=C7=EB=C6=C0=D1=A1=D3=C5=D0=E3=CD=F8=D5=BE=CD=B6=C6=B1=C8=A8=
=A3=AC=CD=B6=B3=F6=C4=E3=D7=EE=C4=DC=D3=B0=CF=EC=D6=D0=B9=FA=CD=F8=D5=BE=
=C5=C5=C3=FB=B5=C4=D2=BB=C6=B1=A1=A3
> =
=CD=B6=C6=B1=CD=F8=D6=B7=A3=BAhttp://fsurvey.cnnic.net.cn/survey/index.h=
tml
>=20
> http://www.163.net =
=C3=BF=CC=EC=B6=BC=D4=DA=CE=AA=C4=FA=B7=FE=CE=F1=B5=C4=B5=E7=D7=D3=D3=CA=
=BE=D6
> ---------------------------------------------------------------

------_=_NextPart_001_01BFCFE8.553D9608
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-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Can we identify calls from messages ?</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">There is no =
necessary connection between Megaco messages and calls.&nbsp; One =
Megaco message could contain multiple transactions.&nbsp; The one thing =
you can be fairly sure of is that actions related to the same context =
are related to the same conference, but Megaco/H.248 has no call =
identifier as such.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Jean Christopher =
[SMTP:jchristopher@163.NET]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, June 06, 2000 10:31 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Can we identify calls from messages =
?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello, list</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Can we identify&nbsp; calls from&nbsp; =
messages?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">For example , just by 2 messages, can =
we judge if they are from</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the same call or not?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
------</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">=C7=EB=D6=A7=B3=D6=D6=D0=B9=FA=BB=A5=C1=AA=CD=F8=B7=A2=D5=
=B9=A3=AC=B2=CE=BC=D3=D6=D0=B9=FA=BB=A5=C1=AA=CD=F8=D0=C5=CF=A2=D6=D0=D0=
=C4=A3=A8CNNIC=A3=A9=B5=F7=B2=E9=BB=EE=B6=AF=A3=AC</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">=B2=A2=C9=EA=C7=EB=C6=C0=D1=A1=D3=C5=D0=E3=CD=F8=D5=BE=CD=
=B6=C6=B1=C8=A8=A3=AC=CD=B6=B3=F6=C4=E3=D7=EE=C4=DC=D3=B0=CF=EC=D6=D0=B9=
=FA=CD=F8=D5=BE=C5=C5=C3=FB=B5=C4=D2=BB=C6=B1=A1=A3</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">=CD=B6=C6=B1=CD=F8=D6=B7=A3=BA<A =
HREF=3D"http://fsurvey.cnnic.net.cn/survey/index.html" =
TARGET=3D"_blank">http://fsurvey.cnnic.net.cn/survey/index.html</A></FON=
T>
</P>

<P><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.163.net" =
TARGET=3D"_blank">http://www.163.net</A></FONT></U><FONT SIZE=3D2 =
FACE=3D"Arial"> =
=C3=BF=CC=EC=B6=BC=D4=DA=CE=AA=C4=FA=B7=FE=CE=F1=B5=C4=B5=E7=D7=D3=D3=CA=
=BE=D6</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
------</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCFE8.553D9608--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 13:10:36 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16307
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 13:10:36 -0400 (EDT)
Received: from standards (47.234.32.16:2010) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73E21@standards.nortelnetworks.com>; Wed, 7 Jun 2000 13:01:39 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3703 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 13:01:38 -0400
Received: from qhars002.nortel.com (47.101.112.102:49968) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73DC3@standards.nortelnetworks.com>; Wed, 7 Jun 2000
          12:51:37 -0400
Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com;
          Wed, 7 Jun 2000 05:20:02 +0100
Received: from zrchb200.us.nortel.com (actually zrchb200) by
          smtprich.nortel.com; Tue, 6 Jun 2000 14:07:05 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <L3GPQ73B>; Tue, 6 Jun 2000 14:15:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCFEB.97E2CA70"
X-Orig: <aspen@americasm01.nt.com>
Message-ID:  <C7D2B856AD6BD311989B0000F80930C102369799@zrchb214.us.nortel.com>
Date:         Tue, 6 Jun 2000 14:15:37 -0500
Reply-To: Amy Pendleton <aspen@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Amy Pendleton <aspen@NORTELNETWORKS.COM>
Subject:      Re: MGC-Initiated Control
X-To:         brian.bidulock@inet.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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_01BFCFEB.97E2CA70
Content-Type: text/plain

Hi,

I would like to present some more justification for the proposal of which
Tom Taylor spoke.

(1) The MGC is the central point of control within the network.  All call
services run through the MGC and only it knows when it is ready to receive
calls and to establish connections.

(2) MGC failover strategy is exposed to MG's by allowing the MG to attempt
to "rehouse" itself when it detects an MGC instance has failed.  The MGC
maintains a fault tolerance system between its instances and should remain
in complete control of which instance is active at a given time.  It has
always looked to me like by allowing the MG's to hunt for their serving MGC,
the  specification is suggesting that the MG should have some part in the
failover of an MGC. In the case where an MG is isolated from its serving MGC
but the MGC is in fact working fine with the rest of the network, what is
achieved by having the MG try the next MGC instance in its list.

(3) MGC's ability to provide call services will be delayed by waiting for
the gateways to establish communication with it both on initialization and
failover.

I recognize that the random spreading of (re)connection from the MG to the
MGC may work but note that MGC-initiated control does not require this to
scale -- the MGC will establish connectivity based on it own ability to
handle call or network traffic.

Thanks,
Amy


> -----Original Message-----
> From: Brian F. G. Bidulock [SMTP:brian.bidulock@INET.COM]
> Sent: Tuesday, June 06, 2000 1:15 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: MGC-Initiated Control
>
> Christian,
>
> Thanks for the tips.  Are you referring to your v5 draft of MGCP?  Does it
> include recommended time intervals and priorities?
>
> Also, I am confused as to which timers do not need to be maintained doing
> it "from the MG".
>
> On Tue, 06 Jun 2000, Christian Huitema wrote:
>
> >
> > > I understand that you have considerable experience in this
> > > area.  How did
> > > you intend to handle the recovery situation where the network
> > > between MGC
> > > and MG is interrupted and all MGs attempt to reconnect as soon as the
> > > network is re-established?
> >
> > This is discussed at length in the MGCP documentation (ask the Cable
> Labs).
> > Basically, you use a random spreading of the [re]connection attempts
> over an
> > appropriate time interval, and you skew the spreading so that MG's that
> > actually need to speak, because they have some change of state to
> report,
> > become more impatient than those with nothing special to say. Note that
> this
> > second part, providing priority to the MG's that need it most, would be
> > impossible in an MGC-driven reconnection. Also, doing it "from the MG"
> > reduces the load at the MGC, which does not need to maintain timers,
> etc.
>
> --
> Brian F. G. Bidulock

------_=_NextPart_001_01BFCFEB.97E2CA70
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.2651.65">
<TITLE>RE: MGC-Initiated Control</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I would like to =
present some more justification for the proposal of which Tom Taylor =
spoke.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">(1) The MGC is the =
central point of control within the network.&nbsp; All call services =
run through the MGC and only it knows when it is ready to receive calls =
and to establish connections.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">(2) MGC failover =
strategy is exposed to MG's by allowing the MG to attempt to =
&quot;rehouse&quot; itself when it detects an MGC instance has =
failed.&nbsp; The MGC maintains a fault tolerance system between its =
instances and should remain in complete control of which instance is =
active at a given time.&nbsp; It has always looked to me like by =
allowing the MG's to hunt for their serving MGC, the&nbsp; =
specification is suggesting that the MG should have some part in the =
failover of an MGC. In the case where an MG is isolated from its =
serving MGC but the MGC is in fact working fine with the rest of the =
network, what is achieved by having the MG try the next MGC instance in =
its list.&nbsp; </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">(3) MGC's ability to =
provide call services will be delayed by waiting for the gateways to =
establish communication with it both on initialization and =
failover.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I recognize that the =
random spreading of (re)connection from the MG to the MGC may work but =
note that MGC-initiated control does not require this to scale -- the =
MGC will establish connectivity based on it own ability to handle call =
or network traffic.&nbsp; </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Amy </FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Brian F. G. Bidulock =
[SMTP:brian.bidulock@INET.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, June 06, 2000 1:15 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: MGC-Initiated Control</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Christian,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks for the tips.&nbsp; Are you =
referring to your v5 draft of MGCP?&nbsp; Does it</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">include recommended time intervals =
and priorities?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Also, I am confused as to which timers =
do not need to be maintained doing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it &quot;from the MG&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">On Tue, 06 Jun 2000, Christian Huitema =
wrote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; I understand that you have =
considerable experience in this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; area.&nbsp; How did</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; you intend to handle the =
recovery situation where the network</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; between MGC</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; and MG is interrupted and =
all MGs attempt to reconnect as soon as the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; network is =
re-established?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; This is discussed at length in =
the MGCP documentation (ask the Cable Labs).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Basically, you use a random =
spreading of the [re]connection attempts over an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; appropriate time interval, and =
you skew the spreading so that MG's that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; actually need to speak, because =
they have some change of state to report,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; become more impatient than those =
with nothing special to say. Note that this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; second part, providing priority =
to the MG's that need it most, would be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; impossible in an MGC-driven =
reconnection. Also, doing it &quot;from the MG&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; reduces the load at the MGC, =
which does not need to maintain timers, etc.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">--</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Brian F. G. Bidulock</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCFEB.97E2CA70--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 13:35:50 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16803
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 13:35:50 -0400 (EDT)
Received: from standards (47.234.32.16:2010) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73E42@standards.nortelnetworks.com>; Wed, 7 Jun 2000 13:26:52 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3851 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 13:26:52 -0400
Received: from dns2.spisystems.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB73E3F@standards.nortelnetworks.com>; Wed, 7 Jun 2000 13:16:52
          -0400
Received: from david (unverified [63.66.182.9]) by spi16.spisystems.com (EMWAC
          SMTPRS 0.83) with SMTP id <B0001072293@spi16.spisystems.com>; Wed, 07
          Jun 2000 17:18:55 +0000
X-Distribution: Bulk
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Priority: normal
Message-ID:  <393E0193.27771.A46EAB@localhost>
Date:         Wed, 7 Jun 2000 08:02:27 -0700
Reply-To: Dialing Dave at SCI <sci@SERVICECONCEPTSINT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Dialing Dave at SCI <sci@SERVICECONCEPTSINT.COM>
Subject:      L5, 6/7 Assorted Memory Requirements and Offers
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7BIT

WE WISH TO PURCHASE:
#1085 Memory Compaq, 241771-B21,   100 @ $140
#1086 Memory Compaq, 241774-B21,   100 @ $2100
#1084 Memory Compaq, 32583-B21, Assembly No: 228471-001 , If retail
          boxed add $100 for the cardboard  100 @ $2600


WE WISH TO OFFER:
#1108 Memory IBM, 8 Meg, 72 pin, gold, Working Pulls, lifetime warantee,
          70 ns, parity, 8 chips per side  5000 @ $3.5
#1083 Memory NEC, 16 Meg, 72 pin, gold, Working Pulls, lifetime warantee,
          70 ns, non-parity, Fast Page, 8 chips per side, 4 k refresh  750 @ $18
#1109 Memory NEC, 32 M, 72 Pin, Gold, Working Pulls, lifetime warantee,
          70 ns, non-parity, Fast Page, 16X 4  500 @ $35
#1122 Memory NEC, 64 Meg, 72 pin, gold, Working Pulls, lifetime warantee,
          70 ns, non-parity, Fast Page, 8 chips per side,  100 @ $68





-----------------------------------------------------------------------------
          Service Concepts International
   Computer Software and Hardware Traders
  Home of "Dialing" Dave and "Honest" Jon

10 sq.foot office:               1219 Enclave Way #1211, Arlington,TX 76011
                                       Tel: 817-860-7483 Fax: 817-275-2737
28,000 sq. ft. warehouse: 4425 Simonton Road, Farmers Branch, TX 75244
                                         Tel: 817-860-7543 Fax: 240-524-8364

Email:                     sci@serviceconceptsint.com
URL:                       http://www.serviceconceptsint.com

Further transmissions to you by SCI may be stopped at no cost to
you by replying back with the word "REMOVE" in the subject line
of the E-mail which was sent.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 13:46:39 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17027
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 13:46:38 -0400 (EDT)
Received: from standards (47.234.32.16:2010) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73E60@standards.nortelnetworks.com>; Wed, 7 Jun 2000 13:37:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3872 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 13:37:45 -0400
Received: from dns2.spisystems.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB73E4F@standards.nortelnetworks.com>; Wed, 7 Jun 2000 13:27:45
          -0400
Received: from david (unverified [63.66.182.9]) by spi16.spisystems.com (EMWAC
          SMTPRS 0.83) with SMTP id <B0001072749@spi16.spisystems.com>; Wed, 07
          Jun 2000 17:26:08 +0000
X-Distribution: Bulk
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Priority: normal
Message-ID:  <393E00F4.7276.A20268@localhost>
Date:         Wed, 7 Jun 2000 07:59:48 -0700
Reply-To: Dialing Dave at SCI <sci@SERVICECONCEPTSINT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Dialing Dave at SCI <sci@SERVICECONCEPTSINT.COM>
Subject:      L5, 6/7 Assorted Printer Requirements and Offers
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7BIT

WE WISH TO PURCHASE:
#1079 Printer Assorted Brands, Assorted Models, Ink Jets, refurbished,
          color and b/w, retail package  200 @ Best Offer


WE WISH TO OFFER:
#1118 Printer Canon, BJC 5000, Refurbed and Boxed, FOB Ilinois, 30
          day warranty  50 @ Best Offer
#1119 Printer Compaq, IJ750's, AS IS, Palletized, deinstalled from
          an office environment, FOB Ilinois  200 @ Best Offer
#1120 Printer Compaq, IJ900, AS IS, Palletized, deinstalled from an
          office environment, FOB Ilinois  90 @ Best Offer
#1107 Printer HP, , 340) HP 500C, 146) HP 500, 346) 540C, 86) Combo
          520C,550C, 560C, 378) 600C. Sold AS IS but guaranteed to come directly
          off desks on a de-install.  May be inspected ! Perfect for a refurb
          house!  1296 @ $13
#1121 Printer HP, 712C, AS IS, Palletized, deinstalled from an office
          environment, FOB Ilinois  75 @ Best Offer
#1117 Printer HP, 712C's, Refurbed and Boxed, FOB Ilinois, 30 Day
          Warranty  70 @ Best Offer
#1091 Printer Xerox, Docuprint C8, PRICE REDUCED (AND I FINALLY SPELLED
          XEROX CORRECTLY) Color, Ink Jet, Brand New, Full mfg warranty, LANDED
          PRICE !!, 1000 lot Minimum  2600 @ $55





-----------------------------------------------------------------------------
          Service Concepts International
   Computer Software and Hardware Traders
  Home of "Dialing" Dave and "Honest" Jon

10 sq.foot office:               1219 Enclave Way #1211, Arlington,TX 76011
                                       Tel: 817-860-7483 Fax: 817-275-2737
28,000 sq. ft. warehouse: 4425 Simonton Road, Farmers Branch, TX 75244
                                         Tel: 817-860-7543 Fax: 240-524-8364

Email:                     sci@serviceconceptsint.com
URL:                       http://www.serviceconceptsint.com

Further transmissions to you by SCI may be stopped at no cost to
you by replying back with the word "REMOVE" in the subject line
of the E-mail which was sent.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 15:02:44 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18417
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 15:02:42 -0400 (EDT)
Received: from standards (47.234.32.16:2010) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73EF0@standards.nortelnetworks.com>; Wed, 7 Jun 2000 14:53:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4094 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 14:53:45 -0400
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73EEF@standards.nortelnetworks.com>; Wed, 7 Jun 2000
          14:53:45 -0400
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA14305
          for <MEGACO@standards.nortelnetworks.com>; Wed, 7 Jun 2000 15:02:11
          -0400 (EDT)
Received: from ihgp2.ih.lucent.com (h135-1-53-26.lucent.com [135.1.53.26]) by
          hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA14289
          for <MEGACO@standards.nortelnetworks.com>; Wed, 7 Jun 2000 15:02:10
          -0400 (EDT)
Received: by ihgp2.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA22653; Wed, 7
          Jun 2000 14:02:09 -0500 (CDT)
Received: from il0015varney2.lucent.com by ihgp2.ih.lucent.com
          (8.8.8+Sun/EMS-1.5 sol2) id OAA22615; Wed, 7 Jun 2000 14:02:07 -0500
          (CDT)
X-Sender: varney@ihgp2.ih.lucent.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Message-ID:  <4.3.1.2.20000607133442.00b22c10@ihgp2.ih.lucent.com>
Date:         Wed, 7 Jun 2000 14:01:48 -0500
Reply-To: Al Varney <varney@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Al Varney <varney@LUCENT.COM>
Subject:      Re: Can we identify calls from messages ?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <28560036253BD41191A10000F8BCBD11480A25@zcard00g.ca.nortel. com>

<html>
At 13:52 06/06/2000 -0500, Tom-PT Taylor wrote:<br>
<br>
<blockquote type=cite cite><font face="Arial, Helvetica" size=2 color="#0000FF">There
is no necessary connection between Megaco messages and calls.&nbsp; One
Megaco message could contain multiple transactions.&nbsp; The one thing
you can be fairly sure of is that actions related to the same context are
related to the same conference, but Megaco/H.248 has no call identifier
as such.</font></blockquote><br>
&nbsp;&nbsp; In the spirit of keeping protocols &quot;open&quot; (to new
applications), I think is useful to decouple the concept of &quot;a
call&quot; (something only an MGC can determine/distinguish) and
connections (something H.248 MGs do).&nbsp; If I use Megaco messages to
intermix music, barge-in requests and announcements of blue-light
specials over an H.248-based public address system at K-Mart, where are
the &quot;calls&quot;?<br>
<br>
&nbsp;&nbsp; More seriously, many actions requested of an MG could be
done outside the bounds of any &quot;call&quot;.&nbsp; Maintenance
requests, loop-back, connections for testing, release of resources due to
audit, etc. might not involve a &quot;call&quot;.&nbsp; Even where calls
exist, I could easily find examples (in today's network) where a single
Context serves several calls, and a single call involves multiple
Contexts (to permit the needed control of who hears what and when).<br>
<br>
&nbsp;&nbsp; On the other hand, it might be useful for MGCs to hand MGs a
&quot;reference value&quot; to be associated with a termination.&nbsp;
This would allow an MGC to request removal of all terminations associated
with a particular &quot;reference value&quot;.&nbsp; If the reference
value happened to be a call-identifier, then some &quot;call
association&quot; would result.&nbsp; Worth doing -- probably not.<br>
<br>
&nbsp;&nbsp; If, on the other hand, you want to monitor an H.248
interface and collect messages associated with a particular TDM interface
or a particular call, that's going to be tough.<br>
<br>
Al Varney - Lucent Technologies&nbsp; +1 630 224-7493&nbsp;&nbsp;&nbsp;
varney@lucent.com
</html>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 20:37:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23221
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 20:37:01 -0400 (EDT)
Received: from standards (47.234.32.16:4586) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73FE9@standards.nortelnetworks.com>; Wed, 7 Jun 2000 20:27:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4442 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 20:27:44 -0400
Received: from qhars002.nortel.com (47.101.112.102:33351) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73FE2@standards.nortelnetworks.com>; Wed, 7 Jun 2000
          20:27:44 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Wed, 7 Jun 2000 18:59:41 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Wed, 7 Jun 2000 12:58:33 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPD1RT4K>; Wed, 7 Jun 2000 12:58:37 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480A30@zcard00g.ca.nortel.com>
Date:         Wed, 7 Jun 2000 12:58:26 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      spam
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Apologies for the spate of unwanted messages.  I have asked our
administrator to add Dialing Dave to our spam list.

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 20:37:24 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23224
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 20:37:01 -0400 (EDT)
Received: from standards (47.234.32.16:4586) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73FED@standards.nortelnetworks.com>; Wed, 7 Jun 2000 20:27:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4447 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 20:27:45 -0400
Received: from qhars002.nortel.com (47.101.112.102:33353) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB73FE3@standards.nortelnetworks.com>; Wed, 7 Jun 2000
          20:27:44 -0400
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          qhars002.nortel.com; Wed, 7 Jun 2000 18:20:39 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Wed, 7 Jun 2000 13:16:30 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <L3HQ13FK>; Wed, 7 Jun 2000 13:06:31 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480A29@zcard00g.ca.nortel.com>
Date:         Wed, 7 Jun 2000 13:06:18 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Mode of Stream
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The mode parameter in LocalControl determines what media flows actually
occurr at a given moment within the MG.  The direction attribute in SDP is
used to coordinate with the far end.  I think I would agree with you that
the SDP attribute is redundant between the MG and MGC, since directionality
is clear as a result of the separation into Local and Remote.  Outward from
the MGC, however, the session description(s) derived from Local has to be
tagged with a=recvOnly, and similarly session descriptions derived from
Remote have to be tagged with a=sendOnly.  The only question is whether the
MG or MGC is responsible for adding these tags.  Since we haven't specified
that in Megaco/H.248 and the attribute is not required by RFC 2327, it is
the MGC's responsibility to make sure it is there.

> -----Original Message-----
> From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> Sent: Wednesday, June 07, 2000 3:27 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Mode of Stream
>
> The mode parameter is appearing in Local control, local and remote
> descriptors.
> Is it true that Mode parameter in local control descriptor defines the
> stream
> mode
> and  the mode specified in local and remote descriptors is redundant and
> not
> used?


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun  7 22:05:08 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24693
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 7 Jun 2000 22:05:07 -0400 (EDT)
Received: from standards (47.234.32.16:2390) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74068@standards.nortelnetworks.com>; Wed, 7 Jun 2000 21:56:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4616 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 21:56:10 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB74067@standards.nortelnetworks.com>; Wed, 7 Jun 2000 21:56:09
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id WAA27846; Wed, 7 Jun 2000 22:04:29 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id WAA26180; Wed, 7 Jun 2000 22:04:30 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <MND22P2A>; Wed, 7 Jun 2000 22:04:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CFC9937B@whq-msgusr-02.fore.com>
Date:         Wed, 7 Jun 2000 22:04:29 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: About Packages..
X-To:         arayhan@nortelnetworks.com
X-cc:         SSMudholkar <ssm@CHIPLOGIC.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

At the MSF, we are working on a set of profiles, which we plan
to make public pretty soon.  You can see the basic outline in
my test profile on the megaco-interop list.  I think that they
will be very good examples of what a profile would look like.
At some point, we should document this in the IETF, I agree.

Brian

> -----Original Message-----
> From: arayhan@nortelnetworks.com [mailto:arayhan@nortelnetworks.com]
> Sent: Tuesday, June 06, 2000 5:21 PM
> To: Rosen, Brian
> Cc: SSMudholkar
> Subject: Re: About Packages..
>
>
> Brian,
>
> I agree with Brian, also the profile would define the
> terminations the MG implements in addition to the packages.
>
> While we have profile as part of the grammar, I can not
> find a profile definition and profile requirements statements
> in the megaco draft. Dont we need to come up with
> profile requirements draft? which defines how to define
> profiles and the requirements that a profile must meet
> for megaco!
>
> Abdallah
>
> "Rosen, Brian" wrote:
>
> > No one else seems to have replied to this one.
> >
> > Packages have to be implemented on the MG.  It's not something the
> > MGC decides.  The designer of the MG decides what kind of
> terminations
> > the MG will support, and implements the appropriate packages needed
> > to control that kind of termination.
> >
> > The MGC finds out what packages are implemented via the
> audit command.
> > The MGC has to be built to understand what capabilities a package
> > may have.  That is one reason for the profile mechanism - the MGC
> > can discover the profile before it accepts the MG for service.
> > The profile includes a set of packages that must be implemented.  If
> > the MGC knows how to support a device with a specific profile, by
> > implication it knows how to support terminations with the packages
> > listed in the profile.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: SSMudholkar [mailto:ssm@CHIPLOGIC.COM]
> > > Sent: Monday, June 05, 2000 6:37 AM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: About Packages..
> > >
> > >
> > > Hi ,
> > >     A newbee question.
> > >  When an MG comes up is it required that all it's
> > > physical terminations (which will be in null context )
> have to support
> > > some
> > > packages by default or all the packages it has to support will be
> > > specified
> > > by the MGC when a termination is created through ADD command.
> > >
> > > Thanks in advance
> > > -sanjeev
> > >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 07:17:51 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11118
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 07:17:51 -0400 (EDT)
Received: from standards (47.234.32.16:4249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74168@standards.nortelnetworks.com>; Thu, 8 Jun 2000 7:08:18 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4947 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 07:08:18 -0400
Received: from mailcity.com (209.1.236.7:56772) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB74165@standards.nortelnetworks.com>; Thu, 8 Jun 2000 6:58:17
          -0400
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Thu Jun  8 04:06:09
          2000
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
X-Sender-Ip: 216.6.88.34
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Message-ID:  <LJAKLPHFEEPAAAAA@mailcity.com>
Date:         Thu, 8 Jun 2000 04:06:09 -0700
Reply-To: hussainmf@mailcity.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hussain F Mohammad <hussainmf@mailcity.com>
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Subject:      Re: Errors and Error Codes
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I was going through the archives and found that these error codes and the reasons of their generation are supposed to be released as a seperate draft. If its released  where to get the draft. As there should be a common understanding  between MG and MGC, in what situation they can generated, these need to be documented somewhere.

Hussain,
Chief scientist,
Advanced IP networks.


Tom-PT Taylor <taylor@NORTELNETWORKS.COM> on 02/11/2000 06:11:14 PM

Please respond to Tom-PT Taylor <taylor@NORTELNETWORKS.COM>

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Hussain F Mohammad)

Subject:  Errors and Error Codes




This E-mail covers several topics dealing with error reporting.

A. Asynchronous Error Reporting
========================

We have discussed, here in Geneva, a mechanism for generating spontaneous
notifications of error conditions (i.e. use of the "cause" event in the
generic package).  The suggested mechanism is this:

  -- we reserve a block of event request-IDs (e.g. 0-15) for assignment to
classes of event the MGC will always want enabled (or alternatively can
enable or disable using a Root property).  As an example of use, we assign
requestID 0 to spontaneous error reports.  This way it won't be necessary to
include the cause event in every Event Descriptor

  -- rather than making errorDescriptor an optional component of the Notify
command (as our ABNF now states), we make it a parameter of the cause event.

  -- this mechanism allows the inclusion of some error codes in our list in
section 7.3 which otherwise shouldn't be there because they would not result
from transaction processing.  One example is 518 "event buffer full".

B. Errors In Transaction Reply

I'm not sure we have a procedure for handling errors in Transaction Reply.
Unless someone can point me to the existing text, we should add something to
cover the situation.

C. Errors Defined In Packages

We agreed with the Cisco proposal that it be possible to define error codes
in packages.  This would just be a matter of documentation convenience --
the codes would NOT be qualified by package name, and the package
documentation would serve double duty as far as IANA registration is
concerned.  IMHO this means no change to our existing section 12 except
perhaps to mention this possibility in the packages section.  Assignment of
codes would follow the usual rules: 000-999 range for ITU/IETF codes, 1000
-9999 for private packages.

D. Review Of Error Codes

I have reviewed the error codes in the current document, and have compiled
explanations for a number of them.  Others I can't explain, and suspect they
shouldn't be there.  I would like other people to review my findings so we
can get this straightened out.  In what follows, errors marked with an
asterisk could be returned against transaction replies as well as
transaction requests.  My comments are enclosed in square brackets.  I
present no explanations for error codes which seem to be adequately
described by the text shown against them in 7.3.

Could someone explain the logic behind the assignment of these codes?  Why
start at 400? -- our numbering space is only 000 to 999 and it doesn't seem
right to waste half of it.

*400 - Bad Request
        A syntax error has been detected at the message level.  The message
does not conform to the productions MegacoMessage or Message in Annex A or
Annex B as applicable.

*401 - Protocol Error
        A violation of Megaco protocol procedures has been detected.  Use
error codes corresponding to more specific conditions if they apply.  [e.g.
465, 466, 467 if they turn out to be justified; 505, 521.]

402 - Unauthorized
        The originator of a command is not authorized to execute that
command for the termination(s) affected by it.  [For messages failing
authentication, what is our procedure? ]

403 - Syntax Error in Transaction
        The form of a transaction request failed to match production
transactionRequest in Annex A, Annex B, or section D.1.2 of Annex D as
applicable.  [Note: review codes proposed in sec. 8.2.2.]

*404 - Syntax Error in TransactionReply
        The form of a transaction reply failed to match production
transactionReply in Annex A, Annex B, or section D.1.2 of Annex D as
applicable.

*405 - Syntax Error in TransactionPending
        The form of a transaction pending failed to match production
transactionPending in Annex A, Annex B, or section D.1.2 of Annex D as
applicable.

*406 - Version Not Supported
        Used by the receiver of a transaction request to indicate lack of
support for the protocol version indicated in the message header.  [Note
usage in sec. 11.3 -- I think there is an error in the second para last
sentence (should be MG, not MGC)]

*410 - Incorrect identifier
        A syntax error has been found in an mId, transactionId, contextId,
terminationId, PropertyId, EventId, SignalId, StatisticsId or ParameterId.

411 - The transaction refers to an unknown ContextId
        A specific contextID provided in a Transaction Request is unknown to
the respondent.  For unknown contextID in Transaction Reply use error code
46x "ContextIDs in Reply do not match Request" [which isn't currently
defined -- could change 461].

412 - No ContextIDs available
        The MG is unable to create a new context in response to an Add or
Move command with CHOOSE given as the contextId, because of a shortage of
software or hardware resources within the MG.

421 - Unknown action or illegal combination of actions
        [Can't happen -- actions don't have tags or semantics in
themselves.]

*422 - Syntax Error in Action
        The syntax of an Action did not conform to production actionRequest
or actionReply as applicable.  Use error code 405 or 406 as applicable if
parsing failed to delineate the end of the Action.
        [Check usage in 8.2.2]

430 - Unknown TerminationID
        A specific terminationID provided in a Transaction Request is
unknown to the responder.  For unknow terminationIDs in Transaction Replies
use error code 463.

431 - No TerminationID matched a wildcard
         The Transaction Request specified a TerminationID including both
specific content and one or more wildcards (ALL or CHOOSE), but the
responder could not find an existing termination or, because of internal
naming constraints, create a new termination matching the specified pattern.

432 - Out of TerminationIDs or No TerminationID available
        The MG was unable to allocate a new terminationID in response to an
Add command specifying a CHOOSE termination identifier, because it has
exhausted the applicable local name space or some other per-termination
resource.

433 - TerminationID is already in a Context
        A TerminationID specified in an Add command already exists within an
active context.

440 - Unsupported or unknown Package
        The package named in a Property, Event, Signal, or Statistic
identifier is not supported by the respondent.

441 - Missing RemoteDescriptor
        The MGC has attempted to set the Mode of a stream on a termination
to SendOnly or SendReceive but an inadeqate or no outgoing media
specification has been provided in a Remote Descriptor for that stream.
[Note: same thing can apply to Local/incoming flows.  Generalize this error
to "Attempt to activate underspecified flow"?]

*442 - Syntax Error in Command
        A command request has failed to match the syntax of the
commandRequest production, or a command reply in a transaction response has
failed to match the syntax of the CommandReply (Annex A) or commandReplys
(Annex B) production, as applicable. Use the 422 error code if parsing
failed to delineate the end of the command request or command reply.  [Check
use in sec. 8.2.2.]

443 - Unsupported or Unknown Command
        The respondent to a Transaction Request successfully parsed a
command to the point of delineating the command type, but does not recognize
or support the command type.  Use the 442 error code if the respondent
failed to delineate the command type.

*444 - Unsupported or Unknown Descriptor
        A  command request or command reply was successfully parsed to the
point of delineating the type of a descriptor, but the descriptor type is
not recognized or supported.  The 442 error code should be used if parsing
failed to delineate the end of the descriptor, the descriptor type, or
individual properties, parameters, or values within the descriptor.

*445 - Unsupported or Unknown Property
        [Redundant -- use 450]

*446 - Unsupported or Unknown Parameter

*447 - Descriptor not legal in this command

*448 - Descriptor appears twice in a command

*450 - No such property in this package
        The Property Name (Annex A) or ItemID (Annex B) of a property within
a descriptor is either unsupported or unrecognized.  Use error code 440 if
the Package Name associated with the property is unrecognized.

*451 - No such event in this package
        This could apply to a reply for the AuditValue command as well as
the more common case of faulty EventDescriptors in other commands.  Use
error code 440 if the Package Name associated with the event is
unrecognized.

*452 - No such signal in this package
        This could apply to a reply for the AuditValue command as well as
the more common case of faulty SignalsDescriptors in other commands.  Use
error code 440 if the Package Name associated with the signal is
unrecognized.

*453 - No such statistic in this package
        Use error code 440 if the Package Name associated with the statistic
is unrecognized.

*454 - No such parameter value in this package
        The value given for a parameter is not legal for the package to
which the parameter belongs.  Use error code 450 if the type as opposed to
the value of the parameter is illegal.

*455 - Parameter illegal in this Descriptor

*456 - Parameter or Property appears twice in this Descriptor

*461 - TransactionIDs in Reply do not match Request
[Can't be detected.  Should be ContextIDs rather than TransactionIDs.  See
comment on 411]

*462 - Commands in Transaction Reply do not match commands in request

*463 - TerminationID of Transaction Reply does not match  request
[Should be phrased similarly to 462]

*464 - Missing reply in Transaction Reply
        [Assuming 461 is changed to ContextIDs and given 462, this one is
redundant]

*465 - TransactionID in Transaction Pending does not match any open request
[Unusable -- contrary to procedures in D.1.4]

466 - Illegal Duplicate Transaction Request
[Unusable -- contrary to procedures in 8.2.3]

*467 - Illegal Duplicate Transaction Reply
[Unusable -- contrary to Annex D procedures?]

471 - Implied Add for Multiplex failure
        A termination listed within a multiplex descriptor could not be
added to the current context.  If the reason is because the termination is
already in a different active context, use error code 433.

500 - Internal Gateway Error
        A command could not be executed properly due to a software failure
within the MG.  For hardware failures, see error code 529.

501 - Not Implemented
        [Redundant??? (Codes 443-446)]

502 - Not ready
        The respondent is temporarily unable to process requests because of
its own internal state.

503 - Service Unavailable
        [What service???  Likely conditions are covered by other error
codes]

504 - Command Received from unauthorized entity
        [Redundant -- covered by 402?]

505 - Command Received before Restart Response
        Issued by the MG which has issued a ServiceChange request to an MGC
if it receives a transaction request from that MGC before it has processed
the response to the ServiceChange request.  See procedural notes in section
11.2.

510 - Insufficient resources
        The MG is unable to execute a command because of a lack of resources
within the MG.

512 - Media Gateway unequipped to detect requested Event
        Self-descriptive.  If the MG does not support the package in which
the event is specified, use code 440.

513 - Media Gateway unequipped to generate requested Signals
        Self-descriptive.  If the MG does not support the package in which
the signal is specified, use code 440.

514 - Media Gateway cannot send the specified announcement
        [Package specific -- should be documented in the announcement
package]

515 - Unsupported Media Type
        [Might want to make it "Unsupported media type or media conversion"
]

517 - Unsupported or invalid mode
        [Too detailed.  Need a general "Unsupported or invalid value" }

518 - Event buffer full
        Reported via the Notify command using the Cause event in the Generic
package.  See procedures in section 7.2.7 [to be added as noted at the start
of this E-mail]

519 - Out of space to store digit map

520 - Media Gateway does not have a digit map
        The digit map named in a command is not specified.  [Probably want
to change to "Digit Map undefined"]

521 - Termination is "ServiceChangeing"
        [Inapplicable if we get rid of Graceful ServiceChange for
terminations.]

526 - Insufficient bandwidth
        The MG was unable to execute a command because of insufficient
resources at the network interface or externally to the MG.

529 - Internal hardware failure
        A command could not be executed properly due to a hardware failure
within the MG.

530 - Temporary Network failure
        The MG was unable to execute a command because of a network failure
of unspecified but temporary nature affecting the termination concerned.  If
the failure renders an existing termination unavailable for service, the MG
should follow up by issuing a ServiceChange on the termination to indicate
its unavailability.

531 - Permanent Network failure
        The MG was unable to execute a command because of a network failure
of unspecified and persistent nature affecting the termination concerned.
If the failure renders an existing termination unavailable for service, the
MG should follow up by issuing a ServiceChange on the termination to
indicate its unavailability.

581 - Does Not Exist
        [Covered by more specific errors (e.g. 411, 430)]


Tom Taylor
Advisor -- Emerging Carrier IP Standards
E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961







Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 07:22:29 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11219
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 07:22:28 -0400 (EDT)
Received: from standards (47.234.32.16:4249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74186@standards.nortelnetworks.com>; Thu, 8 Jun 2000 7:13:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4948 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 07:13:29 -0400
Received: from mailcity.com (209.1.236.7:57919) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB74166@standards.nortelnetworks.com>; Thu, 8 Jun 2000 7:03:28
          -0400
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Thu Jun  8 04:10:20
          2000
Mime-Version: 1.0
X-Sent-Mail: off
X-Expiredinmiddle: true
X-Mailer: MailCity Service
X-Sender-Ip: 216.6.88.34
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Message-ID:  <NAKNBJELOHPAAAAA@mailcity.com>
Date:         Thu, 8 Jun 2000 04:10:20 -0700
Reply-To: hussainmf@mailcity.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hussain F Mohammad <hussainmf@mailcity.com>
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Subject:      Re: Choosing of ephemeral / physical Termination.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Is this issue closed??


> -----Original Message-----
> From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Thursday, April 06, 2000 10:17 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Choosing of ephemeral / physical Termination.
>
>
> Tom,
>
> I was searching through the archives but I am not sure this issue was
> settled.
> Have you make a final decision on this issue yet?
> Is it reflected somewhere in the latest version of the Standard?
>
>
> Thanks
> Chuong
>
>
> On Thu, 27 Jan 2000 15:09:24 -0600, Tom-PT Taylor
> <taylor@NORTELNETWORKS.COM> wrote:
>
> >I think one could interpret Context=${Add=${}} as follows:
> >
> >"Create a new context.  Allocate a terminationID and any
> software resources
> >required to hold more information about that termination when that
> >information is provided.  Return an error if there is any attempt to
> >activate a media flow before there is enough information to
> do so."  Not
> >sure why you'd do this really -- it means extra messaging to
> follow up.
> >
> >
> >> -----Original Message-----
> >> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> >> Sent: Wednesday, January 26, 2000 4:07 PM
> >> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> >> Subject:      Re: Choosing of ephemeral / physical Termination.
> >>
> >> Generally determined by the "kind" of termination requested.
> >> Which is in turn, easily discernable from the Media command.
> >>
> >> However, upon reflection, I think it's not a good answer.
> >> I'd propose that we not allow selection of a physical termination,
> >> in which case choose is always create an ephemeral.  In particular,
> >> the following is perfectly legal:
> >> Context=${Add=${}}
> >> What do you get?
> >>
> >> Brian
> >>
> >> > -----Original Message-----
> >> > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> >> > Sent: Tuesday, January 25, 2000 9:01 AM
> >> > To: MEGACO@standards.nortelnetworks.com
> >> > Subject: Choosing of ephemeral / physical Termination.
> >> >
> >> >
> >> > Annex B.1 says that "The CHOOSE TerminationID $ may be used
> >> > to signal to the MG
> >> > that it has to create an
> >> > ephemeral Termination or select an idle physical Termination".
> >> > How can MG determine when to create an ephemeral termination
> >> > and when to choose
> >> > idle physical termination.??
> >> > What is the logic behind this decision making?
> >> >
> >> > regards
> >> > -Sachin Mittal
> >> >
> >
>


Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 07:25:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11251
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 07:25:03 -0400 (EDT)
Received: from standards (47.234.32.16:4249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7419B@standards.nortelnetworks.com>; Thu, 8 Jun 2000 7:14:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5014 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 07:14:50 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB74185@standards.nortelnetworks.com>; Thu, 8 Jun 2000 7:13:31
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id RAA27894 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 8 Jun 2000 17:39:04 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652568F8.003DAAC7 ; Thu, 8 Jun 2000 16:43:34 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652568F8.003DA9EB.00@sandesh.hss.hns.com>
Date:         Thu, 8 Jun 2000 16:48:02 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Reserve Property.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In section 7.1.7, third para, boolean-value reserve properties, ReserveValue and
ReserveGroup are said to decide the processing at MG when local and/or remote
descriptor are received, but in the ASN syntax of local control descriptor have
only the reserveValue and reserveGroup fields. As the following paragraphs
dictate the processing at MG using this Reserve Property, this field need to be
added.

-Madhu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 09:25:43 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05868
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 09:25:43 -0400 (EDT)
Received: from standards (47.234.32.16:3966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB741D8@standards.nortelnetworks.com>; Thu, 8 Jun 2000 9:16:24 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5091 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 09:16:23 -0400
Received: from tama5.ecl.ntt.co.jp by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB741D7@standards.nortelnetworks.com>; Thu, 8 Jun 2000 9:06:23
          -0400
Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100])
          by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id
          WAA00352 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 8 Jun 2000
          22:14:43 +0900 (JST) (envelope-from takaya.naoki@lab.ntt.co.jp)
Received: from imh.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp
          (8.9.3+3.2W/3.7W/06/05/00) with ESMTP id WAA10162 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 8 Jun 2000 22:14:42 +0900
          (JST) (envelope-from takaya.naoki@lab.ntt.co.jp)
Received: from lab.ntt.co.jp ([129.60.11.88]) by imh.m.ecl.ntt.co.jp
          (8.9.3/3.7W) with ESMTP id WAA17447; Thu, 8 Jun 2000 22:14:42 +0900
          (JST)
X-Mailer: Mozilla 4.7 [ja] (Win98; I)
X-Accept-Language: ja
MIME-Version: 1.0
References: <4.3.1.2.20000606102949.00b44a40@dogwood.cisco.com>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Message-ID:  <393F9CBA.5EBE1D7B@lab.ntt.co.jp>
Date:         Thu, 8 Jun 2000 22:16:42 +0900
Reply-To: Naoki Takaya <takaya.naoki@LAB.NTT.CO.JP>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Naoki Takaya <takaya.naoki@LAB.NTT.CO.JP>
Organization: NTT Network Service System Labs.
Subject:      Re: How many TCP and UDP connections can be established?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,

Which is better to use TCP or UDP between MGC and MG
for transporting messages?


Chip Sharp wrote:

> At 10:15 PM 6/6/00 +0800, Jean Christopher wrote:
> >Hello , the list.
> >
> >  Can we establish more than one TCP connection between
> >    MGC and MG for  transporting messages?
> >    (maybe one connection is not enough)
> >    and the same question for UDP connection.
>
> I don't know of anything in the spec that forbids the use of multiple TCP
> connections between MGC and MG.  However, I'm not an expert on the startup
> procedures and there may be a tie-in in there somewhere.
>
> There is no connection in UDP, so there is no inherent limit. :-)
> If what you mean is you want to run H.248/megaco over multiple port
> numbers, then I have the same answer as for TCP (above).  I don't see any
> advantages of running megaco over multiple UDP ports.
>
> >  If we can , is there is max limit of connections?
>
> I assume it would be the number of connections supported by your
> implementation.  That would be implementation-specific.  Note that if you
> use TCP, the MGC will have to support as many TCP connections as there are
> MGs (potentially).  If you have N TCP connections per MG, then you will
> have to find a MGC that supports N times the number of MGs TCP connections.
>
> Chip

--
Naoki TAKAYA


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 09:35:31 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07312
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 09:35:31 -0400 (EDT)
Received: from standards (47.234.32.16:3966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB741FA@standards.nortelnetworks.com>; Thu, 8 Jun 2000 9:26:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5134 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 09:26:27 -0400
Received: from qhars002.nortel.com (47.101.112.102:63341) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB741F9@standards.nortelnetworks.com>; Thu, 8 Jun 2000 9:26:27
          -0400
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          qhars002.nortel.com; Thu, 8 Jun 2000 14:29:25 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Thu, 8 Jun 2000 09:29:09 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPQCVCBJ>; Thu, 8 Jun 2000 09:29:09 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480A36@zcard00g.ca.nortel.com>
Date:         Thu, 8 Jun 2000 09:29:07 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Errors and Error Codes
X-To:         "hussainmf@mailcity.com" <hussainmf@mailcity.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This leads very nicely into some news I failed to publish regarding results
of the Osaka meeting.  The ITU-T accepted two additional work items:

Annex L to H.248 would document error codes.
Annex M to H.248 describes packages for the Advanced Audio Server function.

I would say Annex L is probably something we want to develop jointly with SG
16, while Annex M is something we might be prepared to comment on only after
it had been determined.  If people feel otherwise, please say so.

Current drafts for these documents may be found in documents APC-1868 and
APC-1855 respectively at
ftp://standard.pictel.com/avc-site/0005_Osa/
The complete Question 14 meeting report from Osaka is to be found in
TD-21b.zip at the same site.

I intend to post Annexes F through K as I-Ds as soon as clean copies are
available and take them through Last Call in the spirit of the Formal
Comment process I proposed earlier.  These Annexes have all been determined,
but there were some changes to F and G coming out of Osaka which have to be
folded in.


> -----Original Message-----
> From: Hussain F Mohammad [SMTP:hussainmf@MAILCITY.COM]
> Sent: Thursday, June 08, 2000 7:06 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Errors and Error Codes
>
> I was going through the archives and found that these error codes and the
> reasons of their generation are supposed to be released as a seperate
> draft. If its released  where to get the draft. As there should be a
> common understanding  between MG and MGC, in what situation they can
> generated, these need to be documented somewhere.
>
> Hussain,
> Chief scientist,
> Advanced IP networks.
>
>
> Tom-PT Taylor <taylor@NORTELNETWORKS.COM> on 02/11/2000 06:11:14 PM
>
        [PTT]  snip


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 09:43:53 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07606
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 09:43:52 -0400 (EDT)
Received: from standards (47.234.32.16:3966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74232@standards.nortelnetworks.com>; Thu, 8 Jun 2000 9:34:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5212 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 09:34:47 -0400
Received: from qhars002.nortel.com (47.101.112.102:64908) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB74231@standards.nortelnetworks.com>; Thu, 8 Jun 2000 9:34:47
          -0400
Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com;
          Thu, 8 Jun 2000 14:43:04 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Thu, 8 Jun 2000 08:26:25 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPD1SFTK>; Thu, 8 Jun 2000 08:34:53 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480A38@zcard00g.ca.nortel.com>
Date:         Thu, 8 Jun 2000 08:34:44 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Reserve Property.
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The phrase "Reserve property" is a verbal shortcut.  The intention is that
this be read as "Reserve Value and ReserveGroup properties".

> -----Original Message-----
> From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> Sent: Thursday, June 08, 2000 7:18 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Reserve Property.
>
> In section 7.1.7, third para, boolean-value reserve properties,
> ReserveValue and
> ReserveGroup are said to decide the processing at MG when local and/or
> remote
> descriptor are received, but in the ASN syntax of local control descriptor
> have
> only the reserveValue and reserveGroup fields. As the following paragraphs
> dictate the processing at MG using this Reserve Property, this field need
> to be
> added.
>
> -Madhu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 10:02:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07981
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 10:02:32 -0400 (EDT)
Received: from standards (47.234.32.16:3966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74258@standards.nortelnetworks.com>; Thu, 8 Jun 2000 9:53:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5260 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 09:53:28 -0400
Received: from qhars002.nortel.com (47.101.112.102:34745) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB74256@standards.nortelnetworks.com>; Thu, 8 Jun 2000 9:53:27
          -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Thu, 8 Jun 2000 14:59:09 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Thu, 8 Jun 2000 09:39:45 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPQCVCP5>; Thu, 8 Jun 2000 09:39:44 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480A39@zcard00g.ca.nortel.com>
Date:         Thu, 8 Jun 2000 09:39:31 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Significance of Local and Remote descriptors for physical ter
              mination
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

You make some good points.  We have to straighten out our SDP usage for TDM
terminations, just as we are working on it for ATM.  The first thing we have
to do is define TDM nettype and addrtype extensions to the SDP -- as you so
rightly point out, the addressing is done incorrectly in the example.  I see
this been done through a revision to the existing TDMC package in Annex E --
others may have a different suggestion.

> -----Original Message-----
> From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> Sent: Wednesday, June 07, 2000 4:31 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Significance of Local and Remote descriptors for physical
> termination
>
> "The MGC uses Local and remote descriptors to reserve and commit
> MG resources for  media decoding and encoding for the given stream..."
>  what is the significance of the encoding and decoding for physical
> termination,
>  is it not pertained to ephemeral termination than for physical?
> And if SDP is used, what significance does the IP address and
> UDP fields for physical terminations? In the example
> transaction 9999 specifies local descriptor for physical termination as
>
> v=0
> c=IN IP4 $
> m=audio $ RTP/AVP 0
> a=fmtp:PCMU VAD=X-NNVAD
>
> with two $(CHOOSE) parameters. But the response sent from MG doesnt
> specify these values, doesnt this contradict the statement (d) of page 25?


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 10:09:46 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08086
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 10:09:46 -0400 (EDT)
Received: from standards (47.234.32.16:3966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74279@standards.nortelnetworks.com>; Thu, 8 Jun 2000 10:00:41 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5259 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 10:00:41 -0400
Received: from tnint06.telogy.com (mail.telogy.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB74255@standards.nortelnetworks.com>; Thu, 8 Jun 2000 9:50:41
          -0400
Received: by argentina.telogy.com with Internet Mail Service (5.5.2448.0) id
          <MQM07W90>; Thu, 8 Jun 2000 09:59:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <61891BA043DED21180920090273F173801164B56@argentina.telogy.com>
Date:         Thu, 8 Jun 2000 09:59:01 -0400
Reply-To: Shankara Ramamurthy <sramamurthy@TELOGY.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shankara Ramamurthy <sramamurthy@TELOGY.COM>
Subject:      Context Audit Properties
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,
Annex B says that ContextAuditProperties can take the value
(topologytoken/Emergencytoken/Prioritytoken). So if an MG gets a
ContextAudit command for the NULL context, with ContextAudit properties set
to the Emergency token or the priority token, what should it respond with?

Thanks

-Shankara


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 10:28:28 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08389
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 10:28:28 -0400 (EDT)
Received: from standards (47.234.32.16:2353) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74299@standards.nortelnetworks.com>; Thu, 8 Jun 2000 10:19:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5344 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 10:19:15 -0400
Received: from qhars002.nortel.com (47.101.112.102:38634) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB74297@standards.nortelnetworks.com>; Thu, 8 Jun 2000
          10:19:14 -0400
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          qhars002.nortel.com; Thu, 8 Jun 2000 15:26:02 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Thu, 8 Jun 2000 10:25:06 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPQCV1VN>; Thu, 8 Jun 2000 10:24:59 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480A3C@zcard00g.ca.nortel.com>
Date:         Thu, 8 Jun 2000 10:24:54 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Context Audit Properties
X-To:         Shankara Ramamurthy <sramamurthy@TELOGY.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Good point.  The null context is a conceptual convenience, but its only
function is to hold provisioned terminations when they are not otherwise
engaged.  We inserted sentences to enforce that with respect to wildcarding,
but we missed this particular point.  I'd say the only valid audit return
for the null context is the list of terminationIds in it.  If other stuff is
asked for, I suppose the 400 Bad Request error might be returned.

> -----Original Message-----
> From: Shankara Ramamurthy [SMTP:sramamurthy@TELOGY.COM]
> Sent: Thursday, June 08, 2000 9:59 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Context Audit Properties
>
> Hi,
> Annex B says that ContextAuditProperties can take the value
> (topologytoken/Emergencytoken/Prioritytoken). So if an MG gets a
> ContextAudit command for the NULL context, with ContextAudit properties
> set
> to the Emergency token or the priority token, what should it respond with?
>
> Thanks
>
> -Shankara


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 11:04:48 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09218
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 11:04:48 -0400 (EDT)
Received: from standards (47.234.32.16:3808) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB742CB@standards.nortelnetworks.com>; Thu, 8 Jun 2000 10:55:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5407 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 10:55:22 -0400
Received: from MYPC (208.238.46.160:2555) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB742C7@standards.nortelnetworks.com>; Thu, 8 Jun 2000 10:45:16
          -0400
X-Sender: griffin@exotic.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3
X-MSMail-Priority: Normal
Message-ID:  <MEGACO%2000060810552240@STANDARDS.NORTELNETWORKS.COM>
Date:         Thu, 8 Jun 2000 09:55:48 -0400
Reply-To: griffin@EXOTIC.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: griffin@EXOTIC.COM
Subject:      GET $3MIL VALUE FROM $25
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Few people get chances they take... Rockefella'

US$25.00 FOR US$3MIL VALUE RESERVED   ... SEND US$25
YOU CAN OWN (in beautiful Jamaica)
7 Acre COFFEE FARM (BLUE MOUNTAIN COFFEE)
   * your own coffee to grind
   * coffee price is going up - you can operate at the retail end
   * export to Japan, etc
   *you can setup local management and watch the $$ come as more people start to drink 5 or more cups per day as a
     cure or preventative to ALZImers

ALSO in the chance is

50 Acres BEACH FRONT PROPERTY (North Coast)
     * ready for RESORT development
     * international GOLF course operation
     * establish a NUDITY beach colony on the white sands
      * watch the income flow

SEND US$25. IN AN EVELOPE WITH YOUR NAME AND ADDRESS WRITTEN ON
  & put this smaller envelop into a larger envelop ( we will return info to you here)
  & write a note saying: please enter me in this DRAW
  & put this note into the larger envelop
THAT'S SIMPLY IT BUT YOUR CHANCE GOES UP : FOR EACH NAME YOU WRITE ONTO THE NOTE GIVES YOU
ONE MORE ENTRY TO THE DRAW if we find the referred person applied for the same DRAW you are in.
IF you write peter smith and a peter smith send in $25. you get one more entry.

1. draw date is that date the applicants fee reach the reserve value indicated

2. you will be sent your title of ownership (and conditions) or the information of who got it.

3. you will be automatically re-entered into the next DRAW if you had referred over ten applicants
SEND YOUR ENVELOPE TO
                                                     EXOCTIC INVESTMENTS
                                                      P.O. BOX 8776
                                                      KINGSTON CSO
                                                      JAMAICA W.I


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 12:44:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11616
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 12:44:58 -0400 (EDT)
Received: from standards (47.234.32.16:3443) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB743A7@standards.nortelnetworks.com>; Thu, 8 Jun 2000 12:35:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5650 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 12:35:30 -0400
Received: from mta5.rcsntx.swbell.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB7438B@standards.nortelnetworks.com>; Thu, 8 Jun 2000 12:25:30
          -0400
Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun
          Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id
          <0FVU00D3GFA52U@mta5.rcsntx.swbell.net> for
          megaco@standards.nortelnetworks.com; Thu,  8 Jun 2000 11:06:05 -0500
          (CDT)
Date-warning: Date header was inserted by mta5.rcsntx.swbell.net
MIME-version: 1.0
Content-type: text/plain; charset=unknown-8bit
Message-ID:  <0FVU00DMFFE32U@mta5.rcsntx.swbell.net>
Date:         Thu, 8 Jun 2000 11:06:05 -0500
Reply-To: zainprov@SWBELL.NET
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: zainprov@SWBELL.NET
Subject:      Shocking LOSE 10-100lbs. DESTINY
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello From Destiny,

You will LOOSE 20-100 pounds easy!
Do to Such a high demand for Destiny, we are able
To Dramatically reduce our price for the entire System!
You will LOVE our incredible offer on this
Scientific Breakthrough in Weight Loss.
Now with a 105% Money Back Guarantee!
LOOK! http://home.swbell.net/zainprov/destiny.htm



We hope things are going well for you.  Good luck, God Bless, and
HAVE A GREAT DAY!



Either you are someone else subscribed to our list.  To be removed
Simply reply with a blank email.

Thank you,

Sherry Wilson


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 17:55:15 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17653
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 17:55:15 -0400 (EDT)
Received: from standards (47.234.32.16:1983) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7447E@standards.nortelnetworks.com>; Thu, 8 Jun 2000 17:46:18 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0218 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 17:46:18 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB7447D@standards.nortelnetworks.com>; Thu, 8 Jun 2000 17:46:17
          -0400
Received: from aiglos.trillium.com (unverified) by turin.trillium.com (Content
          Technologies SMTPRS 4.1.5) with ESMTP id
          <Tced86cda674cad4a1e29@turin.trillium.com> for
          <megaco@standards.nortelnetworks.com>; Thu, 8 Jun 2000 15:07:10 -0700
Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by
          aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id OAA00409 for
          <megaco@standards.nortelnetworks.com>; Thu, 8 Jun 2000 14:54:40 -0700
          (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <MPXWWMTD>; Thu, 8 Jun 2000 14:53:01 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5D9FB23B@aega.trillium.com>
Date:         Thu, 8 Jun 2000 14:52:59 -0700
Reply-To: Bharat Kaul <bharat@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Bharat Kaul <bharat@TRILLIUM.COM>
Subject:      MID Clarification
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi ,

I have a doubt concerning the usage of "MID" in the protocol.  In a IP V4
network, Mid has been is (IP address/domain name) and an optional port
number.

My doubt is that since the port number is specified as optional, is an
entity originating a message "ALLOWED" to specify port in MID in some
messages and skip in some by the protocol ?

Or does protocol require the originating entity to maintain a consistent MID
in all messages i.e. always use same MID across all messages (even in cases
where multiple connections/sockets are being used) ?

On a similar note,  does the port number in MID indicate the source port
from which message was transmitted or does it have any other significance ?

- thanks
  Bharat



----------------------------------------------------------------------------
-----------
Bharat Kaul;                                      Trillium Digital Systems
Inc.
mailto:bharat@trillium.com          12100 Wilshire Blvd,
Phone: +1-310-442-9222                Los Angeles, CA - 90025.
Fax:     +1-310-442-1162                  http://www.trillium.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 19:17:34 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18945
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 19:17:34 -0400 (EDT)
Received: from standards (47.234.32.16:3921) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB744AF@standards.nortelnetworks.com>; Thu, 8 Jun 2000 19:08:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0283 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 19:08:32 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB744AE@standards.nortelnetworks.com>; Thu, 8 Jun 2000 19:08:31
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id TAA20945; Thu, 8 Jun 2000 19:16:57 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id TAA27922; Thu, 8 Jun 2000 19:16:59 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <MR1Y347R>; Thu, 8 Jun 2000 19:16:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFD19F.A554DA30"
Message-ID:  <4FBEA8857476D311A03300204840E1CFC9940A@whq-msgusr-02.fore.com>
Date:         Thu, 8 Jun 2000 19:16:57 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Can we identify calls from messages ?
X-To:         Al Varney <varney@LUCENT.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

The idea of having a value kept by the MG on behalf of the MGC on a per
context (or even per-termination)
is a worthy thought, and my own development people are asking me to promote
that idea for another
reason - recovery from failure.  Creating a package that allows the MGC to
specify that a termination hold
an opaque data object, which the MGC can set and get is straightforward.

We have a draft, which we could publish.

Trying to get the MG to do something with this object (like delete all
contexts with this value) is a
behavior change that would need a protocol extension.

Brian

-----Original Message-----
From: Al Varney [mailto:varney@LUCENT.COM]
Sent: Wednesday, June 07, 2000 3:02 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Can we identify calls from messages ?


At 13:52 06/06/2000 -0500, Tom-PT Taylor wrote:



There is no necessary connection between Megaco messages and calls.  One
Megaco message could contain multiple transactions.  The one thing you can
be fairly sure of is that actions related to the same context are related to
the same conference, but Megaco/H.248 has no call identifier as such.


   In the spirit of keeping protocols "open" (to new applications), I think
is useful to decouple the concept of "a call" (something only an MGC can
determine/distinguish) and connections (something H.248 MGs do).  If I use
Megaco messages to intermix music, barge-in requests and announcements of
blue-light specials over an H.248-based public address system at K-Mart,
where are the "calls"?

   More seriously, many actions requested of an MG could be done outside the
bounds of any "call".  Maintenance requests, loop-back, connections for
testing, release of resources due to audit, etc. might not involve a "call".
Even where calls exist, I could easily find examples (in today's network)
where a single Context serves several calls, and a single call involves
multiple Contexts (to permit the needed control of who hears what and when).

   On the other hand, it might be useful for MGCs to hand MGs a "reference
value" to be associated with a termination.  This would allow an MGC to
request removal of all terminations associated with a particular "reference
value".  If the reference value happened to be a call-identifier, then some
"call association" would result.  Worth doing -- probably not.

   If, on the other hand, you want to monitor an H.248 interface and collect
messages associated with a particular TDM interface or a particular call,
that's going to be tough.

Al Varney - Lucent Technologies  +1 630 224-7493    varney@lucent.com


------_=_NextPart_001_01BFD19F.A554DA30
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 5.00.3017.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=900214515-08062000>The
idea of having a value kept by the MG on behalf of the MGC on a per context (or
even per-termination)</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=900214515-08062000>is a
worthy thought, and my own development people are asking me to promote that idea
for another</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=900214515-08062000>reason
- recovery from failure.&nbsp; Creating a package that allows the MGC to specify
that a termination hold</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=900214515-08062000>an
opaque data object, which the MGC can set and get is
straightforward.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=900214515-08062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=900214515-08062000>We
have a draft, which we could publish.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=900214515-08062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=900214515-08062000>Trying
to get the MG to do something with this object (like delete all contexts with
this value) is a</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=900214515-08062000>behavior change that would need a protocol
extension.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=900214515-08062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=900214515-08062000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Al Varney
  [mailto:varney@LUCENT.COM]<BR><B>Sent:</B> Wednesday, June 07, 2000 3:02
  PM<BR><B>To:</B> MEGACO@STANDARDS.NORTELNETWORKS.COM<BR><B>Subject:</B> Re:
  Can we identify calls from messages ?<BR><BR></DIV></FONT>At 13:52 06/06/2000
  -0500, Tom-PT Taylor wrote:<BR><BR>
  <BLOCKQUOTE cite type="cite"><FONT color=#0000ff face="Arial, Helvetica"
    size=2>There is no necessary connection between Megaco messages and
    calls.&nbsp; One Megaco message could contain multiple transactions.&nbsp;
    The one thing you can be fairly sure of is that actions related to the same
    context are related to the same conference, but Megaco/H.248 has no call
    identifier as such.</FONT></BLOCKQUOTE><BR>&nbsp;&nbsp; In the spirit of
  keeping protocols "open" (to new applications), I think is useful to decouple
  the concept of "a call" (something only an MGC can determine/distinguish) and
  connections (something H.248 MGs do).&nbsp; If I use Megaco messages to
  intermix music, barge-in requests and announcements of blue-light specials
  over an H.248-based public address system at K-Mart, where are the
  "calls"?<BR><BR>&nbsp;&nbsp; More seriously, many actions requested of an MG
  could be done outside the bounds of any "call".&nbsp; Maintenance requests,
  loop-back, connections for testing, release of resources due to audit, etc.
  might not involve a "call".&nbsp; Even where calls exist, I could easily find
  examples (in today's network) where a single Context serves several calls, and
  a single call involves multiple Contexts (to permit the needed control of who
  hears what and when).<BR><BR>&nbsp;&nbsp; On the other hand, it might be
  useful for MGCs to hand MGs a "reference value" to be associated with a
  termination.&nbsp; This would allow an MGC to request removal of all
  terminations associated with a particular "reference value".&nbsp; If the
  reference value happened to be a call-identifier, then some "call association"
  would result.&nbsp; Worth doing -- probably not.<BR><BR>&nbsp;&nbsp; If, on
  the other hand, you want to monitor an H.248 interface and collect messages
  associated with a particular TDM interface or a particular call, that's going
  to be tough.<BR><BR>Al Varney - Lucent Technologies&nbsp; +1 630
  224-7493&nbsp;&nbsp;&nbsp; varney@lucent.com </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFD19F.A554DA30--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun  8 19:45:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19203
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 8 Jun 2000 19:45:10 -0400 (EDT)
Received: from standards (47.234.32.16:1329) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB744D2@standards.nortelnetworks.com>; Thu, 8 Jun 2000 19:36:18 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0327 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 19:36:18 -0400
Received: from bfgbhome.inetint.com (tnt-dal-113.dallas.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB744D1@standards.nortelnetworks.com>; Thu, 8 Jun 2000
          19:36:17 -0400
Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id
          SAA25765; Thu, 8 Jun 2000 18:44:28 -0500
Mail-Followup-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>,
                  MEGACO@STANDARDS.NORTELNETWORKS.COM
References: <4FBEA8857476D311A03300204840E1CFC9940A@whq-msgusr-02.fore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Message-ID:  <20000608184428.P22077@inet.com>
Date:         Thu, 8 Jun 2000 18:44:28 -0500
Reply-To: brian.bidulock@inet.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Brian F. G. Bidulock" <brian.bidulock@inet.com>
Organization: Inet Technologies, Inc.
Subject:      Re: Can we identify calls from messages ?
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CFC9940A@whq-msgusr-02.fore.com>;
              from Brian.Rosen@MARCONI.COM on Thu, Jun 08,
              2000 at 07:16:57PM -0400

Brian,

On Thu, 08 Jun 2000, Rosen, Brian wrote:
>
>    We have a draft, which we could publish.

I would be quite interested in seeing your draft.

>      At 13:52 06/06/2000 -0500, Tom-PT Taylor wrote:
> >
> >       If, on the other hand, you want to monitor an H.248 interface
> >    and collect messages associated with a particular TDM interface or
> >    a particular call, that's going to be tough.
> >
Monitoring an H.248 interface and correlating messages is exactly what
I would like to do (and make possible).  It increases the ability to
perform remote monitoring and diagnostics of systems communicating
with the protocol using external protocol diagnostic equipment.
It also permits network management systems to monitor the network
and collect useful usage and performance information.

And then there's those CALEA requirements...

--
Brian F. G. Bidulock
Director GeoGate SW Development
Network Products, Inet Technologies Inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  9 00:55:17 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23890
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 9 Jun 2000 00:55:17 -0400 (EDT)
Received: from standards (47.234.32.16:4660) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7453D@standards.nortelnetworks.com>; Fri, 9 Jun 2000 0:46:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0465 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 00:46:11 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB7453C@standards.nortelnetworks.com>; Fri, 9 Jun 2000 0:45:34
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id LAA28835 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 9 Jun 2000 11:11:23 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652568F9.001A262C ; Fri, 9 Jun 2000 10:15:37 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652568F9.001A2558.00@sandesh.hss.hns.com>
Date:         Fri, 9 Jun 2000 10:20:05 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Jitter Buffer
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Resending, as the earlier one was without any subject.


What is the significance of adding the Jitter Buffer in Network package?
Network package is extended by both RTP package and TDM package,
which are supported by ephemeral and physical termination, respectively.
Does this mean that jitter buffer shall be implemented by both physical
termination and ephemeral termination ?
This property certainly seems redundant for one type of termination.

-Madhubabu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  9 00:57:34 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23912
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 9 Jun 2000 00:57:34 -0400 (EDT)
Received: from standards (47.234.32.16:4660) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74552@standards.nortelnetworks.com>; Fri, 9 Jun 2000 0:47:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0492 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 00:47:52 -0400
Received: from mailcity.com (209.1.236.7:65475) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB74551@standards.nortelnetworks.com>; Fri, 9 Jun 2000 0:47:52
          -0400
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Thu Jun  8 21:48:31
          2000
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
X-Sender-Ip: 216.6.88.34
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Message-ID:  <GEGIKFDHNDJEAAAA@mailcity.com>
Date:         Thu, 8 Jun 2000 21:48:31 -0700
Reply-To: hussainmf@mailcity.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hussain F Mohammad <hussainmf@mailcity.com>
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Subject:      Re: Choosing of ephemeral / physical Termination.
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Tom,
Considering a scenrio where a Residential MG supports only point-to-point calls, with only two possible termination types (one physical and other ephemeral) in a single context. Say, MG returns the ADD response without actually knowing the type of termination, there may arise a situation at later stage in the context lifecycle where the unspecified termination type turns out to be the same as the type of other terminationn in the context (physical  & physical or ephemeral & ephemeral). As MG is not capable of supporting such contexts, the only possible way out is to send service change for the terminations in the given context. But this should not have happened and the initial ADD response should have been a failure.

Any other comments
-Hussain.

--

On Thu, 8 Jun 2000 08:30:23
 Tom-PT Taylor wrote:
>Yes, as I recall Brian agreed that my interpretation was a possible one.
>
>> -----Original Message-----
>> From:        Hussain F Mohammad [SMTP:hussainmf@MAILCITY.COM]
>> Sent:        Thursday, June 08, 2000 7:10 AM
>> To:  MEGACO@STANDARDS.NORTELNETWORKS.COM
>> Subject:     Re: Choosing of ephemeral / physical Termination.
>>
>> Is this issue closed??
>>
>>
>> > -----Original Message-----
>> > From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM]
>> > Sent: Thursday, April 06, 2000 10:17 AM
>> > To: MEGACO@standards.nortelnetworks.com
>> > Subject: Re: Choosing of ephemeral / physical Termination.
>> >
>> >
>> > Tom,
>> >
>> > I was searching through the archives but I am not sure this issue was
>> > settled.
>> > Have you make a final decision on this issue yet?
>> > Is it reflected somewhere in the latest version of the Standard?
>> >
>> >
>> > Thanks
>> > Chuong
>> >
>> >
>> > On Thu, 27 Jan 2000 15:09:24 -0600, Tom-PT Taylor
>> > <taylor@NORTELNETWORKS.COM> wrote:
>> >
>> > >I think one could interpret Context=${Add=${}} as follows:
>> > >
>> > >"Create a new context.  Allocate a terminationID and any
>> > software resources
>> > >required to hold more information about that termination when that
>> > >information is provided.  Return an error if there is any attempt to
>> > >activate a media flow before there is enough information to
>> > do so."  Not
>> > >sure why you'd do this really -- it means extra messaging to
>> > follow up.
>> > >
>> > >
>> > >> -----Original Message-----
>> > >> From: Rosen, Brian [SMTP:brosen@FORE.COM]
>> > >> Sent: Wednesday, January 26, 2000 4:07 PM
>> > >> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>> > >> Subject:      Re: Choosing of ephemeral / physical Termination.
>> > >>
>> > >> Generally determined by the "kind" of termination requested.
>> > >> Which is in turn, easily discernable from the Media command.
>> > >>
>> > >> However, upon reflection, I think it's not a good answer.
>> > >> I'd propose that we not allow selection of a physical termination,
>> > >> in which case choose is always create an ephemeral.  In particular,
>> > >> the following is perfectly legal:
>> > >> Context=${Add=${}}
>> > >> What do you get?
>> > >>
>> > >> Brian
>> > >>
>> > >> > -----Original Message-----
>> > >> > From: Sachin Mittal [mailto:samittal@hss.hns.com]
>> > >> > Sent: Tuesday, January 25, 2000 9:01 AM
>> > >> > To: MEGACO@standards.nortelnetworks.com
>> > >> > Subject: Choosing of ephemeral / physical Termination.
>> > >> >
>> > >> >
>> > >> > Annex B.1 says that "The CHOOSE TerminationID $ may be used
>> > >> > to signal to the MG
>> > >> > that it has to create an
>> > >> > ephemeral Termination or select an idle physical Termination".
>> > >> > How can MG determine when to create an ephemeral termination
>> > >> > and when to choose
>> > >> > idle physical termination.??
>> > >> > What is the logic behind this decision making?
>> > >> >
>> > >> > regards
>> > >> > -Sachin Mittal
>> > >> >
>> > >
>> >
>>
>>
>> Send FREE Greetings for Father's Day--or any day!
>> Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct
>


Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  9 06:24:35 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08154
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 9 Jun 2000 06:24:34 -0400 (EDT)
Received: from standards (47.234.32.16:2964) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB745CC@standards.nortelnetworks.com>; Fri, 9 Jun 2000 6:15:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0649 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 06:15:14 -0400
Received: from smtp2.cluster.oleane.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB745CB@standards.nortelnetworks.com>; Fri, 9 Jun 2000 6:15:14
          -0400
Received: from oleane  (dyn-1-2-224.Vin.dialup.oleane.fr [194.2.4.224])  by
          smtp2.cluster.oleane.net  with SMTP id MAA10607 for
          <megaco@standards.nortelnetworks.com>; Fri, 9 Jun 2000 12:24:21 +0200
          (CEST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0031_01BFD20D.56109B80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Message-ID:  <003401bfd1fc$935a5dc0$7501a8c0@oleane.oleane.com>
Date:         Fri, 9 Jun 2000 12:22:11 +0200
Reply-To: Peter Lewis <peter.lewis@UPPERSIDE.FR>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Lewis <peter.lewis@UPPERSIDE.FR>
Subject:      MGC CALL FOR PAPER
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01BFD20D.56109B80
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


MGCP/Megaco Conference 14 to 17 November 2000.=20
Second edition: deployment experiences, operational issues, =
interoperability status.
Please get more details on the call for papers online:
http://www.upperside.fr/bamgc2yk.htm

------=_NextPart_000_0031_01BFD20D.56109B80
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>MGCP/Megaco Conference 14 to 17 =
November 2000.=20
</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Second edition: deployment =
experiences,=20
operational issues, interoperability status.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>Please get =
more details on=20
the call for papers online:</FONT></DIV>
<DIV><FONT size=3D2><A=20
href=3D"http://www.upperside.fr/bamgc2yk.htm">http://www.upperside.fr/bam=
gc2yk.htm</A></FONT></DIV></DIV></DIV></BODY></HTML>

------=_NextPart_000_0031_01BFD20D.56109B80--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  9 08:38:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10297
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 9 Jun 2000 08:38:30 -0400 (EDT)
Received: from standards (47.234.32.16:1210) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB746B8@standards.nortelnetworks.com>; Fri, 9 Jun 2000 8:29:16 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0940 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 08:29:15 -0400
Received: from qhars002.nortel.com (47.101.112.102:34161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB746B7@standards.nortelnetworks.com>; Fri, 9 Jun 2000 8:29:11
          -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Fri, 9 Jun 2000 13:32:54 +0100
Received: from zcard00m.ca.nortel.com (actually zcard00m) by
          ertpg14e1.nortelnetworks.com; Fri, 9 Jun 2000 08:32:20 -0400
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2650.21) id MPQ14JPS; Fri, 9 Jun 2000 08:32:14 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by
          zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id L5HL8DTS; Fri, 9 Jun 2000 08:32:16
          -0400
X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CFC9940A@whq-msgusr-02.fore.com>
Content-Type: multipart/alternative;
              boundary="------------C398ECD5A6ADCB1269F45C2A"
Message-ID:  <3940E45C.B69BB7A9@americasm01.nt.com>
Date:         Fri, 9 Jun 2000 08:34:36 -0400
Reply-To: Abdallah Rayhan <arayhan@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Abdallah Rayhan <arayhan@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: Can we identify calls from messages ?
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------C398ECD5A6ADCB1269F45C2A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Brian,

I dont see much difference between this approach and scripts!
We dont have scripts in v1. Is this a way around that?

Abdallah

"Rosen, Brian" wrote:

>  The idea of having a value kept by the MG on behalf of the MGC on a
> per context (or even per-termination)is a worthy thought, and my own
> development people are asking me to promote that idea for
> anotherreason - recovery from failure.  Creating a package that allows
> the MGC to specify that a termination holdan opaque data object, which
> the MGC can set and get is straightforward. We have a draft, which we
> could publish. Trying to get the MG to do something with this object
> (like delete all contexts with this value) is abehavior change that
> would need a protocol extension. Brian
>
>      -----Original Message-----
>      From: Al Varney [mailto:varney@LUCENT.COM]
>      Sent: Wednesday, June 07, 2000 3:02 PM
>      To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject: Re: Can we identify calls from messages ?
>
>      At 13:52 06/06/2000 -0500, Tom-PT Taylor wrote:
>
>
>     > There is no necessary connection between Megaco messages
>     > and calls.  One Megaco message could contain multiple
>     > transactions.  The one thing you can be fairly sure of is
>     > that actions related to the same context are related to
>     > the same conference, but Megaco/H.248 has no call
>     > identifier as such.
>
>
>         In the spirit of keeping protocols "open" (to new
>      applications), I think is useful to decouple the concept of
>      "a call" (something only an MGC can determine/distinguish)
>      and connections (something H.248 MGs do).  If I use Megaco
>      messages to intermix music, barge-in requests and
>      announcements of blue-light specials over an H.248-based
>      public address system at K-Mart, where are the "calls"?
>
>         More seriously, many actions requested of an MG could be
>      done outside the bounds of any "call".  Maintenance
>      requests, loop-back, connections for testing, release of
>      resources due to audit, etc. might not involve a "call".
>      Even where calls exist, I could easily find examples (in
>      today's network) where a single Context serves several
>      calls, and a single call involves multiple Contexts (to
>      permit the needed control of who hears what and when).
>
>         On the other hand, it might be useful for MGCs to hand
>      MGs a "reference value" to be associated with a
>      termination.  This would allow an MGC to request removal of
>      all terminations associated with a particular "reference
>      value".  If the reference value happened to be a
>      call-identifier, then some "call association" would result.
>      Worth doing -- probably not.
>
>         If, on the other hand, you want to monitor an H.248
>      interface and collect messages associated with a particular
>      TDM interface or a particular call, that's going to be
>      tough.
>
>      Al Varney - Lucent Technologies  +1 630 224-7493
>      varney@lucent.com
>

--------------C398ECD5A6ADCB1269F45C2A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Brian,
<p>I dont see much difference between this approach and scripts!
<br>We dont have scripts in v1. Is this a way around that?
<p>Abdallah
<p>"Rosen, Brian" wrote:
<blockquote TYPE=CITE>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>The
idea of having a value kept by the MG on behalf of the MGC on a per context
(or even per-termination)</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>is
a worthy thought, and my own development people are asking me to promote
that idea for another</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>reason
- recovery from failure.&nbsp; Creating a package that allows the MGC to
specify that a termination hold</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>an
opaque data object, which the MGC can set and get is straightforward.</font></font></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>We
have a draft, which we could publish.</font></font></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>Trying
to get the MG to do something with this object (like delete all contexts
with this value) is a</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>behavior
change that would need a protocol extension.</font></font></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>Brian</font></font></font>
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Al Varney [<A HREF="mailto:varney@LUCENT.COM">mailto:varney@LUCENT.COM</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, June 07,
2000 3:02 PM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> MEGACO@STANDARDS.NORTELNETWORKS.COM</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: Can we identify
calls from messages ?</font></font>
<br>&nbsp;</div>
At 13:52 06/06/2000 -0500, Tom-PT Taylor wrote:
<br>&nbsp;
<blockquote cite type="cite"><font face="Arial, Helvetica"><font color="#0000FF"><font size=-1>There
is no necessary connection between Megaco messages and calls.&nbsp; One
Megaco message could contain multiple transactions.&nbsp; The one thing
you can be fairly sure of is that actions related to the same context are
related to the same conference, but Megaco/H.248 has no call identifier
as such.</font></font></font></blockquote>

<p><br>&nbsp;&nbsp; In the spirit of keeping protocols "open" (to new applications),
I think is useful to decouple the concept of "a call" (something only an
MGC can determine/distinguish) and connections (something H.248 MGs do).&nbsp;
If I use Megaco messages to intermix music, barge-in requests and announcements
of blue-light specials over an H.248-based public address system at K-Mart,
where are the "calls"?
<p>&nbsp;&nbsp; More seriously, many actions requested of an MG could be
done outside the bounds of any "call".&nbsp; Maintenance requests, loop-back,
connections for testing, release of resources due to audit, etc. might
not involve a "call".&nbsp; Even where calls exist, I could easily find
examples (in today's network) where a single Context serves several calls,
and a single call involves multiple Contexts (to permit the needed control
of who hears what and when).
<p>&nbsp;&nbsp; On the other hand, it might be useful for MGCs to hand
MGs a "reference value" to be associated with a termination.&nbsp; This
would allow an MGC to request removal of all terminations associated with
a particular "reference value".&nbsp; If the reference value happened to
be a call-identifier, then some "call association" would result.&nbsp;
Worth doing -- probably not.
<p>&nbsp;&nbsp; If, on the other hand, you want to monitor an H.248 interface
and collect messages associated with a particular TDM interface or a particular
call, that's going to be tough.
<p>Al Varney - Lucent Technologies&nbsp; +1 630 224-7493&nbsp;&nbsp;&nbsp;
varney@lucent.com</blockquote>
</blockquote>
</html>

--------------C398ECD5A6ADCB1269F45C2A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  9 09:15:52 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10970
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 9 Jun 2000 09:15:52 -0400 (EDT)
Received: from standards (47.234.32.16:1642) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB746DB@standards.nortelnetworks.com>; Fri, 9 Jun 2000 9:06:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0986 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 09:06:44 -0400
Received: from qhars002.nortel.com (47.101.112.102:39546) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB746DA@standards.nortelnetworks.com>; Fri, 9 Jun 2000 9:06:44
          -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Fri, 9 Jun 2000 14:09:35 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Fri, 9 Jun 2000 08:09:04 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPD1TAR4>; Fri, 9 Jun 2000 08:09:11 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480A62@zcard00g.ca.nortel.com>
Date:         Fri, 9 Jun 2000 08:09:06 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Choosing of ephemeral / physical Termination.
X-To:         "hussainmf@mailcity.com" <hussainmf@mailcity.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I think that your case is a particular example of the general case where the
MGC asks the MG to do something it does not have the resources to support.
Rather than issue a ServiceChange, the MG issues an appropriate error return
to the command.  It's up to the MGC to clean up.

> -----Original Message-----
> From: Hussain F Mohammad [SMTP:hussainmf@mailcity.com]
> Sent: Friday, June 09, 2000 12:49 AM
> To:   Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      RE: Choosing of ephemeral / physical Termination.
>
> Tom,
> Considering a scenrio where a Residential MG supports only point-to-point
> calls, with only two possible termination types (one physical and other
> ephemeral) in a single context. Say, MG returns the ADD response without
> actually knowing the type of termination, there may arise a situation at
> later stage in the context lifecycle where the unspecified termination
> type turns out to be the same as the type of other terminationn in the
> context (physical  & physical or ephemeral & ephemeral). As MG is not
> capable of supporting such contexts, the only possible way out is to send
> service change for the terminations in the given context. But this should
> not have happened and the initial ADD response should have been a failure.
>
>
> Any other comments
> -Hussain.
>
> --
>
> On Thu, 8 Jun 2000 08:30:23
>  Tom-PT Taylor wrote:
> >Yes, as I recall Brian agreed that my interpretation was a possible one.
> >
> >> -----Original Message-----
> >> From:      Hussain F Mohammad [SMTP:hussainmf@MAILCITY.COM]
> >> Sent:      Thursday, June 08, 2000 7:10 AM
> >> To:        MEGACO@STANDARDS.NORTELNETWORKS.COM
> >> Subject:   Re: Choosing of ephemeral / physical Termination.
> >>
> >> Is this issue closed??
> >>
> >>
> >> > -----Original Message-----
> >> > From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM]
> >> > Sent: Thursday, April 06, 2000 10:17 AM
> >> > To: MEGACO@standards.nortelnetworks.com
> >> > Subject: Re: Choosing of ephemeral / physical Termination.
> >> >
> >> >
> >> > Tom,
> >> >
> >> > I was searching through the archives but I am not sure this issue was
> >> > settled.
> >> > Have you make a final decision on this issue yet?
> >> > Is it reflected somewhere in the latest version of the Standard?
> >> >
> >> >
> >> > Thanks
> >> > Chuong
> >> >
> >> >
> >> > On Thu, 27 Jan 2000 15:09:24 -0600, Tom-PT Taylor
> >> > <taylor@NORTELNETWORKS.COM> wrote:
> >> >
> >> > >I think one could interpret Context=${Add=${}} as follows:
> >> > >
> >> > >"Create a new context.  Allocate a terminationID and any
> >> > software resources
> >> > >required to hold more information about that termination when that
> >> > >information is provided.  Return an error if there is any attempt to
> >> > >activate a media flow before there is enough information to
> >> > do so."  Not
> >> > >sure why you'd do this really -- it means extra messaging to
> >> > follow up.
> >> > >
> >> > >
> >> > >> -----Original Message-----
> >> > >> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> >> > >> Sent: Wednesday, January 26, 2000 4:07 PM
> >> > >> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> >> > >> Subject:      Re: Choosing of ephemeral / physical Termination.
> >> > >>
> >> > >> Generally determined by the "kind" of termination requested.
> >> > >> Which is in turn, easily discernable from the Media command.
> >> > >>
> >> > >> However, upon reflection, I think it's not a good answer.
> >> > >> I'd propose that we not allow selection of a physical termination,
> >> > >> in which case choose is always create an ephemeral.  In
> particular,
> >> > >> the following is perfectly legal:
> >> > >> Context=${Add=${}}
> >> > >> What do you get?
> >> > >>
> >> > >> Brian
> >> > >>
> >> > >> > -----Original Message-----
> >> > >> > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> >> > >> > Sent: Tuesday, January 25, 2000 9:01 AM
> >> > >> > To: MEGACO@standards.nortelnetworks.com
> >> > >> > Subject: Choosing of ephemeral / physical Termination.
> >> > >> >
> >> > >> >
> >> > >> > Annex B.1 says that "The CHOOSE TerminationID $ may be used
> >> > >> > to signal to the MG
> >> > >> > that it has to create an
> >> > >> > ephemeral Termination or select an idle physical Termination".
> >> > >> > How can MG determine when to create an ephemeral termination
> >> > >> > and when to choose
> >> > >> > idle physical termination.??
> >> > >> > What is the logic behind this decision making?
> >> > >> >
> >> > >> > regards
> >> > >> > -Sachin Mittal
> >> > >> >
> >> > >
> >> >
> >>
> >>
> >> Send FREE Greetings for Father's Day--or any day!
> >> Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct
> >
>
>
> Send FREE Greetings for Father's Day--or any day!
> Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  9 10:03:40 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11927
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 9 Jun 2000 10:03:39 -0400 (EDT)
Received: from standards (47.234.32.16:1080) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74718@standards.nortelnetworks.com>; Fri, 9 Jun 2000 9:54:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1059 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 09:54:30 -0400
Received: from june.idc1.level3.com (june.Broomfield1.Level3.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB74715@standards.nortelnetworks.com>; Fri, 9 Jun 2000 9:44:30
          -0400
Received: from f1ee40-03.idc1.level3.com (hme0.f1ee40-03.idc1.oss.level3.com
          [10.1.144.140]) by june.idc1.level3.com (8.9.3/8.9.3) with ESMTP id
          NAA02825 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 9 Jun 2000
          13:53:00 GMT
Received: from l3londmail01.l3.com (localhost [127.0.0.1]) by
          f1ee40-03.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id HAA26989
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 9 Jun 2000 07:53:00
          -0600 (MDT)
Received: by l3londmail01.eu.l3.com with Internet Mail Service (5.5.2650.10) id
          <MPCF6FT7>; Fri, 9 Jun 2000 14:50:19 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <6FA15EC018C1D211AA4C0008C70D033006A5B14C@l3londmail02.eu.l3.com>
Date:         Fri, 9 Jun 2000 14:51:41 +0100
Reply-To: "Quan, Michael" <Michael.Quan@LEVEL3.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Quan, Michael" <Michael.Quan@LEVEL3.COM>
Subject:      unsubscribe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Michael Quan

International Voice Engineering
Level (3) Communications
66 Prescot St
London, E1 8HG

Tel:                +44 (0)20 7864 4444
Direct Line:  +44 (0)20 7864 0941
Mobile:         +44 (0)788 0506108
Fax:                +44 (0)20 7864 4488
Email:             michael.quan@level3.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  9 10:59:42 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12597
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 9 Jun 2000 10:59:41 -0400 (EDT)
Received: from standards (47.234.32.16:2701) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74742@standards.nortelnetworks.com>; Fri, 9 Jun 2000 10:50:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1113 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 10:50:29 -0400
Received: from hd2.dot.net.in (hd2.vsnl.net.in) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB74741@standards.nortelnetworks.com>; Fri, 9 Jun 2000 10:50:28
          -0400
Received: from hyd.chiplogic.com ([203.197.20.111]) by hd2.dot.net.in
          (8.8.8/8.8.8) with ESMTP id UAA14550 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 9 Jun 2000 20:26:19 +0530
          (IST)
Received: from chiplogic.com ([192.168.2.61]) by hyd.chiplogic.com
          (8.8.7/8.8.7) with ESMTP id UAA28385 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 9 Jun 2000 20:22:37 +0530
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL}  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CFC9937B@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39410731.D0DC171F@chiplogic.com>
Date:         Fri, 9 Jun 2000 20:33:13 +0530
Reply-To: SSMudholkar <ssm@CHIPLOGIC.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: SSMudholkar <ssm@CHIPLOGIC.COM>
Organization: CHIPLOGIC
Subject:      Re: About Packages..
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,
    In real world implementation ,are MGs supposed to support packages
based on a profile or can it support any set of packages ?

Any clarification on this will be helpful.
Thanks in advance
-sanjeev

"Rosen, Brian" wrote:

> At the MSF, we are working on a set of profiles, which we plan
> to make public pretty soon.  You can see the basic outline in
> my test profile on the megaco-interop list.  I think that they
> will be very good examples of what a profile would look like.
> At some point, we should document this in the IETF, I agree.
>
> Brian
>
> > -----Original Message-----
> > From: arayhan@nortelnetworks.com [mailto:arayhan@nortelnetworks.com]
> > Sent: Tuesday, June 06, 2000 5:21 PM
> > To: Rosen, Brian
> > Cc: SSMudholkar
> > Subject: Re: About Packages..
> >
> >
> > Brian,
> >
> > I agree with Brian, also the profile would define the
> > terminations the MG implements in addition to the packages.
> >
> > While we have profile as part of the grammar, I can not
> > find a profile definition and profile requirements statements
> > in the megaco draft. Dont we need to come up with
> > profile requirements draft? which defines how to define
> > profiles and the requirements that a profile must meet
> > for megaco!
> >
> > Abdallah
> >
> > "Rosen, Brian" wrote:
> >
> > > No one else seems to have replied to this one.
> > >
> > > Packages have to be implemented on the MG.  It's not something the
> > > MGC decides.  The designer of the MG decides what kind of
> > terminations
> > > the MG will support, and implements the appropriate packages needed
> > > to control that kind of termination.
> > >
> > > The MGC finds out what packages are implemented via the
> > audit command.
> > > The MGC has to be built to understand what capabilities a package
> > > may have.  That is one reason for the profile mechanism - the MGC
> > > can discover the profile before it accepts the MG for service.
> > > The profile includes a set of packages that must be implemented.  If
> > > the MGC knows how to support a device with a specific profile, by
> > > implication it knows how to support terminations with the packages
> > > listed in the profile.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: SSMudholkar [mailto:ssm@CHIPLOGIC.COM]
> > > > Sent: Monday, June 05, 2000 6:37 AM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: About Packages..
> > > >
> > > >
> > > > Hi ,
> > > >     A newbee question.
> > > >  When an MG comes up is it required that all it's
> > > > physical terminations (which will be in null context )
> > have to support
> > > > some
> > > > packages by default or all the packages it has to support will be
> > > > specified
> > > > by the MGC when a termination is created through ADD command.
> > > >
> > > > Thanks in advance
> > > > -sanjeev
> > > >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  9 11:43:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13397
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 9 Jun 2000 11:43:20 -0400 (EDT)
Received: from standards (47.234.32.16:1119) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7478D@standards.nortelnetworks.com>; Fri, 9 Jun 2000 11:34:14 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1213 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 11:34:14 -0400
Received: from qhars002.nortel.com (47.101.112.102:60623) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7478C@standards.nortelnetworks.com>; Fri, 9 Jun 2000
          11:34:14 -0400
Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com;
          Fri, 9 Jun 2000 16:36:15 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Fri, 9 Jun 2000 10:27:45 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPD1THKH>; Fri, 9 Jun 2000 10:36:11 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480A67@zcard00g.ca.nortel.com>
Date:         Fri, 9 Jun 2000 10:36:06 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: About Packages..
X-To:         SSMudholkar <ssm@CHIPLOGIC.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The Megaco/H.248 view of profiles is that they are something devised by
industry fora, not a standards matter.  While an MG claiming conformance to
a given profile should support all the packages that profile posits, there
is nothing to prevent it from supporting other packages besides.  My
personal opinion is that this will be a frequent occurrence, at least until
more experience is gained.

> -----Original Message-----
> From: SSMudholkar [SMTP:ssm@CHIPLOGIC.COM]
> Sent: Friday, June 09, 2000 11:03 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: About Packages..
>
> Hi,
>     In real world implementation ,are MGs supposed to support packages
> based on a profile or can it support any set of packages ?
>
> Any clarification on this will be helpful.
> Thanks in advance
> -sanjeev
>
> "Rosen, Brian" wrote:
>
> > At the MSF, we are working on a set of profiles, which we plan
> > to make public pretty soon.  You can see the basic outline in
> > my test profile on the megaco-interop list.  I think that they
> > will be very good examples of what a profile would look like.
> > At some point, we should document this in the IETF, I agree.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: arayhan@nortelnetworks.com [mailto:arayhan@nortelnetworks.com]
> > > Sent: Tuesday, June 06, 2000 5:21 PM
> > > To: Rosen, Brian
> > > Cc: SSMudholkar
> > > Subject: Re: About Packages..
> > >
> > >
> > > Brian,
> > >
> > > I agree with Brian, also the profile would define the
> > > terminations the MG implements in addition to the packages.
> > >
> > > While we have profile as part of the grammar, I can not
> > > find a profile definition and profile requirements statements
> > > in the megaco draft. Dont we need to come up with
> > > profile requirements draft? which defines how to define
> > > profiles and the requirements that a profile must meet
> > > for megaco!
> > >
> > > Abdallah
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > No one else seems to have replied to this one.
> > > >
> > > > Packages have to be implemented on the MG.  It's not something the
> > > > MGC decides.  The designer of the MG decides what kind of
> > > terminations
> > > > the MG will support, and implements the appropriate packages needed
> > > > to control that kind of termination.
> > > >
> > > > The MGC finds out what packages are implemented via the
> > > audit command.
> > > > The MGC has to be built to understand what capabilities a package
> > > > may have.  That is one reason for the profile mechanism - the MGC
> > > > can discover the profile before it accepts the MG for service.
> > > > The profile includes a set of packages that must be implemented.  If
> > > > the MGC knows how to support a device with a specific profile, by
> > > > implication it knows how to support terminations with the packages
> > > > listed in the profile.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: SSMudholkar [mailto:ssm@CHIPLOGIC.COM]
> > > > > Sent: Monday, June 05, 2000 6:37 AM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: About Packages..
> > > > >
> > > > >
> > > > > Hi ,
> > > > >     A newbee question.
> > > > >  When an MG comes up is it required that all it's
> > > > > physical terminations (which will be in null context )
> > > have to support
> > > > > some
> > > > > packages by default or all the packages it has to support will be
> > > > > specified
> > > > > by the MGC when a termination is created through ADD command.
> > > > >
> > > > > Thanks in advance
> > > > > -sanjeev
> > > > >
> > >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun  9 11:58:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13756
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 9 Jun 2000 11:58:03 -0400 (EDT)
Received: from standards (47.234.32.16:1119) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB747B0@standards.nortelnetworks.com>; Fri, 9 Jun 2000 11:49:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1259 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 11:49:01 -0400
Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB747AF@standards.nortelnetworks.com>; Fri, 9 Jun 2000 11:49:01
          -0400
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by
          sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA02556; Fri, 9
          Jun 2000 08:57:42 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id IAA02258; Fri, 9 Jun 2000 08:57:32 -0700
          (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4FBEA8857476D311A03300204840E1CFC9940A@whq-msgusr-02.fore.com>
            <3940E45C.B69BB7A9@americasm01.nt.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
        @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
        bUcI'1!
Message-ID:  <14657.5100.347647.998883@thomasm-u1.cisco.com>
Date:         Fri, 9 Jun 2000 08:57:32 -0700
Reply-To: Michael Thomas <mat@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael Thomas <mat@CISCO.COM>
Subject:      Re: Can we identify calls from messages ?
X-To:         Abdallah Rayhan <arayhan@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <3940E45C.B69BB7A9@americasm01.nt.com>
Content-Transfer-Encoding: 7bit

Abdallah Rayhan writes:
 > Brian,
 >
 > I dont see much difference between this approach and scripts!
 > We dont have scripts in v1. Is this a way around that?

   I disagree. The MGC can deposit and retrieve
   state on the MG right now: that's what signals
   and audits get you. Normally the deposited state
   causes an action. What Brian is describing is
   depositing state for which the action is to
   store it in memory for a later audit.

   Scripts, on the other hand, imply programatic
   flow. The base variable mechanism was always
   there in the form of signals and events. What
   is lacking for scripts is the execution flow
   definitions, which is a substantial can of
   worms.

   Hey Brian! What you want here is a TECO
   registers package! :-)

                Mike

 >
 > Abdallah
 >
 > "Rosen, Brian" wrote:
 >
 > >  The idea of having a value kept by the MG on behalf of the MGC on a
 > > per context (or even per-termination)is a worthy thought, and my own
 > > development people are asking me to promote that idea for
 > > anotherreason - recovery from failure.  Creating a package that allows
 > > the MGC to specify that a termination holdan opaque data object, which
 > > the MGC can set and get is straightforward. We have a draft, which we
 > > could publish. Trying to get the MG to do something with this object
 > > (like delete all contexts with this value) is abehavior change that
 > > would need a protocol extension. Brian
 > >
 > >      -----Original Message-----
 > >      From: Al Varney [mailto:varney@LUCENT.COM]
 > >      Sent: Wednesday, June 07, 2000 3:02 PM
 > >      To: MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >      Subject: Re: Can we identify calls from messages ?
 > >
 > >      At 13:52 06/06/2000 -0500, Tom-PT Taylor wrote:
 > >
 > >
 > >     > There is no necessary connection between Megaco messages
 > >     > and calls.  One Megaco message could contain multiple
 > >     > transactions.  The one thing you can be fairly sure of is
 > >     > that actions related to the same context are related to
 > >     > the same conference, but Megaco/H.248 has no call
 > >     > identifier as such.
 > >
 > >
 > >         In the spirit of keeping protocols "open" (to new
 > >      applications), I think is useful to decouple the concept of
 > >      "a call" (something only an MGC can determine/distinguish)
 > >      and connections (something H.248 MGs do).  If I use Megaco
 > >      messages to intermix music, barge-in requests and
 > >      announcements of blue-light specials over an H.248-based
 > >      public address system at K-Mart, where are the "calls"?
 > >
 > >         More seriously, many actions requested of an MG could be
 > >      done outside the bounds of any "call".  Maintenance
 > >      requests, loop-back, connections for testing, release of
 > >      resources due to audit, etc. might not involve a "call".
 > >      Even where calls exist, I could easily find examples (in
 > >      today's network) where a single Context serves several
 > >      calls, and a single call involves multiple Contexts (to
 > >      permit the needed control of who hears what and when).
 > >
 > >         On the other hand, it might be useful for MGCs to hand
 > >      MGs a "reference value" to be associated with a
 > >      termination.  This would allow an MGC to request removal of
 > >      all terminations associated with a particular "reference
 > >      value".  If the reference value happened to be a
 > >      call-identifier, then some "call association" would result.
 > >      Worth doing -- probably not.
 > >
 > >         If, on the other hand, you want to monitor an H.248
 > >      interface and collect messages associated with a particular
 > >      TDM interface or a particular call, that's going to be
 > >      tough.
 > >
 > >      Al Varney - Lucent Technologies  +1 630 224-7493
 > >      varney@lucent.com
 > >
 > <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 > <html>
 > Brian,
 > <p>I dont see much difference between this approach and scripts!
 > <br>We dont have scripts in v1. Is this a way around that?
 > <p>Abdallah
 > <p>"Rosen, Brian" wrote:
 > <blockquote TYPE=CITE>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>The
 > idea of having a value kept by the MG on behalf of the MGC on a per context
 > (or even per-termination)</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>is
 > a worthy thought, and my own development people are asking me to promote
 > that idea for another</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>reason
 > - recovery from failure.&nbsp; Creating a package that allows the MGC to
 > specify that a termination hold</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>an
 > opaque data object, which the MGC can set and get is straightforward.</font></font></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>We
 > have a draft, which we could publish.</font></font></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>Trying
 > to get the MG to do something with this object (like delete all contexts
 > with this value) is a</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>behavior
 > change that would need a protocol extension.</font></font></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>Brian</font></font></font>
 > <blockquote
 > style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
 > <div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
 > Message-----</font></font>
 > <br><font face="Tahoma"><font size=-1><b>From:</b> Al Varney [<A HREF="mailto:varney@LUCENT.COM">mailto:varney@LUCENT.COM</A>]</font></font>
 > <br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, June 07,
 > 2000 3:02 PM</font></font>
 > <br><font face="Tahoma"><font size=-1><b>To:</b> MEGACO@STANDARDS.NORTELNETWORKS.COM</font></font>
 > <br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: Can we identify
 > calls from messages ?</font></font>
 > <br>&nbsp;</div>
 > At 13:52 06/06/2000 -0500, Tom-PT Taylor wrote:
 > <br>&nbsp;
 > <blockquote cite type="cite"><font face="Arial, Helvetica"><font color="#0000FF"><font size=-1>There
 > is no necessary connection between Megaco messages and calls.&nbsp; One
 > Megaco message could contain multiple transactions.&nbsp; The one thing
 > you can be fairly sure of is that actions related to the same context are
 > related to the same conference, but Megaco/H.248 has no call identifier
 > as such.</font></font></font></blockquote>
 >
 > <p><br>&nbsp;&nbsp; In the spirit of keeping protocols "open" (to new applications),
 > I think is useful to decouple the concept of "a call" (something only an
 > MGC can determine/distinguish) and connections (something H.248 MGs do).&nbsp;
 > If I use Megaco messages to intermix music, barge-in requests and announcements
 > of blue-light specials over an H.248-based public address system at K-Mart,
 > where are the "calls"?
 > <p>&nbsp;&nbsp; More seriously, many actions requested of an MG could be
 > done outside the bounds of any "call".&nbsp; Maintenance requests, loop-back,
 > connections for testing, release of resources due to audit, etc. might
 > not involve a "call".&nbsp; Even where calls exist, I could easily find
 > examples (in today's network) where a single Context serves several calls,
 > and a single call involves multiple Contexts (to permit the needed control
 > of who hears what and when).
 > <p>&nbsp;&nbsp; On the other hand, it might be useful for MGCs to hand
 > MGs a "reference value" to be associated with a termination.&nbsp; This
 > would allow an MGC to request removal of all terminations associated with
 > a particular "reference value".&nbsp; If the reference value happened to
 > be a call-identifier, then some "call association" would result.&nbsp;
 > Worth doing -- probably not.
 > <p>&nbsp;&nbsp; If, on the other hand, you want to monitor an H.248 interface
 > and collect messages associated with a particular TDM interface or a particular
 > call, that's going to be tough.
 > <p>Al Varney - Lucent Technologies&nbsp; +1 630 224-7493&nbsp;&nbsp;&nbsp;
 > varney@lucent.com</blockquote>
 > </blockquote>
 > </html>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jun 11 18:10:35 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09880
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 11 Jun 2000 18:10:34 -0400 (EDT)
Received: from standards (47.234.32.16:3269) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74C48@standards.nortelnetworks.com>; 11 Jun 2000 18:00:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2843 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 11 Jun 2000 18:00:55 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB74C47@standards.nortelnetworks.com>; 11 Jun 2000 18:00:54 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id SAA23598; Sun, 11 Jun 2000 18:09:29 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id SAA29914; Sun, 11 Jun 2000 18:09:30 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <MR1YP6DK>; Sun, 11 Jun 2000 18:09:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFD3F1.B5D34366"
Message-ID:  <4FBEA8857476D311A03300204840E1CFC994A2@whq-msgusr-02.fore.com>
Date:         Sun, 11 Jun 2000 18:09:27 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: MGC-Initiated Control
X-To:         Amy Pendleton <aspen@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Comments below

Brian

-----Original Message-----
From: Amy Pendleton [mailto:aspen@NORTELNETWORKS.COM]
Sent: Tuesday, June 06, 2000 3:16 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: MGC-Initiated Control



Hi,

I would like to present some more justification for the proposal of which
Tom Taylor spoke.

(1) The MGC is the central point of control within the network.  All call
services run through the MGC and only it knows when it is ready to receive
calls and to establish connections.

<br> These are distributed systems.  While the MGC is the "Controller" (the
C in MGC), no calls can be handled until all the components are ready.  The
design of the protocol permits the MGC to control when calls are accepted.

(2) MGC failover strategy is exposed to MG's by allowing the MG to attempt
to "rehouse" itself when it detects an MGC instance has failed.  The MGC
maintains a fault tolerance system between its instances and should remain
in complete control of which instance is active at a given time.  It has
always looked to me like by allowing the MG's to hunt for their serving MGC,
the  specification is suggesting that the MG should have some part in the
failover of an MGC. In the case where an MG is isolated from its serving MGC
but the MGC is in fact working fine with the rest of the network, what is
achieved by having the MG try the next MGC instance in its list.

<br> There are many failover strategies.  Some require the MG detect
failure, some require the standby MGC to detect failure, some have
mechanisms that are not even visible to the MGs.  Skewing the protocol for
one of these doesn't seem appropriate.  I'll grant that you would ideally
like to have the protocol neutral to all.

(3) MGC's ability to provide call services will be delayed by waiting for
the gateways to establish communication with it both on initialization and
failover.

<br> I don't really understand this.  At best, it's true in one direction
only (call from some gateway that is initialized towards a gateway that is
not).  Having MGs get control associations with the randomization Christian
suggested has to result in better average response if both directions are
considered.  I think the whole subject is not worth worrying about.

I recognize that the random spreading of (re)connection from the MG to the
MGC may work but note that MGC-initiated control does not require this to
scale -- the MGC will establish connectivity based on it own ability to
handle call or network traffic.

<br> in general, I suspect you are not thinking about the really interesting
cases of mostly residential gateways.  If there are only trunk or other
large scale access gateways, there are few enough of them that these issues
don't matter at all.  The real issue is that it's the MG that is the one
that will go up and down, and the MGC will be relatively stable.  In that
circumstance, you want the MG to contact the MGC when it comes back up.  You
don't want the MGC polling all the non-responding MGs periodically.  Failure
of the MGC has to work pretty well, but randomized backoff does work pretty
well.

Finally, the protocol is pretty fixed now.  Anything that changes behavior
has to be considered a CS2 kind of thing.  It's fine to start a list of
these issues, but I think we have to shelve any that are not real
show-stoppers.  This just isn't such an issue.

Thanks,
Amy


        -----Original Message-----
From:   Brian F. G. Bidulock [SMTP:brian.bidulock@INET.COM]
Sent:   Tuesday, June 06, 2000 1:15 PM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Re: MGC-Initiated Control

        Christian,

        Thanks for the tips.  Are you referring to your v5 draft of MGCP?
Does it
include recommended time intervals and priorities?

        Also, I am confused as to which timers do not need to be maintained
doing
it "from the MG".

        On Tue, 06 Jun 2000, Christian Huitema wrote:

        >
> > I understand that you have considerable experience in this
> > area.  How did
> > you intend to handle the recovery situation where the network
> > between MGC
> > and MG is interrupted and all MGs attempt to reconnect as soon as the
> > network is re-established?
>
> This is discussed at length in the MGCP documentation (ask the Cable
Labs).
> Basically, you use a random spreading of the [re]connection attempts over
an
> appropriate time interval, and you skew the spreading so that MG's that
> actually need to speak, because they have some change of state to report,
> become more impatient than those with nothing special to say. Note that
this
> second part, providing priority to the MG's that need it most, would be
> impossible in an MGC-driven reconnection. Also, doing it "from the MG"
> reduces the load at the MGC, which does not need to maintain timers, etc.

        --
Brian F. G. Bidulock


------_=_NextPart_001_01BFD3F1.B5D34366
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: MGC-Initiated Control</TITLE>

<META content="MSHTML 5.00.3017.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#800000 face=Arial size=2><SPAN
class=030295414-09062000>Comments below</SPAN></FONT></DIV>
<DIV><SPAN class=030295414-09062000></SPAN>&nbsp;</DIV>
<DIV><FONT color=#800000 face=Arial size=2><SPAN
class=030295414-09062000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Amy Pendleton
  [mailto:aspen@NORTELNETWORKS.COM]<BR><B>Sent:</B> Tuesday, June 06, 2000 3:16
  PM<BR><B>To:</B> MEGACO@STANDARDS.NORTELNETWORKS.COM<BR><B>Subject:</B> Re:
  MGC-Initiated Control<BR><BR></DIV></FONT>
  <P><FONT color=#0000ff face=Arial size=2>Hi,</FONT> </P>
  <P><FONT color=#0000ff face=Arial size=2>I would like to present some more
  justification for the proposal of which Tom Taylor spoke.</FONT> </P>
  <P><FONT size=2><FONT color=#0000ff><FONT face=Arial>(1) The MGC is the
  central point of control within the network.&nbsp; All call services run
  through the MGC and only it knows when it is ready to receive calls and to
  establish connections.<SPAN
  class=030295414-09062000>&nbsp;</SPAN></FONT></FONT></FONT></P>
  <P><FONT face=Arial><FONT color=#800000 size=2><SPAN
  class=030295414-09062000>&lt;br&gt; These are distributed systems.&nbsp; While
  the MGC is the "Controller" (the C in MGC), no calls can be handled until all
  the components are ready.&nbsp; The design of the protocol permits the MGC to
  control when calls are accepted.&nbsp; </SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff><FONT face=Arial>(2) MGC failover strategy
  is exposed to MG's by allowing the MG to attempt to "rehouse" itself when it
  detects an MGC instance has failed.&nbsp; The MGC maintains a fault tolerance
  system between its instances and should remain in complete control of which
  instance is active at a given time.&nbsp; It has always looked to me like by
  allowing the MG's to hunt for their serving MGC, the&nbsp; specification is
  suggesting that the MG should have some part in the failover of an MGC. In the
  case where an MG is isolated from its serving MGC but the MGC is in fact
  working fine with the rest of the network, what is achieved by having the MG
  try the next MGC instance in its list.&nbsp;&nbsp;<SPAN
  class=030295414-09062000>&nbsp;</SPAN></FONT></FONT></FONT></P>
  <P><FONT color=#800000><FONT face=Arial><FONT size=2><SPAN
  class=030295414-09062000>&lt;br&gt;&nbsp;</SPAN><SPAN
  class=030295414-09062000>There are many failover strategies.&nbsp; Some
  require the MG detect failure, some require the standby MGC
  to&nbsp;</SPAN><SPAN class=030295414-09062000>detect&nbsp;failure, some
  have&nbsp;mechanisms that are not even visible to the MGs.&nbsp;&nbsp;Skewing
  the protocol for one of these&nbsp;doesn't seem appropriate.&nbsp;&nbsp;I'll
  grant that you would ideally like to have the protocol neutral to
  all.</SPAN><SPAN
  class=030295414-09062000>&nbsp;</SPAN></FONT></FONT></FONT></P>
  <P><FONT face=Arial><FONT size=2><FONT color=#0000ff><FONT
  color=#000080>(</FONT>3) MGC's ability to provide call services will be
  delayed by waiting for the gateways to establish communication with it both on
  initialization and failover.<SPAN
  class=030295414-09062000>&nbsp;</SPAN></FONT></FONT></FONT></P>
  <P><FONT color=#800000 face=Arial size=2><SPAN
  class=030295414-09062000>&lt;br&gt; I don't really understand this.&nbsp; At
  best, it's&nbsp;true in one direction only (call from some gateway that is
  initialized towards a gateway that is not).&nbsp;&nbsp;Having MGs&nbsp;get
  control associations with the randomization Christian suggested has to result
  in better average&nbsp;response if both directions are considered.&nbsp; I
  think the whole subject is not worth worrying about.&nbsp;</SPAN></FONT></P>
  <P><FONT size=2><FONT color=#0000ff><FONT face=Arial>I recognize that the
  random spreading of (re)connection from the MG to the MGC may work but note
  that MGC-initiated control does not require this to scale -- the MGC will
  establish connectivity based on it own ability to handle call or network
  traffic.&nbsp;&nbsp;<SPAN
  class=030295414-09062000>&nbsp;</SPAN></FONT></FONT></FONT></P>
  <P><FONT color=#800000><FONT face=Arial><FONT size=2><SPAN
  class=030295414-09062000>&lt;br&gt; in general, I suspect you are not thinking
  about the really interesting cases of mostly residential&nbsp;gateways.&nbsp;
  If there are only trunk or other large scale access gateways, there are few
  enough of them that these issues don't matter at all.</SPAN><SPAN
  class=030295414-09062000>&nbsp; The real issue is that&nbsp;it's the MG that
  is the one that will go&nbsp;up and down, and the MGC will be relatively
  stable.&nbsp; In that circumstance, you want the MG to contact the MGC when it
  comes&nbsp;back up.&nbsp; You don't want the MGC polling all the
  non-responding MGs periodically.&nbsp; Failure of the MGC has to work pretty
  well, but randomized backoff does work pretty
  well.</SPAN></FONT></FONT></FONT></P>
  <P><FONT color=#800000 face=Arial size=2><SPAN
  class=030295414-09062000>Finally, the protocol is pretty fixed&nbsp;now.&nbsp;
  Anything that changes behavior has to&nbsp;be considered a CS2 kind of
  thing.&nbsp; It's fine to start a list of these issues, but I think we have to
  shelve any that are not real show-stoppers.&nbsp; This just isn't such an
  issue.</SPAN></FONT></P>
  <P><FONT color=#0000ff face=Arial size=2>Thanks,</FONT> <BR><FONT
  color=#0000ff face=Arial size=2>Amy </FONT></P><BR>
  <UL>
    <P><FONT face=Arial size=1>-----Original Message-----</FONT> <BR><B><FONT
    face=Arial size=1>From:&nbsp;&nbsp;</FONT></B> <FONT face=Arial size=1>Brian
    F. G. Bidulock [SMTP:brian.bidulock@INET.COM]</FONT> <BR><B><FONT face=Arial
    size=1>Sent:&nbsp;&nbsp;</FONT></B> <FONT face=Arial size=1>Tuesday, June
    06, 2000 1:15 PM</FONT> <BR><B><FONT face=Arial
    size=1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial
    size=1>MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><B><FONT face=Arial
    size=1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT
    face=Arial size=1>Re: MGC-Initiated Control</FONT> </P>
    <P><FONT face=Arial size=2>Christian,</FONT> </P>
    <P><FONT face=Arial size=2>Thanks for the tips.&nbsp; Are you referring to
    your v5 draft of MGCP?&nbsp; Does it</FONT> <BR><FONT face=Arial
    size=2>include recommended time intervals and priorities?</FONT> </P>
    <P><FONT face=Arial size=2>Also, I am confused as to which timers do not
    need to be maintained doing</FONT> <BR><FONT face=Arial size=2>it "from the
    MG".</FONT> </P>
    <P><FONT face=Arial size=2>On Tue, 06 Jun 2000, Christian Huitema
    wrote:</FONT> </P>
    <P><FONT face=Arial size=2>&gt;</FONT> <BR><FONT face=Arial size=2>&gt; &gt;
    I understand that you have considerable experience in this</FONT> <BR><FONT
    face=Arial size=2>&gt; &gt; area.&nbsp; How did</FONT> <BR><FONT face=Arial
    size=2>&gt; &gt; you intend to handle the recovery situation where the
    network</FONT> <BR><FONT face=Arial size=2>&gt; &gt; between MGC</FONT>
    <BR><FONT face=Arial size=2>&gt; &gt; and MG is interrupted and all MGs
    attempt to reconnect as soon as the</FONT> <BR><FONT face=Arial size=2>&gt;
    &gt; network is re-established?</FONT> <BR><FONT face=Arial
    size=2>&gt;</FONT> <BR><FONT face=Arial size=2>&gt; This is discussed at
    length in the MGCP documentation (ask the Cable Labs).</FONT> <BR><FONT
    face=Arial size=2>&gt; Basically, you use a random spreading of the
    [re]connection attempts over an</FONT> <BR><FONT face=Arial size=2>&gt;
    appropriate time interval, and you skew the spreading so that MG's
    that</FONT> <BR><FONT face=Arial size=2>&gt; actually need to speak, because
    they have some change of state to report,</FONT> <BR><FONT face=Arial
    size=2>&gt; become more impatient than those with nothing special to say.
    Note that this</FONT> <BR><FONT face=Arial size=2>&gt; second part,
    providing priority to the MG's that need it most, would be</FONT> <BR><FONT
    face=Arial size=2>&gt; impossible in an MGC-driven reconnection. Also, doing
    it "from the MG"</FONT> <BR><FONT face=Arial size=2>&gt; reduces the load at
    the MGC, which does not need to maintain timers, etc.</FONT> </P>
    <P><FONT face=Arial size=2>--</FONT> <BR><FONT face=Arial size=2>Brian F. G.
    Bidulock</FONT> </P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFD3F1.B5D34366--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jun 11 18:24:07 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09882
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 11 Jun 2000 18:10:35 -0400 (EDT)
Received: from standards (47.234.32.16:3269) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74C4D@standards.nortelnetworks.com>; 11 Jun 2000 18:01:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2848 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 11 Jun 2000 18:01:28 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB74C4C@standards.nortelnetworks.com>; 11 Jun 2000 18:01:27 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id SAA23652; Sun, 11 Jun 2000 18:10:03 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id SAA00010; Sun, 11 Jun 2000 18:10:04 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <MR1YP61H>; Sun, 11 Jun 2000 18:10:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CFC994AD@whq-msgusr-02.fore.com>
Date:         Sun, 11 Jun 2000 18:10:03 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: MID Clarification
X-To:         Bharat Kaul <bharat@trillium.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It should be consistent, and it should be the source port.
Implementations may need to consider rogue entities who spoof!

Brian

> -----Original Message-----
> From: Bharat Kaul [mailto:bharat@trillium.com]
> Sent: Thursday, June 08, 2000 9:05 PM
> To: Rosen, Brian
> Subject: MID Clarification
>
>
>
> Hi Brian,
>
> I have a doubt concerning the usage of "MID" in the protocol.
>  In a IP V4
> network, Mid has been is (IP address/domain name) and an optional port
> number.
>
> My doubt is that since the port number is specified as optional, is an
> entity originating a message "ALLOWED" to specify port in MID in some
> messages and skip in some by the protocol ?
>
> Or does protocol require the originating entity to maintain a
> consistent MID
> in all messages i.e. always use same MID across all messages
> (even in cases
> where multiple connections/sockets are being used) ?
>
> On a similar note,  does the port number in MID indicate the
> source port
> from which message was transmitted or does it have any other
> significance ?
>
> - thanks
>   Bharat
>
>
>
> --------------------------------------------------------------
> --------------
> -----------
> Bharat Kaul;                                      Trillium
> Digital Systems
> Inc.
> mailto:bharat@trillium.com          12100 Wilshire Blvd,
> Phone: +1-310-442-9222                Los Angeles, CA - 90025.
> Fax:     +1-310-442-1162                  http://www.trillium.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 12 00:54:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14084
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 12 Jun 2000 00:54:18 -0400 (EDT)
Received: from standards (47.234.32.16:3308) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74CDF@standards.nortelnetworks.com>; Mon, 12 Jun 2000 0:44:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3035 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 12 Jun 2000 00:44:56 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB74CDA@standards.nortelnetworks.com>; Mon, 12 Jun 2000 0:34:41
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          XAA23391 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 11 Jun 2000
          23:41:32 -0500 (CDT)
Received: from <chak@axes-mach01.dsccc.com> (relay1.usa.alcatel.com
          [143.209.238.6]) by fw7 via smap (V2.1) id xma023357; Sun, 11 Jun 00
          23:41:24 -0500
Received: from multi2.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id XAA26839 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 11 Jun 2000 23:43:37
          -0500 (CDT)
Received: from axes-mach01.axes-mach01.usa.alcatel.com
          (axes-mach01.usa.alcatel.com [130.202.9.90]) by
          multi2.usa.alcatel.com (8.8.8+Sun/8.8.8) with SMTP id XAA15435 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 11 Jun 2000 23:42:06
          -0500 (CDT)
Received: from chak by axes-mach01.axes-mach01.usa.alcatel.com
          (SMI-8.6/SMI-SVR4) id KAA10484; Mon, 12 Jun 2000 10:13:11 -0500
References: <4FBEA8857476D311A03300204840E1CFC9940A@whq-msgusr-02.fore.com>    
            <3940E45C.B69BB7A9@americasm01.nt.com> 
            <14657.5100.347647.998883@thomasm-u1.cisco.com>
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 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <001c01bfd428$aaa23240$1d09ca82@chak>
Date:         Mon, 12 Jun 2000 10:12:49 +0530
Reply-To: Chakravarthi PSK <chak@AXES-MACH01.DSCCC.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chakravarthi PSK <chak@AXES-MACH01.DSCCC.COM>
Subject:      Hairpin connection
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello,

    How MGC can instruct MG to establish connection between two terminations
existing on same MG?

    In MGCP we can send second end point to inform MG that a hairpin
connection is required between the two end points.

    How does MEGACO support this?

    Is it by sending two TDM trunks in the same transaction without any
media descriptor?

Thanks
Chak


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 12 08:23:18 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29716
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 12 Jun 2000 08:23:18 -0400 (EDT)
Received: from standards (47.234.32.16:1460) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74DB8@standards.nortelnetworks.com>; Mon, 12 Jun 2000 8:13:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3324 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 12 Jun 2000 08:13:52 -0400
Received: from qhars002.nortel.com (47.101.112.102:34174) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB74DB7@standards.nortelnetworks.com>; Mon, 12 Jun 2000
          8:13:52 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Mon, 12 Jun 2000 13:21:26 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Mon, 12 Jun 2000 07:20:33 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPD141S8>; Mon, 12 Jun 2000 07:20:11 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480A7B@zcard00g.ca.nortel.com>
Date:         Mon, 12 Jun 2000 07:20:11 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Hairpin connection
X-To:         Chakravarthi PSK <chak@AXES-MACH01.DSCCC.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Even TDM trunks require media descriptors, if for no other reason than to
indicate Mode and medium.  Annex C shows a pile of other properties which
may be specified.  I view Annex C as an agenda for us to augment SDP to
match, as we have discussed in other threads.

In any event, TDM to TDM operation is nothing special in Megaco/H.248 -- you
just place two TDM terminations in the same context.

> -----Original Message-----
> From: Chakravarthi PSK [SMTP:chak@AXES-MACH01.DSCCC.COM]
> Sent: Monday, June 12, 2000 12:43 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Hairpin connection
>
> Hello,
>
>     How MGC can instruct MG to establish connection between two
> terminations
> existing on same MG?
>
>     In MGCP we can send second end point to inform MG that a hairpin
> connection is required between the two end points.
>
>     How does MEGACO support this?
>
>     Is it by sending two TDM trunks in the same transaction without any
> media descriptor?
>
> Thanks
> Chak


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 12 11:00:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03404
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 12 Jun 2000 11:00:19 -0400 (EDT)
Received: from standards (47.234.32.16:3234) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74E2D@standards.nortelnetworks.com>; Mon, 12 Jun 2000 10:50:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3491 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 12 Jun 2000 10:50:57 -0400
Received: from qhars002.nortel.com (47.101.112.102:51321) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB74E2C@standards.nortelnetworks.com>; Mon, 12 Jun 2000
          10:50:57 -0400
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          qhars002.nortel.com; Mon, 12 Jun 2000 15:59:01 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Mon, 12 Jun 2000 10:57:03 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPQCXDDS>; Mon, 12 Jun 2000 10:57:02 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480A80@zcard00g.ca.nortel.com>
Date:         Mon, 12 Jun 2000 10:56:57 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Test profile As Megaco Work Item?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Brian Rosen is working on an I-D detailing a proposed test profile for the
interoperability event.  Would it be proper to make this an official WG
document, with ultimate objective to create an i-RFC?

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 12 11:24:35 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04135
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 12 Jun 2000 11:24:34 -0400 (EDT)
Received: from standards (47.234.32.16:3234) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74E48@standards.nortelnetworks.com>; Mon, 12 Jun 2000 11:15:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3525 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 12 Jun 2000 11:15:13 -0400
Received: from bfgbhome.inetint.com (tnt-dal-42-242.dallas.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB74E47@standards.nortelnetworks.com>; Mon, 12 Jun 2000
          11:15:02 -0400
Received: (from bfb@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id
          KAA26124; Mon, 12 Jun 2000 10:22:30 -0500
Mail-Followup-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>,
                  MEGACO@STANDARDS.NORTELNETWORKS.COM
References: <28560036253BD41191A10000F8BCBD11480A80@zcard00g.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
X-Operating-System: Linux bfgbhome 2.2.14-5.0
Dsn-Notification-To: <brian.bidulock@inet.com>
Precedence: special-delivery
X-Sensitivity: Confidential
X-Importance: High
X-Priority: 1 (highest)
Message-ID:  <20000612102229.B25987@inet.com>
Date:         Mon, 12 Jun 2000 10:22:29 -0500
Reply-To: brian.bidulock@inet.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Brian F. G. Bidulock" <brian.bidulock@inet.com>
Organization: Inet Technologies, Inc.
Subject:      Re: Test profile As Megaco Work Item?
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <28560036253BD41191A10000F8BCBD11480A80@zcard00g.ca.nortel.com>;
              from taylor@NORTELNETWORKS.COM on Mon, Jun 12,
              2000 at 10:56:57AM -0400

Tom-PT,

On Mon, 12 Jun 2000, Tom-PT Taylor wrote:
> Brian Rosen is working on an I-D detailing a proposed test profile for the
> interoperability event.  Would it be proper to make this an official WG
> document, with ultimate objective to create an i-RFC?

Mmmmmmmmm!

--
Brian F. G. Bidulock
Director GeoGate SW Development
Network Products, Inet Technologies Inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 12 11:51:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04944
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 12 Jun 2000 11:51:37 -0400 (EDT)
Received: from standards (47.234.32.16:2111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74E5F@standards.nortelnetworks.com>; Mon, 12 Jun 2000 11:42:24 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3552 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 12 Jun 2000 11:42:24 -0400
Received: from ns-inetext.inet.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB74E5E@standards.nortelnetworks.com>; Mon, 12 Jun 2000 11:42:23
          -0400
Received: from harpo.inetint.com (harpo [172.16.99.60]) by ns-inetext.inet.com
          (8.9.2/8.9.2) with ESMTP id KAA09639 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 12 Jun 2000 10:49:57
          -0500 (CDT)
Received: from inet.com ([172.16.63.49]) by harpo.inetint.com (Netscape
          Messaging Server 3.6)  with ESMTP id AAA6AC6; Mon, 12 Jun 2000
          10:56:08 -0500
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480A80@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <394506B5.215EB568@inet.com>
Date:         Mon, 12 Jun 2000 10:50:13 -0500
Reply-To: Mart Nurmet <mart.nurmet@INET.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Mart Nurmet <mart.nurmet@INET.COM>
Organization: Inet - Staff Engineer
Subject:      Re: Test profile As Megaco Work Item?
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

To all:

Would we not want to expand that past the Interoperability event for the
informational RFC?

-Mart

Tom-PT Taylor wrote:

> Brian Rosen is working on an I-D detailing a proposed test profile for the
> interoperability event.  Would it be proper to make this an official WG
> document, with ultimate objective to create an i-RFC?
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 12 14:15:29 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08389
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 12 Jun 2000 14:15:29 -0400 (EDT)
Received: from standards (47.234.32.16:1926) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74EDD@standards.nortelnetworks.com>; Mon, 12 Jun 2000 14:06:17 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3711 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 12 Jun 2000 14:06:17 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB74EDC@standards.nortelnetworks.com>; Mon, 12 Jun 2000 13:56:16
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id OAA13453 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 12
          Jun 2000 14:04:56 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id OAA10391 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 12
          Jun 2000 14:04:56 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <MR1YQ363>; Mon, 12 Jun 2000 14:04:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <9523A991F7AED311A8B900508B6701F4178D22@dl-msgusr-01.eu.fore.com>
Date:         Mon, 12 Jun 2000 11:32:03 -0400
Reply-To: "flynn, martin" <Martin.Flynn@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "flynn, martin" <Martin.Flynn@MARCONI.COM>
Subject:      Re: MID Clarification
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Brian,

How does this match up with the example in Appendix A (F?) of the spec.?
The MG first registers as [124.124.124.222] but then calls itself
[124.124.124.222]:55555.

Martin

-----Original Message-----
From: Rosen, Brian
Sent: Sunday, June 11, 2000 11:10 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: MID Clarification


It should be consistent, and it should be the source port.
Implementations may need to consider rogue entities who spoof!

Brian

> -----Original Message-----
> From: Bharat Kaul [mailto:bharat@trillium.com]
> Sent: Thursday, June 08, 2000 9:05 PM
> To: Rosen, Brian
> Subject: MID Clarification
>
>
>
> Hi Brian,
>
> I have a doubt concerning the usage of "MID" in the protocol.
>  In a IP V4
> network, Mid has been is (IP address/domain name) and an optional port
> number.
>
> My doubt is that since the port number is specified as optional, is an
> entity originating a message "ALLOWED" to specify port in MID in some
> messages and skip in some by the protocol ?
>
> Or does protocol require the originating entity to maintain a
> consistent MID
> in all messages i.e. always use same MID across all messages
> (even in cases
> where multiple connections/sockets are being used) ?
>
> On a similar note,  does the port number in MID indicate the
> source port
> from which message was transmitted or does it have any other
> significance ?
>
> - thanks
>   Bharat
>
>
>
> --------------------------------------------------------------
> --------------
> -----------
> Bharat Kaul;                                      Trillium
> Digital Systems
> Inc.
> mailto:bharat@trillium.com          12100 Wilshire Blvd,
> Phone: +1-310-442-9222                Los Angeles, CA - 90025.
> Fax:     +1-310-442-1162                  http://www.trillium.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 12 17:02:31 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11216
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 12 Jun 2000 17:02:31 -0400 (EDT)
Received: from standards (47.234.32.16:4170) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74F3C@standards.nortelnetworks.com>; Mon, 12 Jun 2000 16:53:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3828 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 12 Jun 2000 16:53:11 -0400
Received: from wellington.cnchost.com (wellington.concentric.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB74F3B@standards.nortelnetworks.com>; Mon, 12 Jun 2000
          16:53:10 -0400
Received: from MATT.ascend.com (w066.z208037018.sjc-ca.dsl.cnc.net
          [208.37.18.66]) by wellington.cnchost.com id RAA16108; Mon, 12 Jun
          2000 17:01:48 -0400 (EDT) [ConcentricHost SMTP Relay 1.8]
Errors-To: <matt@ipverse.com>
X-Sender: matt@ipverse.com@pop3.ipverse.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.3.1.2.20000612140212.00bd5240@pop3.ipverse.com>
Date:         Mon, 12 Jun 2000 14:05:46 -0700
Reply-To: Matt Holdrege <matt@ipverse.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Matt Holdrege <matt@ipverse.com>
Subject:      Re: Test profile As Megaco Work Item?
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <28560036253BD41191A10000F8BCBD11480A80@zcard00g.ca.nortel. com>

At 10:56 AM 6/12/00 -0400, Tom-PT Taylor wrote:
>Brian Rosen is working on an I-D detailing a proposed test profile for the
>interoperability event.  Would it be proper to make this an official WG
>document, with ultimate objective to create an i-RFC?

1. You can't ask us to approve an I-D til we see it, right?

2. Profile's are not necessarily from the MEGACO WG. They can come from
other sources such as the MSF, right?

3. I don't think we want the creation of a "test" RFC as an objective.
RFC's are long lived and I don't think a test document fits that class.

That said, I hope Brian publishes his document somehow as it could be quite
useful in the near term.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 13 03:25:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00251
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 13 Jun 2000 03:25:15 -0400 (EDT)
Received: from standards (47.234.32.16:1886) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75010@standards.nortelnetworks.com>; Tue, 13 Jun 2000 3:15:39 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4099 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 03:15:39 -0400
Received: from mailcity.com (209.1.236.7:52020) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB7500F@standards.nortelnetworks.com>; Tue, 13 Jun 2000 3:15:39
          -0400
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Tue Jun 13 00:24:02
          2000
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
X-Sender-Ip: 216.6.88.34
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Message-ID:  <HOGBJJFAMAMIBAAA@mailcity.com>
Date:         Tue, 13 Jun 2000 00:24:02 -0700
Reply-To: hussainmf@mailcity.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hussain F Mohammad <hussainmf@mailcity.com>
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Subject:      Re: Jitter Buffer
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Were there any responses for this mail?

--

On Fri, 9 Jun 2000 10:20:05
 Madhu Babu wrote:
>Resending, as the earlier one was without any subject.
>
>
>What is the significance of adding the Jitter Buffer in Network package?
>Network package is extended by both RTP package and TDM package,
>which are supported by ephemeral and physical termination, respectively.
>Does this mean that jitter buffer shall be implemented by both physical
>termination and ephemeral termination ?
>This property certainly seems redundant for one type of termination.
>
>-Madhubabu
>


Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 13 15:31:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19984
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 13 Jun 2000 15:31:32 -0400 (EDT)
Received: from standards (47.234.32.16:4495) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75453@standards.nortelnetworks.com>; Tue, 13 Jun 2000 15:22:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1036 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 15:22:10 -0400
Received: from turin.trillium.com (206.216.108.218:1509) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB75452@standards.nortelnetworks.com>; Tue, 13 Jun 2000
          15:22:10 -0400
Received: from aiglos.trillium.com (unverified) by turin.trillium.com (Content
          Technologies SMTPRS 4.1.5) with ESMTP id
          <Tced86cda674cc6862e2a@turin.trillium.com>; Tue, 13 Jun 2000 12:43:16
          -0700
Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by
          aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id MAA05425; Tue, 13 Jun
          2000 12:30:32 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <MVL8V3TN>; Tue, 13 Jun 2000 12:28:31 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5D9FB25C@aega.trillium.com>
Date:         Tue, 13 Jun 2000 12:28:25 -0700
Reply-To: Bharat Kaul <bharat@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Bharat Kaul <bharat@TRILLIUM.COM>
Subject:      Re: MID Clarification
X-To:         "flynn, martin" <Martin.Flynn@MARCONI.COM>
X-cc:         "brian.rosen@marconi.com" <brian.rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I am more concerned about this due to virtual MG's. A MGC controlling a set
of virtual MG's should have a unique way of distinguishing each one of them
and source port is one of the ways of doing so. Am wondering if protocol
requires virtual MG's over a single interface to have different source port
number always as part of MID or are there other mechanisms to help MGC
identify the source entity correctly ?

However, one problem I see with MID being consistent is that, for example,
on MG side using a TCP connection to MGC, my connection can go down locally.
Once MG re-establishes connection and sends a Service Change message again
indicating communication is restored, its source port may no longer be the
same. So MID cannot really be required to be consistent. And this further
complicates life with virtual MG's.

Any comments or clarifications are appreciated.

- Bharat


-----Original Message-----
From: flynn, martin [mailto:Martin.Flynn@MARCONI.COM]
Sent: Monday, June 12, 2000 8:32 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: MID Clarification


Hi Brian,

How does this match up with the example in Appendix A (F?) of the spec.?
The MG first registers as [124.124.124.222] but then calls itself
[124.124.124.222]:55555.

Martin

-----Original Message-----
From: Rosen, Brian
Sent: Sunday, June 11, 2000 11:10 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: MID Clarification


It should be consistent, and it should be the source port.
Implementations may need to consider rogue entities who spoof!

Brian

> -----Original Message-----
> From: Bharat Kaul [mailto:bharat@trillium.com]
> Sent: Thursday, June 08, 2000 9:05 PM
> To: Rosen, Brian
> Subject: MID Clarification
>
>
>
> Hi Brian,
>
> I have a doubt concerning the usage of "MID" in the protocol.
>  In a IP V4
> network, Mid has been is (IP address/domain name) and an optional port
> number.
>
> My doubt is that since the port number is specified as optional, is an
> entity originating a message "ALLOWED" to specify port in MID in some
> messages and skip in some by the protocol ?
>
> Or does protocol require the originating entity to maintain a
> consistent MID
> in all messages i.e. always use same MID across all messages
> (even in cases
> where multiple connections/sockets are being used) ?
>
> On a similar note,  does the port number in MID indicate the
> source port
> from which message was transmitted or does it have any other
> significance ?
>
> - thanks
>   Bharat
>
>
>
> --------------------------------------------------------------
> --------------
> -----------
> Bharat Kaul;                                      Trillium
> Digital Systems
> Inc.
> mailto:bharat@trillium.com          12100 Wilshire Blvd,
> Phone: +1-310-442-9222                Los Angeles, CA - 90025.
> Fax:     +1-310-442-1162                  http://www.trillium.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 14 04:19:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14167
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 14 Jun 2000 04:19:18 -0400 (EDT)
Received: from standards (47.234.32.16:1727) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB756AC@standards.nortelnetworks.com>; Wed, 14 Jun 2000 4:09:36 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1834 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 14 Jun 2000 04:09:36 -0400
Received: from standards (47.234.32.16:1727) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB756A7@standards.nortelnetworks.com>; Wed, 14 Jun 2000 3:59:36
          -0400
Message-ID:  <MEGACO%2000061404093623@STANDARDS.NORTELNETWORKS.COM>
Date:         Wed, 14 Jun 2000 03:59:36 -0400
Reply-To: test <gritsi_gr@YAHOO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: test <gritsi_gr@YAHOO.COM>
Subject:      test
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

test


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 14 04:37:46 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14300
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 14 Jun 2000 04:37:45 -0400 (EDT)
Received: from standards (47.234.32.16:3092) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB756C3@standards.nortelnetworks.com>; Wed, 14 Jun 2000 4:28:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1871 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 14 Jun 2000 04:28:19 -0400
Received: from standards (47.234.32.16:3092) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB756C2@standards.nortelnetworks.com>; Wed, 14 Jun 2000 4:28:19
          -0400
Message-ID:  <MEGACO%2000061404281996@STANDARDS.NORTELNETWORKS.COM>
Date:         Wed, 14 Jun 2000 04:28:19 -0400
Reply-To: Giannis Ritsioudis <gritsi_gr@YAHOO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Giannis Ritsioudis <gritsi_gr@YAHOO.COM>
Subject:      ServiceChangeAddress
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I implement this protocol in C++ and I have this problem concerning
ServiceChangeAddress.

Well, I understand the format that ServiceChangeAddress has in ASN 1
syntax,  but I do not
understand the format that has in ABNF ( ServiceChangeAddressToken EQUAL
VALUE)
What is the relationship between VALUE and the format in ASN 1 syntax ?

Giannis


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 14 07:28:09 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15634
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 14 Jun 2000 07:28:08 -0400 (EDT)
Received: from standards (47.234.32.16:4946) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75770@standards.nortelnetworks.com>; Wed, 14 Jun 2000 7:18:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2055 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 14 Jun 2000 07:18:35 -0400
Received: from ficon-tech.com (12.10.198.190:3766) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7575D@standards.nortelnetworks.com>; Wed, 14 Jun 2000
          7:08:30 -0400
Received: from globespan.net (skgupta.india.ficon-tech.com [172.25.1.109]) by
          ficon-tech.com (8.9.3/8.9.3) with ESMTP id PAA48488; Wed, 14 Jun 2000
          15:18:58 +0530 (IST) (envelope-from skgupta@globespan.net)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3947553F.C2BF2DC5@globespan.net>
Date:         Wed, 14 Jun 2000 15:19:52 +0530
Reply-To: "Sanjay Kr. Gupta" <skgupta@GLOBESPAN.NET>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Sanjay Kr. Gupta" <skgupta@GLOBESPAN.NET>
Organization: GlobeSpan Inc.
Subject:      change of e-mail address
X-To:         Abhishek Goyal <abhishek_goel@bet.satyam.com>,
              aditya chugh <aditya@npi.stpn.soft.net>,
              "Agrawal, Anurag" <Anurag.Agrawal@Bestbuy.com>,
              Ajay Nagpal <nagpal_ajay@hotmail.com>,
              Amal Nandan Prasad <anprasad@noida.hclt.com>,
              Aman Gulati <aman@qcominc.com>,
              Aman Kochher <aman.kochher@saint-gobain.co.in>,
              amit aggarwal <agarwalamit@usa.net>,
              Amitabh Rai <Amitabh_Rai@prnewswire.com>,
              Anil Sinha <a_sinha@www.com>,
              Anurag Batta <anurag_batta@hotmail.com>,
              Arun Singhal <aruns@inf.com>,
              Arun Singhal <arunsing@nortelnetworks.com>,
              Ashish Arora <ashish.arora@tatainfotech.com>,
              Ashish Garg <akgarg@mercury.noida.hclt.com>,
              Ashish Kumar <ashishkr@usa.net>,
              Ashish Kumar <ashkumar@nortelnetworks.com>,
              Atul Arora <atul.arora@tatainfotech.com>,
              Atul Mukker <amukker@hotmail.com>,
              Avinash Sohal <Avinash.Sohal@geind.ge.com>,
              Avinash Sohal <Sohalavi@hotbot.com>,
              bijender sangwan <bijenders@getafix.infogain.com>,
              bijender sangwan <bsangwan@hotmail.com>,
              Deepak Biswas <dipakb@future.futsoft.com>,
              deepti jerath <deepti.jerath@tatainfotech.com>,
              Dilip Nanecha <nanecha@mailcity.com>,
              Dipanjan Purkayastha <dipanjan@caltiger.net.in>,
              dipanka sarmah <dipu@cdotb.ernet.in>,
              Divakar Shukla <diwakar_shukla@hotmail.com>,
              Divakar Shukla <d_shukla@engineer.com>,
              Sachin Jindal <sjindal@hss.hns.com>,
              Manoj Verma <mmanoj_vverma@hotmail.com>,
              Jitender Gupta <guptajitender@hotmail.com>,
              sunil madan <sunil_madan@intersolutions.stpn.soft.net>,
              Gagan Khatri <f98speed@fmsdu.ernet.in>,
              Gaurav Kamboj <gaurav.kamboj@tatainfotech.com>,
              Gurpreet Sachdeva <gurpreets@delhi.tcs.co.in>,
              I C Garg <iawrqats@vsnl.com>, I C Garg <saha@bom3.vsnl.net.in>,
              InderJit Singh <singhinderjit@hotmail.com>,
              Inderjit Singh <inderjits@mtcindia.com>,
              Jatin Mahendroo <janinfy@yahoo.com>,
              jatin mahendru <mahendrujatin@hotmail.com>,
              Jitender Chabra <jitender@reck.ernet.in>,
              Jitender Gupta <jitender@england.com>,
              Jitender Gupta <guptajitender@hotmail.com>,
              jyotsana dhawan <jdhawan@netacross.com>,
              "K.C. Ramakrishna" <kcramakrishna@yahoo.com>,
              kamal kakkar <kamal@aplion.stpn.soft.net>,
              Kamal Sharma <kamals@noida.hclt.com>,
              "Kamboj, Gaurav" <Gaurav.Kamboj@nike.com>,
              Kaptan Singh <kmehra@cdotp.ernet.in>,
              Karan Goel <karangoel@yahoo.com>,
              KCRAMAKRISHNA <KCRAMAKRISHNA@inf.com>,
              kirti Dua <kirtidua98@hotmail.com>,
              kumar ashish <kashduhan@netscape.net>,
              Lalit Jain <jain_lalit@hotmail.com>,
              Lalit Jain <Lalit.Jain@gecapital.com>,
              Lalit Mohan Deepak <lmdeepak@yahoo.com>,
              "Longia, Mohan (DAT)" <mlongia@NA2.US.ML.com>,
              Mahesh Garg <gargmahesh@usa.net>, Maiti <maiti75@hotmail.com>,
              manish garg <msg-c&ap@asc.ltindia.com>,
              Manish Handa <mhanda@ececs.uc.edu>,
              manish kheterpal <kmani13@hotmail.com>,
              "Manitosh Kaushik (E-mail)" <Manitosh.Kaushik@metamorgs.com>,
              manoj sharma <mauji@yahoo.com>, manoj sharma <manoj@basit.com>,
              Manoj Verma <mmanoj_vverma@hotmail.com>,
              Manoj Verma <manojv@solutionsny.com>,
              Manpreet Singh <ampraj@hotmail.com>,
              Mohan Longia <mlongia@NA2.US.ML.com>,
              Mohit Gupta <Mohit.gupta@motorola.com>,
              mohit kumar <mohitbhutani@usa.net>,
              mollars <mollars@egroups.com>,
              Mrityunjoy Ghosh <mitu_org@hotmail.com>,
              Mukesh Punhani <mpunhani@hotmail.com>,
              Munish Bansal <munishb@microsoft.com>,
              Navin Samuel <nsamuel@att.com>,
              Navin Samuel <navinsamuel@hotmail.com>,
              neeraj gaur <ngaur@hss.hns.com>,
              Neerav Aggarwal <aggrawan@geodc.patni.com>,
              Neetu Gupta <neetu.gupta@jci.com>,
              Neetu Gupta <neetug@yahoo.com>,
              nilesh maheshwari <nileshm12@hotmail.com>,
              Nitin Chawla <nitin_ch@excite.com>,
              Nitin Chawla <nitinc@lucent.com>,
              Nitin Dhingra <n_dhingra@hotmail.com>,
              Pankaj Bansal <pankaj.k@PARSEC.CO.IN>,
              Pankaj Bansal <the_piscean@usa.net>,
              Pankaj Garg <pgarg@hss.hns.com>,
              Pankaj Sharma <sharma_pank@yahoo.com>,
              Pawan Garg <PAWANg@interra.com>, Pawan Garg <PawanG@interra.com>,
              piyush goyal <piyushg@delhi.tcs.co.in>,
              Poonam Bhatla <poonam@dcmds.co.in>,
              Praney Mittal <praneym@hotmail.com>,
              Praney Mittal <praneym@delhi.tcs.co.in>,
              Prashant Dube <pdee@hotmail.com>,
              Prashant Dube <Prashant.Dube@fairchildsemi.com>,
              Prashant Jain <jainp@Catamarancom.com>,
              Prodyot Biswas <prodyotb@pune.tcs.co.in>,
              Puneet Narang <puneet_n@hotmail.com>,
              Puneet Narang <puneetn@iscc.net>,
              Qamar Zaman <qamarz@wipsys.soft.net>,
              Rahul Raina <rahul.raina@dcmds.co.in>,
              Raj Mohan <rajmohan@giasbg01.vsnl.net.in>,
              rohini juneja <rohini_juneja@i2.com>,
              rohit gupta <rohit_kgupta@yahoo.com>,
              rohit gupta <rohit.gupta@eng.sun.com>,
              Rohit Raina <rohitr@microsoft.com>,
              Manoj Verma <mmanoj_vverma@hotmail.com>,
              Jitender Gupta <guptajitender@hotmail.com>,
              sunil madan <sunil_madan@intersolutions.stpn.soft.net>,
              Sachin Garg <sachin@npi.stpn.soft.net>,
              Sachin Jindal <sjindal@hss.hns.com>,
              Sandeep Kumar <sandeep.kumar@gepex.ge.com>,
              saradindu ghosh <sandy_idesigner@hotmail.com>,
              sarvesh kakar <kakarsarvesh@usa.net>,
              sarvesh kumar <sarvesh_kumar@indianoil.co.in>,
              seema kakar <seemakakar@hotmail.com>,
              SHASHI bhushan <s_bhushan@mailcity.com>,
              shekhar dahiya <shekhardahiya@inf.com>,
              Shikhar Sarkar <shikhar@grex.cyberspace.org>,
              Sudarshan Dhingra <sk_dhingra@hotmail.com>,
              sunil madan <sunil_madan@intersolutions.stpn.soft.net>,
              Suparna Taneja <staneja@hss.hns.com>,
              Surbhi Singh <nizam@reck.ernet.in>,
              The great '93 batch of RECKers <reck@egroups.com>,
              Tushar Dave <dave.tushar@bellatlantic.com>,
              Vibhoosh Gupta <vibhoosh@dcmds.co.in>,
              Vikas Aggarwal <aggarwal_v@hotmail.com>,
              vikas bansal <vikasb@iimidr.ernet.in>,
              vikas junthra <vikas1003@hotmail.com>,
              Vikas Sood <visood@hss.hns.com>,
              Vineet Kumar Arora <Vineetk@talisma.com>,
              Anjana Sharma <anj_sharma@hotmail.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

HI All,
    Please change my e-mail address in ur address books to
            skgupta@globespan.net

Thanks and Regards,
Sanjay

--
Sanjay Kr. Gupta
GlobeSpan Inc.
email: mailto:skgupta@globespan.net
web: http://www.globespan.net


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 14 11:36:34 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25440
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 14 Jun 2000 11:36:34 -0400 (EDT)
Received: from standards (47.234.32.16:1773) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75848@standards.nortelnetworks.com>; Wed, 14 Jun 2000 11:26:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2361 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 14 Jun 2000 11:26:55 -0400
Received: from gateway.assuredaccess.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB75847@standards.nortelnetworks.com>; Wed, 14 Jun 2000 11:26:54
          -0400
Received: from nonki.assuredaccess.com ([10.193.101.111]) by
          gateway.assuredaccess.com (Netscape Mail Server v2.0) with SMTP id
          AAA105 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 14 Jun 2000
          08:37:52 -0700
Message-ID:  <20000614153751328.AAA105@nonki.assuredaccess.com>
Date:         Wed, 14 Jun 2000 08:37:52 -0700
Reply-To: Jeff Enderwick <jeff@ASSUREDACCESS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Jeff Enderwick <jeff@ASSUREDACCESS.COM>
Subject:      list mgmt subject
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'm on some other lists where a brief set
of admin howtos is pasted to the tail of
each list email. It seems to pretty much
eliminate the occasional unsubsribe and
other admin mail from being sent to the
entire list. Maybe the list owner could
add this?

my $.02

Jeff


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 14 12:01:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26131
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 14 Jun 2000 12:01:02 -0400 (EDT)
Received: from standards (47.234.32.16:3362) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7586E@standards.nortelnetworks.com>; Wed, 14 Jun 2000 11:51:34 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2407 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 14 Jun 2000 11:51:34 -0400
Received: from ctsincsisxia.DBSS.COM (202.54.64.137:2166) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7586D@standards.nortelnetworks.com>; Wed, 14 Jun 2000
          11:51:32 -0400
Received: from 162.44.9.80 by ctsincsisxia.DBSS.COM (InterScan E-Mail VirusWall
          NT); Wed, 14 Jun 2000 18:07:37 +0530
Received: from rnd.cts-corp.com (206.136.109.204 [206.136.109.204]) by
          ctsincsisxic.cts-corp.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2448.0) id M7RY6NVL; Wed, 14 Jun 2000 18:16:15
          +0530
Received: from 9a4-gnd ([206.136.109.229]) by rnd.cts-corp.com (8.9.3/8.8.7)
          with SMTP id SAA28542; Wed, 14 Jun 2000 18:18:13 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_010D_01BFD62C.96C43790"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Message-ID:  <011001bfd656$7fa1e0b0$e56d88ce@9a4-gnd>
Date:         Wed, 14 Jun 2000 18:15:58 -0500
Reply-To: Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
Subject:      Stream Mode
X-To:         taylor@nortelnetworks.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_010D_01BFD62C.96C43790
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

What is the default value of the Stream Mode? I could not find it in the =
draft.

Media descriptor
    Local Control Descriptor
        Stream Descriptor
            Stream Mode
Thank-you.
Regards,
Sameer

------=_NextPart_000_010D_01BFD62C.96C43790
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3612.1706"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hello,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>What is the default value of the =
Stream Mode? I=20
could not find it in the draft.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Media descriptor</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; Local Control=20
Descriptor</FONT></DIV>
<DIV><FONT color=3D#000000 =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Stream Descriptor</FONT></DIV>
<DIV><FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; Stream=20
Mode</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Thank-you.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Regards,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Sameer</FONT></DIV></BODY></HTML>

------=_NextPart_000_010D_01BFD62C.96C43790--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 14 12:09:08 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26516
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 14 Jun 2000 12:09:07 -0400 (EDT)
Received: from standards (47.234.32.16:3362) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75887@standards.nortelnetworks.com>; Wed, 14 Jun 2000 11:59:46 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2400 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 14 Jun 2000 11:59:46 -0400
Received: from bfgbhome.inetint.com (tnt-dal-42-204.dallas.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB75867@standards.nortelnetworks.com>; Wed, 14 Jun 2000
          11:49:45 -0400
Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id
          KAA03601; Wed, 14 Jun 2000 10:58:24 -0500
Mail-Followup-To: Jeff Enderwick <jeff@ASSUREDACCESS.COM>,
                  MEGACO@STANDARDS.NORTELNETWORKS.COM
References: <20000614153751328.AAA105@nonki.assuredaccess.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2i
X-Operating-System: Linux bfgbhome 2.2.14-5.0
Dsn-Notification-To: <bidulock@dallas.net>
Precedence: special-delivery
X-Sensitivity: Confidential
X-Importance: High
X-Priority: 1 (highest)
Message-ID:  <20000614105824.A410@dallas.net>
Date:         Wed, 14 Jun 2000 10:58:24 -0500
Reply-To: bidulock@dallas.net
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Brian F. G. Bidulock" <bidulock@dallas.net>
Organization: Brian F. G. Bidulock, P. Eng.
Subject:      Re: list mgmt subject
X-To:         Jeff Enderwick <jeff@ASSUREDACCESS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <20000614153751328.AAA105@nonki.assuredaccess.com>; from
              jeff@ASSUREDACCESS.COM on Wed, Jun 14, 2000 at 08:37:52AM -0700
Content-Transfer-Encoding: 8bit

Jeff,

A simple

    List-Archive: <ftp://ftp.ietf.org/ietf-mail-archives/megaco/>
    List-Help: <mailto:blahblah@somewhere.com?body=help>
    List-Unsubscribe: <mailto:blahblah@somewhere.com?body=unsubscribe>

attached to the mail headers might suffice.  Netscape users could even show
headers and then just click on the thing they want...

Jeff Enderwick wrote:                         (Wed, 14 Jun 2000 08:37:52)
> I'm on some other lists where a brief set
> of admin howtos is pasted to the tail of
> each list email. It seems to pretty much
> eliminate the occasional unsubsribe and
> other admin mail from being sent to the
> entire list. Maybe the list owner could
> add this?
>
> my $.02
>
> Jeff

--
Brian F. G. Bidulock   ¦ The reasonable man adapts himself to the ¦
bidulock@dallas.net    ¦ world; the unreasonable one persists in  ¦
                       ¦ trying  to adapt the  world  to himself. ¦
                       ¦ Therefore  all  progress  depends on the ¦
M.O.A.M.O.N.N.T.O.M.E. ¦ unreasonable man. -- George Bernard Shaw ¦


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 14 12:11:53 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26639
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 14 Jun 2000 12:11:52 -0400 (EDT)
Received: from standards (47.234.32.16:3362) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75894@standards.nortelnetworks.com>; Wed, 14 Jun 2000 12:01:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2406 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 14 Jun 2000 12:01:31 -0400
Received: from rambo.globespan.net (p1.globespan.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7586C@standards.nortelnetworks.com>; Wed, 14 Jun 2000
          11:51:30 -0400
Received: by rambo.globespan.net with Internet Mail Service (5.5.2650.21) id
          <M8JFXQZ1>; Wed, 14 Jun 2000 11:58:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFD619.6A0A4E50"
Message-ID:  <4D0A8ECBDC8AD211BD0900A0C9EBC13301CCDD39@rambo.globespan.net>
Date:         Wed, 14 Jun 2000 11:58:41 -0400
Reply-To: mollars@egroups.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Helpdesk MIS <AdminLogs@GLOBESPAN.NET>
Subject:      [mollars] change of e-mail address
X-To:         Abhishek Goyal <abhishek_goel@bet.satyam.com>,
              aditya chugh <aditya@npi.stpn.soft.net>,
              "Agrawal, Anurag" <Anurag.Agrawal@Bestbuy.com>,
              Ajay Nagpal <nagpal_ajay@hotmail.com>,
              Amal Nandan Prasad <anprasad@noida.hclt.com>,
              Aman Gulati <aman@qcominc.com>,
              Aman Kochher <aman.kochher@saint-gobain.co.in>,
              amit aggarwal <agarwalamit@usa.net>,
              Amitabh Rai <Amitabh_Rai@prnewswire.com>,
              Anil Sinha <a_sinha@www.com>,
              Anurag Batta <anurag_batta@hotmail.com>,
              Arun Singhal <aruns@inf.com>,
              Arun Singhal <arunsing@nortelnetworks.com>,
              Ashish Arora <ashish.arora@tatainfotech.com>,
              Ashish Garg <akgarg@mercury.noida.hclt.com>,
              Ashish Kumar <ashishkr@usa.net>,
              Ashish Kumar <ashkumar@nortelnetworks.com>,
              Atul Arora <atul.arora@tatainfotech.com>,
              Atul Mukker <amukker@hotmail.com>,
              Avinash Sohal <Avinash.Sohal@geind.ge.com>,
              Avinash Sohal <Sohalavi@hotbot.com>,
              bijender sangwan <bijenders@getafix.infogain.com>,
              bijender sangwan <bsangwan@hotmail.com>,
              Deepak Biswas <dipakb@future.futsoft.com>,
              deepti jerath <deepti.jerath@tatainfotech.com>,
              Dilip Nanecha <nanecha@mailcity.com>,
              Dipanjan Purkayastha <dipanjan@caltiger.net.in>,
              dipanka sarmah <dipu@cdotb.ernet.in>,
              Divakar Shukla <diwakar_shukla@hotmail.com>,
              Divakar Shukla <d_shukla@engineer.com>,
              Sachin Jindal <sjindal@hss.hns.com>,
              Manoj Verma <mmanoj_vverma@hotmail.com>,
              Jitender Gupta <guptajitender@hotmail.com>,
              sunil madan <sunil_madan@intersolutions.stpn.soft.net>,
              Gagan Khatri <f98speed@fmsdu.ernet.in>,
              Gaurav Kamboj <gaurav.kamboj@tatainfotech.com>,
              Gurpreet Sachdeva <gurpreets@delhi.tcs.co.in>,
              I C Garg <iawrqats@vsnl.com>, I C Garg <saha@bom3.vsnl.net.in>,
              InderJit Singh <singhinderjit@hotmail.com>,
              Inderjit Singh <inderjits@mtcindia.com>,
              Jatin Mahendroo <janinfy@yahoo.com>,
              jatin mahendru <mahendrujatin@hotmail.com>,
              Jitender Chabra <jitender@reck.ernet.in>,
              Jitender Gupta <jitender@england.com>,
              Jitender Gupta <guptajitender@hotmail.com>,
              jyotsana dhawan <jdhawan@netacross.com>,
              "K.C. Ramakrishna" <kcramakrishna@yahoo.com>,
              kamal kakkar <kamal@aplion.stpn.soft.net>,
              Kamal Sharma <kamals@noida.hclt.com>,
              "Kamboj, Gaurav" <Gaurav.Kamboj@nike.com>,
              Kaptan Singh <kmehra@cdotp.ernet.in>,
              Karan Goel <karangoel@yahoo.com>,
              KCRAMAKRISHNA <KCRAMAKRISHNA@inf.com>,
              kirti Dua <kirtidua98@hotmail.com>,
              kumar ashish <kashduhan@netscape.net>,
              Lalit Jain <jain_lalit@hotmail.com>,
              Lalit Jain <Lalit.Jain@gecapital.com>,
              Lalit Mohan Deepak <lmdeepak@yahoo.com>,
              "Longia, Mohan (DAT)" <mlongia@NA2.US.ML.com>,
              Mahesh Garg <gargmahesh@usa.net>, Maiti <maiti75@hotmail.com>,
              manish garg <msg-c&ap@asc.ltindia.com>,
              Manish Handa <mhanda@ececs.uc.edu>,
              manish kheterpal <kmani13@hotmail.com>,
              "Manitosh Kaushik (E-mail)" <Manitosh.Kaushik@metamorgs.com>,
              manoj sharma <mauji@yahoo.com>, manoj sharma <manoj@basit.com>,
              Manoj Verma <mmanoj_vverma@hotmail.com>,
              Manoj Verma <manojv@solutionsny.com>,
              Manpreet Singh <ampraj@hotmail.com>,
              Mohan Longia <mlongia@NA2.US.ML.com>,
              Mohit Gupta <Mohit.gupta@motorola.com>,
              mohit kumar <mohitbhutani@usa.net>,
              mollars <mollars@egroups.com>,
              Mrityunjoy Ghosh <mitu_org@hotmail.com>,
              Mukesh Punhani <mpunhani@hotmail.com>,
              Munish Bansal <munishb@microsoft.com>,
              Navin Samuel <nsamuel@att.com>,
              Navin Samuel <navinsamuel@hotmail.com>,
              neeraj gaur <ngaur@hss.hns.com>,
              Neerav Aggarwal <aggrawan@geodc.patni.com>,
              Neetu Gupta <neetu.gupta@jci.com>,
              Neetu Gupta <neetug@yahoo.com>,
              nilesh maheshwari <nileshm12@hotmail.com>,
              Nitin Chawla <nitin_ch@excite.com>,
              Nitin Chawla <nitinc@lucent.com>,
              Nitin Dhingra <n_dhingra@hotmail.com>,
              Pankaj Bansal <pankaj.k@PARSEC.CO.IN>,
              Pankaj Bansal <the_piscean@usa.net>,
              Pankaj Garg <pgarg@hss.hns.com>,
              Pankaj Sharma <sharma_pank@yahoo.com>,
              Pawan Garg <PAWANg@interra.com>, Pawan Garg <PawanG@interra.com>,
              piyush goyal <piyushg@delhi.tcs.co.in>,
              Poonam Bhatla <poonam@dcmds.co.in>,
              Praney Mittal <praneym@hotmail.com>,
              Praney Mittal <praneym@delhi.tcs.co.in>,
              Prashant Dube <pdee@hotmail.com>,
              Prashant Dube <Prashant.Dube@fairchildsemi.com>,
              Prashant Jain <jainp@Catamarancom.com>,
              Prodyot Biswas <prodyotb@pune.tcs.co.in>,
              Puneet Narang <puneet_n@hotmail.com>,
              Puneet Narang <puneetn@iscc.net>,
              Qamar Zaman <qamarz@wipsys.soft.net>,
              Rahul Raina <rahul.raina@dcmds.co.in>,
              Raj Mohan <rajmohan@giasbg01.vsnl.net.in>,
              rohini juneja <rohini_juneja@i2.com>,
              rohit gupta <rohit_kgupta@yahoo.com>,
              rohit gupta <rohit.gupta@eng.sun.com>,
              Rohit Raina <rohitr@microsoft.com>,
              Manoj Verma <mmanoj_vverma@hotmail.com>,
              Jitender Gupta <guptajitender@hotmail.com>,
              sunil madan <sunil_madan@intersolutions.stpn.soft.net>,
              Sachin Garg <sachin@npi.stpn.soft.net>,
              Sachin Jindal <sjindal@hss.hns.com>,
              Sandeep Kumar <sandeep.kumar@gepex.ge.com>,
              saradindu ghosh <sandy_idesigner@hotmail.com>,
              sarvesh kakar <kakarsarvesh@usa.net>,
              sarvesh kumar <sarvesh_kumar@indianoil.co.in>,
              seema kakar <seemakakar@hotmail.com>,
              SHASHI bhushan <s_bhushan@mailcity.com>,
              shekhar dahiya <shekhardahiya@inf.com>,
              Shikhar Sarkar <shikhar@grex.cyberspace.org>,
              Sudarshan Dhingra <sk_dhingra@hotmail.com>,
              sunil madan <sunil_madan@intersolutions.stpn.soft.net>,
              Suparna Taneja <staneja@hss.hns.com>,
              Surbhi Singh <nizam@reck.ernet.in>,
              The great '93 batch of RECKers <reck@egroups.com>,
              Tushar Dave <dave.tushar@bellatlantic.com>,
              Vibhoosh Gupta <vibhoosh@dcmds.co.in>,
              Vikas Aggarwal <aggarwal_v@hotmail.com>,
              vikas bansal <vikasb@iimidr.ernet.in>,
              vikas junthra <vikas1003@hotmail.com>,
              Vikas Sood <visood@hss.hns.com>,
              Vineet Kumar Arora <Vineetk@talisma.com>,
              Anjana Sharma <anj_sharma@hotmail.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

From: Sanjay Kr. Gupta

HI All,
    Please change my e-mail address in ur address books to
            skgupta@globespan.net

Thanks and Regards,
Sanjay

--
Sanjay Kr. Gupta
GlobeSpan Inc.
email: mailto:skgupta@globespan.net
web: http://www.globespan.net



------------------------------------------------------------------------
Accurate impartial advice on everything from laptops to table saws.
http://click.egroups.com/1/4634/6/_/278248/_/960981499/
------------------------------------------------------------------------

To Post a message, send it to:   mollars@eGroups.com
To Unsubscribe, send a blank message to: mollars-unsubscribe@eGroups.com

------_=_NextPart_001_01BFD619.6A0A4E50
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-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>[mollars] change of e-mail address</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>From: Sanjay Kr. Gupta</FONT>
</P>

<P><FONT SIZE=3D2>HI All,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Please change my e-mail address =
in ur address books to</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; skgupta@globespan.net</FONT>
</P>

<P><FONT SIZE=3D2>Thanks and Regards,</FONT>
<BR><FONT SIZE=3D2>Sanjay</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Sanjay Kr. Gupta</FONT>
<BR><FONT SIZE=3D2>GlobeSpan Inc.</FONT>
<BR><FONT SIZE=3D2>email: <A =
HREF=3D"mailto:skgupta@globespan.net">mailto:skgupta@globespan.net</A></=
FONT>
<BR><FONT SIZE=3D2>web: <A HREF=3D"http://www.globespan.net" =
TARGET=3D"_blank">http://www.globespan.net</A></FONT>
</P>
<BR>
<BR>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
---------</FONT>
<BR><FONT SIZE=3D2>Accurate impartial advice on everything from laptops =
to table saws.</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://click.egroups.com/1/4634/6/_/278248/_/960981499/" =
TARGET=3D"_blank">http://click.egroups.com/1/4634/6/_/278248/_/960981499=
/</A></FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
---------</FONT>
</P>

<P><FONT SIZE=3D2>To Post a message, send it to:&nbsp;&nbsp; =
mollars@eGroups.com</FONT>
<BR><FONT SIZE=3D2>To Unsubscribe, send a blank message to: =
mollars-unsubscribe@eGroups.com</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD619.6A0A4E50--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 14 12:11:54 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26643
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 14 Jun 2000 12:11:53 -0400 (EDT)
Received: from standards (47.234.32.16:3362) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB758A0@standards.nortelnetworks.com>; Wed, 14 Jun 2000 12:02:12 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2418 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 14 Jun 2000 12:02:11 -0400
Received: from raptor.access.net.id by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB75876@standards.nortelnetworks.com>; Wed, 14 Jun 2000 11:52:03
          -0400
Received: from wireless (pteredon133.access.net.id [202.180.8.133]) by
          raptor.access.net.id (8.10.0/8.10.0) with SMTP id e5EFu8531528; Wed,
          14 Jun 2000 22:56:08 +0700
X-Sender: teddyap@pop3.access.net.id
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <3.0.6.32.20000614224536.0085a100@pop3.access.net.id>
Date:         Wed, 14 Jun 2000 22:45:36 +0700
Reply-To: "Teddy A. Purwadi" <teddyap@ACCESS.NET.ID>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Teddy A. Purwadi" <teddyap@ACCESS.NET.ID>
Subject:      Re: list mgmt subject
X-To:         Jeff Enderwick <jeff@ASSUREDACCESS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <20000614153751328.AAA105@nonki.assuredaccess.com>

I got it too. Recipient List suppressed may
be the way, not to megaco-list.

-Teddy

At 08:37 AM 6/14/00 -0700, Jeff Enderwick wrote:
>I'm on some other lists where a brief set
>of admin howtos is pasted to the tail of
>each list email. It seems to pretty much
>eliminate the occasional unsubsribe and
>other admin mail from being sent to the
>entire list. Maybe the list owner could
>add this?
>
>my $.02
>
>Jeff
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 14 21:55:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08334
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 14 Jun 2000 21:55:04 -0400 (EDT)
Received: from standards (47.234.32.16:2149) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75AC7@standards.nortelnetworks.com>; Wed, 14 Jun 2000 21:45:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3189 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 14 Jun 2000 21:45:27 -0400
Received: from qhars002.nortel.com (47.101.112.102:61310) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB75AC6@standards.nortelnetworks.com>; Wed, 14 Jun 2000
          21:45:27 -0400
Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com;
          Thu, 15 Jun 2000 02:48:58 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Wed, 14 Jun 2000 20:40:31 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPD1W9KN>; Wed, 14 Jun 2000 20:48:56 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480AA5@zcard00g.ca.nortel.com>
Date:         Wed, 14 Jun 2000 20:48:55 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Stream Mode
X-To:         Sameer Kaikini <ksameer@RND.CTS-CORP.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I confirm your finding -- we have not defined a default.  That means the MGC
should always set one, else behaviour is unpredictable.

> -----Original Message-----
> From: Sameer Kaikini [SMTP:ksameer@RND.CTS-CORP.COM]
> Sent: Wednesday, June 14, 2000 7:16 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Stream Mode
>
> Hello,
>
> What is the default value of the Stream Mode? I could not find it in the
> draft.
>
> Media descriptor
>     Local Control Descriptor
>         Stream Descriptor
>             Stream Mode
> Thank-you.
> Regards,
> Sameer


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 15 02:24:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24015
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 15 Jun 2000 02:24:36 -0400 (EDT)
Received: from standards (47.234.32.16:2245) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75B4B@standards.nortelnetworks.com>; Thu, 15 Jun 2000 2:14:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3339 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 02:14:28 -0400
Received: from web4206.mail.yahoo.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB75B39@standards.nortelnetworks.com>; Thu, 15 Jun 2000 2:04:27
          -0400
Received: from [203.197.168.163] by web4206.mail.yahoo.com; Wed, 14 Jun 2000
          23:13:13 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20000615061313.4711.qmail@web4206.mail.yahoo.com>
Date:         Wed, 14 Jun 2000 23:13:13 -0700
Reply-To: Charles Qiu <qiuxiuping@YAHOO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Charles Qiu <qiuxiuping@YAHOO.COM>
Subject:      When will the formal standard  come out?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi, list

When will the formal standard come out?
Will it come out in June?

Thanks.


__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 15 06:42:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26234
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 15 Jun 2000 06:42:21 -0400 (EDT)
Received: from standards (47.234.32.16:3512) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75BD6@standards.nortelnetworks.com>; Thu, 15 Jun 2000 6:32:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3530 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 06:32:42 -0400
Received: from web5101.mail.yahoo.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB75BD4@standards.nortelnetworks.com>; Thu, 15 Jun 2000 6:22:42
          -0400
Received: from [203.197.168.163] by web5101.mail.yahoo.com; Thu, 15 Jun 2000
          03:31:31 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20000615103131.20045.qmail@web5101.mail.yahoo.com>
Date:         Thu, 15 Jun 2000 03:31:31 -0700
Reply-To: Jack Wu <wuyongji@YAHOO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Jack Wu <wuyongji@YAHOO.COM>
Subject:      ISDN termination with Q.931 signaling
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello every one:

If there is a ISDN termination,such as ISDN telephone
which signaling is Q.931 in a MG, then how the MGC
deal with Q.931 to control the MG for establishing a
call.

Thanks.


__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 15 06:51:15 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26315
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 15 Jun 2000 06:51:14 -0400 (EDT)
Received: from standards (47.234.32.16:3512) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75BEB@standards.nortelnetworks.com>; Thu, 15 Jun 2000 6:41:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3531 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 06:41:55 -0400
Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB75BD5@standards.nortelnetworks.com>; Thu, 15 Jun 2000 6:31:55
          -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id GAA26113; Thu, 15 Jun 2000 06:40:43
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200006151040.GAA26113@ietf.org>
Date:         Thu, 15 Jun 2000 06:40:43 -0400
Reply-To: Internet-Drafts@ietf.org
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      I-D ACTION:draft-ietf-megaco-merged-01.txt
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Media Gateway Control Working Group of the IETF.

        Title           : Megaco Protocol
        Author(s)       : F. Cuervo,  N. Greene,  C. Huitema,
                          A. Rayhan,  B. Rosen,  J. Segers
        Filename        : draft-ietf-megaco-merged-01.txt
        Pages           : 166
        Date            : 14-Jun-00

This document reflects the application of the changes proposed in
draft-ietf-megaco-errata-03.txt to the base protocol document draft-
ietf-megaco-protocol-08.txt, plus a number of editorial changes that
do not affect the substance of the document.  It thus has common
text with the document that is about to be decided by ITU-T Study
Group 16 as Recommendation H.248.
The protocol presented in this document meets the requirements for a
media gateway control protocol as presented in RFC 2805.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-merged-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-megaco-merged-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-megaco-merged-01.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
        access-type="mail-server";
        server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:     <20000614110602.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-megaco-merged-01.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-megaco-merged-01.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20000614110602.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 15 08:21:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28755
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 15 Jun 2000 08:21:31 -0400 (EDT)
Received: from standards (47.234.32.16:2319) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75C22@standards.nortelnetworks.com>; Thu, 15 Jun 2000 8:11:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3619 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 08:11:52 -0400
Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB75C1B@standards.nortelnetworks.com>; Thu, 15 Jun 2000 8:01:51
          -0400
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by
          mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id PAA23986; Thu, 15 Jun
          2000 15:10:28 +0300 (EETDST)
Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com
          [131.228.118.151]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP
          id PAA26006; Thu, 15 Jun 2000 15:10:21 +0300 (EETDST)
Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id <MJXG4LQK>;
          Thu, 15 Jun 2000 15:10:12 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <11CD408013B6D2119BB50008C7EA510C02914960@eseis05nok>
Date:         Thu, 15 Jun 2000 15:10:10 +0300
Reply-To: mikko.alutoin@NOKIA.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Mikko Alutoin <mikko.alutoin@NOKIA.COM>
Subject:      Re: ISDN termination with Q.931 signaling
X-To:         wuyongji@YAHOO.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,

You might find the following I-D interesting:
draft-bouwen-megaco-isdn-00.txt

Mikko

> -----Original Message-----
> From: EXT Jack Wu [mailto:wuyongji@YAHOO.COM]
> Sent: 15. June 2000 13:32
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: ISDN termination with Q.931 signaling
>
>
> Hello every one:
>
> If there is a ISDN termination,such as ISDN telephone
> which signaling is Q.931 in a MG, then how the MGC
> deal with Q.931 to control the MG for establishing a
> call.
>
> Thanks.
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Photos -- now, 100 FREE prints!
> http://photos.yahoo.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 15 08:29:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29032
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 15 Jun 2000 08:29:59 -0400 (EDT)
Received: from standards (47.234.32.16:2319) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75C37@standards.nortelnetworks.com>; Thu, 15 Jun 2000 8:20:36 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3657 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 08:20:36 -0400
Received: from qhars002.nortel.com (47.101.112.102:54267) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB75C36@standards.nortelnetworks.com>; Thu, 15 Jun 2000
          8:20:36 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Thu, 15 Jun 2000 13:27:00 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Thu, 15 Jun 2000 07:26:05 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPD1XB4K>; Thu, 15 Jun 2000 07:26:43 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480AA9@zcard00g.ca.nortel.com>
Date:         Thu, 15 Jun 2000 07:26:42 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: When will the formal standard come out?
X-To:         Charles Qiu <qiuxiuping@YAHOO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

My morning's mail included your note and two others which are relevant.
First: the formal ITU-T approval of H.248 was completed in Geneva earlier
today.  It takes a few months for them to publish a standard formally
(similar to our RFC editor's queue, in which our requirements document
languished for two months), but in the meantime I will ensure that the
document that was actually decided is posted on the Megaco FTP site.
Secondly and purely by coincidence, draft-ietf-megaco-merged-01.txt was
announced this morning.  This actually got lost in the system for a couple
of weeks.  This is our counterpart to the ITU-T document.

The IESG approved the combination of -protocol-08 and -errata-03 for
publication as Proposed Standard RFCs.  As I understand it, to get approval
for the merged document, I have to take it through the full process all over
again.  I will announce Last Call in a separate message.  I really don't
know what we do with any comments received, other than to get ITU-T
agreement to include them in the H.248 Implementor's Guide.

> -----Original Message-----
> From: Charles Qiu [SMTP:qiuxiuping@YAHOO.COM]
> Sent: Thursday, June 15, 2000 2:13 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      When will the formal standard come out?
>
> Hi, list
>
> When will the formal standard come out?
> Will it come out in June?
>
> Thanks.
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Photos -- now, 100 FREE prints!
> http://photos.yahoo.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 15 08:34:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29216
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 15 Jun 2000 08:34:20 -0400 (EDT)
Received: from standards (47.234.32.16:2319) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75C4C@standards.nortelnetworks.com>; Thu, 15 Jun 2000 8:24:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3686 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 08:24:59 -0400
Received: from qhars002.nortel.com (47.101.112.102:54944) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB75C4B@standards.nortelnetworks.com>; Thu, 15 Jun 2000
          8:24:59 -0400
Received: from zrtps06s.us.nortel.com (actually 47.140.48.50) by
          qhars002.nortel.com; Thu, 15 Jun 2000 13:30:06 +0100
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n.us.nortel.com)
          by zrtps06s.us.nortel.com; Thu, 15 Jun 2000 08:29:20 -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Thu, 15 Jun 2000 08:28:50 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPQCZWPG>; Thu, 15 Jun 2000 08:28:49 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480AAA@zcard00g.ca.nortel.com>
Date:         Thu, 15 Jun 2000 08:28:48 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: ISDN termination with Q.931 signaling
X-To:         Jack Wu <wuyongji@YAHOO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The MGC sets up a signalling backhaul connection to collect the Q.931
messages independently of any Megaco/H.248 control session.  Sigtran is
dealing with this issue.

> -----Original Message-----
> From: Jack Wu [SMTP:wuyongji@YAHOO.COM]
> Sent: Thursday, June 15, 2000 6:32 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      ISDN termination with Q.931 signaling
>
> Hello every one:
>
> If there is a ISDN termination,such as ISDN telephone
> which signaling is Q.931 in a MG, then how the MGC
> deal with Q.931 to control the MG for establishing a
> call.
>
> Thanks.
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Photos -- now, 100 FREE prints!
> http://photos.yahoo.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 15 09:29:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01205
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 15 Jun 2000 09:29:32 -0400 (EDT)
Received: from standards (47.234.32.16:2375) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75C81@standards.nortelnetworks.com>; Thu, 15 Jun 2000 9:20:05 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0032 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 09:20:05 -0400
Received: from qhars002.nortel.com (47.101.112.102:63102) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB75C80@standards.nortelnetworks.com>; Thu, 15 Jun 2000
          9:20:05 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Thu, 15 Jun 2000 14:25:12 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Thu, 15 Jun 2000 09:21:29 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPQCZYQT>; Thu, 15 Jun 2000 09:21:28 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480AB2@zcard00g.ca.nortel.com>
Date:         Thu, 15 Jun 2000 09:21:25 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      FW: Question about H.248 Add command
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The question raised here may be of interest to the list.

> -----Original Message-----
> From: Taylor, Tom-PT [NORSE:B901:EXCH]
> Sent: Wednesday, June 14, 2000 10:16 PM
> To:   'David_Franklin@nmss.com'; ISC_DeviceControl
> Subject:      RE: Question about H.248 Add command
>
        [PTT]  It would have been quite reasonable to post this to the
Megaco list.
        The ways I can think of to underspecify Events and Signals
descriptors
        are fairly devious.  On the other hand, if the Add command doesn't
have
        an Events descriptor at all, I would find it reasonable for the MG
to
        return the last value set for that descriptor, since that would
remain
        the current value.  The same logic would apply for Signals, except
that
        I doubt a termination in the null context would have any signals
set.
        Thinking this through, it occurred to me that an auditValue of a
Signals
        descriptor at any time could be misleading, because it wouldn't be
clear
        which signals had already completed.

        All in all you've identified a rather murky area, not completely
thought
        out.  May I have permission to repost this exchange to the Megaco
list?

                -----Original Message-----
        From:   David_Franklin@nmss.com [SMTP:David_Franklin@nmss.com]
        Sent:   Wednesday, June 14, 2000 3:25 PM
        To:     ISC_DeviceControl
        Subject:        Question about H.248 Add command




                I wasn't sure whether to post this to the Megaco list, but I

        thought I would try here first.

                In the H.248 draft (draft-ietf-megaco-protocol-08.txt),
        section 7.2.1 describes the Add command. The last
        paragraph of that section is as follows:

                   All descriptors that can be modified could be returned by
MG
        if a
           parameter was underspecified or overspecified.  ObservedEvents,
           Statistics, and Packages, and the EventBuffer Descriptors are
           returned only if requested in the AuditDescriptor.  Add SHALL NOT
be
           used on a Termination with a serviceState of "OutofService".

                First, the language "could be returned" seems a little too
        loose, but this isn't the forum to address that.  My real
        question is that there are a number of other descriptors
        that can be returned: EventsDescriptor, SignalsDescriptor,
        DigitMapDescriptor.  Are these returned with an under-
        or over-specified parameter? Or only if there was an
        embedded AuditDescriptor in the command? If, for example,
        the EventsDescriptor parameter was overspecified, would
        the MG then return the EventsDescriptor as being the
        event it chose to satisfy the overspecification?

                Regards,
        David Franklin
        Principal Software Engineer
        Natural MicroSystems Corp.
        david_franklin@nmss.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 15 10:15:12 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02710
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 15 Jun 2000 10:15:12 -0400 (EDT)
Received: from standards (47.234.32.16:3755) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75CA1@standards.nortelnetworks.com>; Thu, 15 Jun 2000 10:05:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0075 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 10:05:38 -0400
Received: from qhars002.nortel.com (47.101.112.102:37269) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB75CA0@standards.nortelnetworks.com>; Thu, 15 Jun 2000
          10:05:38 -0400
Received: from zrtps06s.us.nortel.com (actually 47.140.48.50) by
          qhars002.nortel.com; Thu, 15 Jun 2000 15:05:41 +0100
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n.us.nortel.com)
          by zrtps06s.us.nortel.com; Thu, 15 Jun 2000 10:03:59 -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Thu, 15 Jun 2000 10:03:40 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPQCZ5RH>; Thu, 15 Jun 2000 10:03:39 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480AB3@zcard00g.ca.nortel.com>
Date:         Thu, 15 Jun 2000 10:03:37 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Last Call: draft-ietf-megaco-merged-01.txt
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The ITU-T today formally approved H.248.  draft-ietf-megaco-merged-01.txt
provides the same text, obtained by merging
draft-ietf-megaco-protocol-08.txt and draft-ietf-megaco-errata-03.txt.
While the latter two have been approved for publication as standards-track
RFCs, I believe that the industry would find it more convenient to have a
single document to work from.

We have two choices:

(1) Run draft-ietf-megaco-merged-01.txt through Last Call and IESG review.
As well as providing a single document, this would fulfill  to the letter
our agreement with the ITU-T to republish H.248.

(2) Consider the currently approved documents to fulfill the ITU-T agreement
and carry the merged series as a living document, incorporating corrections
and clarifications mutually agreed upon by the IETF and ITU-T.

If we choose the first course of action, we have the problem of what to do
with any comments received during the review process.

I would like the advice of the list on where to go from here.  Above all, we
must preserve the benefits of having a single standard for the industry to
work with.

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 15 16:41:53 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14207
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 15 Jun 2000 16:41:52 -0400 (EDT)
Received: from standards (47.234.32.16:4833) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75DC4@standards.nortelnetworks.com>; Thu, 15 Jun 2000 16:32:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0425 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 16:32:30 -0400
Received: from qhars002.nortel.com (47.101.112.102:39058) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB75DC3@standards.nortelnetworks.com>; Thu, 15 Jun 2000
          16:32:29 -0400
Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com;
          Thu, 15 Jun 2000 21:37:09 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Thu, 15 Jun 2000 15:28:42 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPD1XVLC>; Thu, 15 Jun 2000 15:37:05 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480ABA@zcard00g.ca.nortel.com>
Date:         Thu, 15 Jun 2000 15:37:02 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Rechartering
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

At the Adelaide meeting, attendees favoured continuance of the Working Group
in order to ensure an IETF voice in the evolution of the Megaco/H.248
protocol.  Since we have accomplished all of our original charter except for
the MIBs, it is time to think about a new charter.  I would propose that
this charter contain the following elements:

(1) an introduction including a general definition of a Media Gateway and a
description of work accomplished so far

(2) a general description of the work to be carried out by the Working Group
over the next year
    -- identification of errors and clarifications required to the base
protocol
    -- review and standardization of additional packages
    -- completion of the Megaco/H.248 MIBs
    -- (suggested in Oslo) completion of a document giving the complete
picture of the MIBs required to manage a Media Gateway
    -- cooperation with MMUSIC on the detailed extensions to SDP required to
support IP transport of media
    -- review of proposed Megaco/H.248 profiles, upon request from other
bodies
    -- consideration of possible extensions to the base protocol
  all in cooperation with the ITU-T and other standards bodies and fora.

(3) a detailed listing of all work currently in hand.

Would the list care to comment on this proposal?  Do we agree to recharter,
and does (2) have the right list of work items?

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 15 21:18:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19228
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 15 Jun 2000 21:18:17 -0400 (EDT)
Received: from standards (47.234.32.16:1170) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75E26@standards.nortelnetworks.com>; Thu, 15 Jun 2000 21:08:57 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0557 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 21:08:57 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB75E25@standards.nortelnetworks.com>; Thu, 15 Jun 2000 21:08:57
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id VAA02577; Thu, 15 Jun 2000 21:17:45 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id VAA13733; Thu, 15 Jun 2000 21:17:48 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <MR1Y4BGN>; Thu, 15 Jun 2000 21:17:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678470@whq-msgusr-02.fore.com>
Date:         Thu, 15 Jun 2000 21:17:45 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Last Call: draft-ietf-megaco-merged-01.txt
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I would prefer to have merged-01 published as an RFC, which would
"obsolete" the RFC which is the protocol-08 and errata-03.
I would be willing to take the "risk" about comments.

I'd say that comments are "discouraged", but of course, if they
come, we have to deal with them.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Thursday, June 15, 2000 10:04 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Last Call: draft-ietf-megaco-merged-01.txt
>
>
> The ITU-T today formally approved H.248.
> draft-ietf-megaco-merged-01.txt
> provides the same text, obtained by merging
> draft-ietf-megaco-protocol-08.txt and draft-ietf-megaco-errata-03.txt.
> While the latter two have been approved for publication as
> standards-track
> RFCs, I believe that the industry would find it more
> convenient to have a
> single document to work from.
>
> We have two choices:
>
> (1) Run draft-ietf-megaco-merged-01.txt through Last Call and
> IESG review.
> As well as providing a single document, this would fulfill
> to the letter
> our agreement with the ITU-T to republish H.248.
>
> (2) Consider the currently approved documents to fulfill the
> ITU-T agreement
> and carry the merged series as a living document,
> incorporating corrections
> and clarifications mutually agreed upon by the IETF and ITU-T.
>
> If we choose the first course of action, we have the problem
> of what to do
> with any comments received during the review process.
>
> I would like the advice of the list on where to go from here.
>  Above all, we
> must preserve the benefits of having a single standard for
> the industry to
> work with.
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 15 21:34:41 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19427
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 15 Jun 2000 21:34:39 -0400 (EDT)
Received: from standards (47.234.32.16:1170) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75E3B@standards.nortelnetworks.com>; Thu, 15 Jun 2000 21:25:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0582 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 21:25:20 -0400
Received: from ish7.ericsson.com.au (203.61.155.111:47981) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB75E38@standards.nortelnetworks.com>; Thu, 15 Jun 2000
          21:15:19 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA19720 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 16 Jun 2000 11:23:10
          +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA22941 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 16 Jun 2000 11:24:02
          +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA02068 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 16 Jun 2000 11:24:31
          +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678470@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <394981A2.38681B66@ericsson.com>
Date:         Fri, 16 Jun 2000 11:23:46 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Last Call: draft-ietf-megaco-merged-01.txt
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I concur with Brian. I'd like to see a merged version and it does follow
previous agreements. Comments can be handled as an implementors guide.

Christian

"Rosen, Brian" wrote:
>
> I would prefer to have merged-01 published as an RFC, which would
> "obsolete" the RFC which is the protocol-08 and errata-03.
> I would be willing to take the "risk" about comments.
>
> I'd say that comments are "discouraged", but of course, if they
> come, we have to deal with them.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Thursday, June 15, 2000 10:04 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Last Call: draft-ietf-megaco-merged-01.txt
> >
> >
> > The ITU-T today formally approved H.248.
> > draft-ietf-megaco-merged-01.txt
> > provides the same text, obtained by merging
> > draft-ietf-megaco-protocol-08.txt and draft-ietf-megaco-errata-03.txt.
> > While the latter two have been approved for publication as
> > standards-track
> > RFCs, I believe that the industry would find it more
> > convenient to have a
> > single document to work from.
> >
> > We have two choices:
> >
> > (1) Run draft-ietf-megaco-merged-01.txt through Last Call and
> > IESG review.
> > As well as providing a single document, this would fulfill
> > to the letter
> > our agreement with the ITU-T to republish H.248.
> >
> > (2) Consider the currently approved documents to fulfill the
> > ITU-T agreement
> > and carry the merged series as a living document,
> > incorporating corrections
> > and clarifications mutually agreed upon by the IETF and ITU-T.
> >
> > If we choose the first course of action, we have the problem
> > of what to do
> > with any comments received during the review process.
> >
> > I would like the advice of the list on where to go from here.
> >  Above all, we
> > must preserve the benefits of having a single standard for
> > the industry to
> > work with.
> >
> > Tom Taylor
> > Phone and FAX: +1 613 736 0961
> > E-mail: taylor@nortelnetworks.com
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 16 00:48:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24235
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 16 Jun 2000 00:48:21 -0400 (EDT)
Received: from standards (47.234.32.16:4509) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75E8A@standards.nortelnetworks.com>; Fri, 16 Jun 2000 0:38:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0673 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 00:38:41 -0400
Received: from mail.huawei.com.cn (202.96.135.132:38614) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB75E87@standards.nortelnetworks.com>; Fri, 16 Jun 2000
          0:28:40 -0400
Received: from huawei.com.cn ([10.105.29.194]) by mail.huawei.com.cn (Netscape
          Mail Server v2.02) with ESMTP id AAA2452 for
          <megaco@standards.nortelnetworks.com>; Fri, 16 Jun 2000 12:37:34 +0800
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3949AEA9.4ADA1D52@huawei.com.cn>
Date:         Fri, 16 Jun 2000 12:35:53 +0800
Reply-To: "Xiaotian Bian(Bill)" <bianxiaotian@HUAWEI.COM.CN>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Xiaotian Bian(Bill)" <bianxiaotian@HUAWEI.COM.CN>
Subject:      VTOA MG & ATM signaling
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,
   Imagine a VTOA MG carrying media streams on ATM network. If MGC sends
it an  ADD command asking it to establish connections with peer VTOA MG,
then ATM signaling should be applied. Is the origination or termination
of ATM signaling done by VTOA MG or else,by MGC?
  Thanks.

Bill.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 16 02:45:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06943
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 16 Jun 2000 02:45:20 -0400 (EDT)
Received: from standards (47.234.32.16:4085) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75ED2@standards.nortelnetworks.com>; Fri, 16 Jun 2000 2:35:52 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0770 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 02:35:52 -0400
Received: from tama5.ecl.ntt.co.jp by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB75ED1@standards.nortelnetworks.com>; Fri, 16 Jun 2000 2:35:51
          -0400
Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100])
          by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id
          PAA11380; Fri, 16 Jun 2000 15:44:19 +0900 (JST) (envelope-from
          makinae.naoto@lab.ntt.co.jp)
Received: from ima.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp
          (8.9.3+3.2W/3.7W/06/05/00) with ESMTP id PAA05041; Fri, 16 Jun 2000
          15:44:18 +0900 (JST) (envelope-from makinae.naoto@lab.ntt.co.jp)
Received: from idc (ksk-p22.pflab.ecl.ntt.co.jp [129.60.18.196]) by
          ima.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id PAA21159; Fri, 16 Jun
          2000 15:44:18 +0900 (JST)
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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Message-ID:  <NDBBKGPMCLCCPKPNAOBEGEEBCMAA.makinae.naoto@lab.ntt.co.jp>
Date:         Fri, 16 Jun 2000 15:44:40 +0900
Reply-To: makinae.naoto@lab.ntt.co.jp
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Naoto MAKINAE <makinae.naoto@lab.ntt.co.jp>
Subject:      Re: Last Call: draft-ietf-megaco-merged-01.txt
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <394981A2.38681B66@ericsson.com>
Content-Transfer-Encoding: 7bit

Hi all,

I agree to publishing a merged document as an RFC.

My only concern is that if any changes are made to the merged-01,
there would be no RFC equivalent to ITU-T H.248.

So, I suggest that any changes be
  - incorporated into the RFC with diff-marks or something, depending on
    the nature of changes, as well as
  - attached as a separate annex to the RFC.

This enables us to distinguish the new RFC with changes if any and
the merged-01/H.248, by calling them as "RFCXXX" and "RFCXXX without Annex YYY",
respectively.

Also, I understand that the new RFC will be liaised to ITU-T for its consideration of
publishing an implementor's guide.

> I concur with Brian. I'd like to see a merged version and it does follow
> previous agreements. Comments can be handled as an implementors guide.
>
> Christian
>
> "Rosen, Brian" wrote:
> >
> > I would prefer to have merged-01 published as an RFC, which would
> > "obsolete" the RFC which is the protocol-08 and errata-03.
> > I would be willing to take the "risk" about comments.
> >
> > I'd say that comments are "discouraged", but of course, if they
> > come, we have to deal with them.
> >
> > Brian
> >


--
Naoto MAKINAE
Email:makinae.naoto@lab.ntt.co.jp


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 16 04:25:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07565
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 16 Jun 2000 04:25:16 -0400 (EDT)
Received: from standards (47.234.32.16:1717) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75F23@standards.nortelnetworks.com>; Fri, 16 Jun 2000 4:14:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0814 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 04:14:29 -0400
Received: from ogma.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB75EF3@standards.nortelnetworks.com>; Fri, 16 Jun 2000 4:04:29
          -0400
Received: from munich.cisco.com (munich.cisco.com [144.254.24.45]) by
          ogma.cisco.com (Postfix) with ESMTP id 52FB115D for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 16 Jun 2000 10:13:21
          +0200 (MET DST)
Received: from hdoelz-8kcdt (mun-pan-usr-vlan13-dhcp7.cisco.com
          [144.254.27.143]) by munich.cisco.com (8.8.8+Sun/8.8.8) with SMTP id
          KAA06227 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 16 Jun 2000
          10:13:20 +0200 (MET DST)
X-Sender: hdoelz@munich.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
Mime-Version: 1.0
Content-Type: multipart/alternative; types="text/plain,text/html";
              boundary="=====================_1024679==_.ALT"
Message-ID:  <200006160813.KAA06227@munich.cisco.com>
Date:         Fri, 16 Jun 2000 10:13:47 +0100
Reply-To: Harald Doelz <hdoelz@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Harald Doelz <hdoelz@CISCO.COM>
Subject:      unsubscription
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--=====================_1024679==_.ALT
Content-Type: text/plain; charset="us-ascii"

Please unsubscribe hdoelz@cisco.com

Thank you very much
-------------------------------------------
Harald Doelz
Internetworking Consultant

Cisco Systems
Lilienthalstrasse 9
85399 Hallbergmoos

fixed:  +49(0)811 559 5408
mobile: +49(0)170 575 4276
mailto: hdoelz@cisco.com

--=====================_1024679==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<b>Please unsubscribe hdoelz@cisco.com<br>
<br>
Thank you very much</b><br>
<div>-------------------------------------------</div>
<div>Harald Doelz</div>
<div>Internetworking Consultant</div>
<br>
<div>Cisco Systems</div>
<div>Lilienthalstrasse 9</div>
<div>85399 Hallbergmoos</div>
<br>
<div>fixed:&nbsp; +49(0)811 559 5408</div>
<div>mobile: +49(0)170 575 4276</div>
<div>mailto: hdoelz@cisco.com</div>
</html>

--=====================_1024679==_.ALT--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 16 10:07:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12260
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 16 Jun 2000 10:07:13 -0400 (EDT)
Received: from standards (47.234.32.16:1425) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75FDF@standards.nortelnetworks.com>; Fri, 16 Jun 2000 9:57:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1115 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 09:57:32 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB75FDE@standards.nortelnetworks.com>; Fri, 16 Jun 2000 9:57:32
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id KAA06497; Fri, 16 Jun 2000 10:06:22 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id KAA29068; Fri, 16 Jun 2000 10:06:24 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <MR1Y4NF1>; Fri, 16 Jun 2000 10:06:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678474@whq-msgusr-02.fore.com>
Date:         Fri, 16 Jun 2000 10:06:19 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Question about H.248 Add command
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I think the intention is really clear.  If the language is
unclear, we can work on it in subsequent editions.

When you get a reply, the descriptors you get are determined
by:

Any under/over specification of a descriptor mentioned in
the command

Something you ask for by using the Audit descriptor.

You don't get any descriptors that aren't in one of those
two categories.  Whenever you under/overspecify a
descriptor, you get the value the MG settled on in the
reply.  If you include an audit, you get the descriptors
you asked for.

It does occur to me that we should state that if you do
both - i.e. underspecify a descriptor AND ask for it
in the Audit descriptor, then you only get one copy of
it in the return.

So, David's example of overspecifying Events would
result in the EventsDescriptor being returned.
If the command does not specify an EventsDescriptor,
the only way you get one returned is to ask for it
with AuditDescriptor.

Since the MG is not synchronous with the MGC, returning
Events and Signals descriptors is always dicey.
Events could occur at any time, and we don't specify,
and don't want to specify, exactly how the MG responds
when an event (or completion of a signal) occurs near
to when a reply containing the event (or signal)
is constructed.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Thursday, June 15, 2000 9:21 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: FW: Question about H.248 Add command
>
>
> The question raised here may be of interest to the list.
>
> > -----Original Message-----
> > From: Taylor, Tom-PT [NORSE:B901:EXCH]
> > Sent: Wednesday, June 14, 2000 10:16 PM
> > To:   'David_Franklin@nmss.com'; ISC_DeviceControl
> > Subject:      RE: Question about H.248 Add command
> >
>         [PTT]  It would have been quite reasonable to post this to the
> Megaco list.
>         The ways I can think of to underspecify Events and Signals
> descriptors
>         are fairly devious.  On the other hand, if the Add
> command doesn't
> have
>         an Events descriptor at all, I would find it
> reasonable for the MG
> to
>         return the last value set for that descriptor, since
> that would
> remain
>         the current value.  The same logic would apply for
> Signals, except
> that
>         I doubt a termination in the null context would have
> any signals
> set.
>         Thinking this through, it occurred to me that an
> auditValue of a
> Signals
>         descriptor at any time could be misleading, because
> it wouldn't be
> clear
>         which signals had already completed.
>
>         All in all you've identified a rather murky area, not
> completely
> thought
>         out.  May I have permission to repost this exchange
> to the Megaco
> list?
>
>                 -----Original Message-----
>         From:   David_Franklin@nmss.com [SMTP:David_Franklin@nmss.com]
>         Sent:   Wednesday, June 14, 2000 3:25 PM
>         To:     ISC_DeviceControl
>         Subject:        Question about H.248 Add command
>
>
>
>
>                 I wasn't sure whether to post this to the
> Megaco list, but I
>
>         thought I would try here first.
>
>                 In the H.248 draft
> (draft-ietf-megaco-protocol-08.txt),
>         section 7.2.1 describes the Add command. The last
>         paragraph of that section is as follows:
>
>                    All descriptors that can be modified could
> be returned by
> MG
>         if a
>            parameter was underspecified or overspecified.
> ObservedEvents,
>            Statistics, and Packages, and the EventBuffer
> Descriptors are
>            returned only if requested in the AuditDescriptor.
>  Add SHALL NOT
> be
>            used on a Termination with a serviceState of
> "OutofService".
>
>                 First, the language "could be returned" seems
> a little too
>         loose, but this isn't the forum to address that.  My real
>         question is that there are a number of other descriptors
>         that can be returned: EventsDescriptor, SignalsDescriptor,
>         DigitMapDescriptor.  Are these returned with an under-
>         or over-specified parameter? Or only if there was an
>         embedded AuditDescriptor in the command? If, for example,
>         the EventsDescriptor parameter was overspecified, would
>         the MG then return the EventsDescriptor as being the
>         event it chose to satisfy the overspecification?
>
>                 Regards,
>         David Franklin
>         Principal Software Engineer
>         Natural MicroSystems Corp.
>         david_franklin@nmss.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 16 10:17:03 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12548
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 16 Jun 2000 10:17:02 -0400 (EDT)
Received: from standards (47.234.32.16:1425) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75FF6@standards.nortelnetworks.com>; Fri, 16 Jun 2000 10:07:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1146 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 10:07:38 -0400
Received: from qhars002.nortel.com (47.101.112.102:41649) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB75FF5@standards.nortelnetworks.com>; Fri, 16 Jun 2000
          10:07:38 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Fri, 16 Jun 2000 15:15:09 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Fri, 16 Jun 2000 10:11:51 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPQC5W5V>; Fri, 16 Jun 2000 10:11:51 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480AC3@zcard00g.ca.nortel.com>
Date:         Fri, 16 Jun 2000 10:11:46 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Question about H.248 Add command
X-To:         Brian Rosen <brosen@FORE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I have always assumed without thinking about it that an audit of the Signals
descriptor would return whatever the MGC last set there.  Is this how other
people see it?

> -----Original Message-----
> From: Rosen, Brian [SMTP:Brian.Rosen@marconi.com]
> Sent: Friday, June 16, 2000 10:06 AM
> To:   Taylor, Tom-PT [NORSE:B901:EXCH];
> MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      RE: Question about H.248 Add command
>
> I think the intention is really clear.  If the language is
> unclear, we can work on it in subsequent editions.
>
> When you get a reply, the descriptors you get are determined
> by:
>
> Any under/over specification of a descriptor mentioned in
> the command
>
> Something you ask for by using the Audit descriptor.
>
> You don't get any descriptors that aren't in one of those
> two categories.  Whenever you under/overspecify a
> descriptor, you get the value the MG settled on in the
> reply.  If you include an audit, you get the descriptors
> you asked for.
>
> It does occur to me that we should state that if you do
> both - i.e. underspecify a descriptor AND ask for it
> in the Audit descriptor, then you only get one copy of
> it in the return.
>
> So, David's example of overspecifying Events would
> result in the EventsDescriptor being returned.
> If the command does not specify an EventsDescriptor,
> the only way you get one returned is to ask for it
> with AuditDescriptor.
>
> Since the MG is not synchronous with the MGC, returning
> Events and Signals descriptors is always dicey.
> Events could occur at any time, and we don't specify,
> and don't want to specify, exactly how the MG responds
> when an event (or completion of a signal) occurs near
> to when a reply containing the event (or signal)
> is constructed.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Thursday, June 15, 2000 9:21 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: FW: Question about H.248 Add command
> >
> >
> > The question raised here may be of interest to the list.
> >
> > > -----Original Message-----
> > > From: Taylor, Tom-PT [NORSE:B901:EXCH]
> > > Sent: Wednesday, June 14, 2000 10:16 PM
> > > To:   'David_Franklin@nmss.com'; ISC_DeviceControl
> > > Subject:      RE: Question about H.248 Add command
> > >
> >         [PTT]  It would have been quite reasonable to post this to the
> > Megaco list.
> >         The ways I can think of to underspecify Events and Signals
> > descriptors
> >         are fairly devious.  On the other hand, if the Add
> > command doesn't
> > have
> >         an Events descriptor at all, I would find it
> > reasonable for the MG
> > to
> >         return the last value set for that descriptor, since
> > that would
> > remain
> >         the current value.  The same logic would apply for
> > Signals, except
> > that
> >         I doubt a termination in the null context would have
> > any signals
> > set.
> >         Thinking this through, it occurred to me that an
> > auditValue of a
> > Signals
> >         descriptor at any time could be misleading, because
> > it wouldn't be
> > clear
> >         which signals had already completed.
> >
> >         All in all you've identified a rather murky area, not
> > completely
> > thought
> >         out.  May I have permission to repost this exchange
> > to the Megaco
> > list?
> >
> >                 -----Original Message-----
> >         From:   David_Franklin@nmss.com [SMTP:David_Franklin@nmss.com]
> >         Sent:   Wednesday, June 14, 2000 3:25 PM
> >         To:     ISC_DeviceControl
> >         Subject:        Question about H.248 Add command
> >
> >
> >
> >
> >                 I wasn't sure whether to post this to the
> > Megaco list, but I
> >
> >         thought I would try here first.
> >
> >                 In the H.248 draft
> > (draft-ietf-megaco-protocol-08.txt),
> >         section 7.2.1 describes the Add command. The last
> >         paragraph of that section is as follows:
> >
> >                    All descriptors that can be modified could
> > be returned by
> > MG
> >         if a
> >            parameter was underspecified or overspecified.
> > ObservedEvents,
> >            Statistics, and Packages, and the EventBuffer
> > Descriptors are
> >            returned only if requested in the AuditDescriptor.
> >  Add SHALL NOT
> > be
> >            used on a Termination with a serviceState of
> > "OutofService".
> >
> >                 First, the language "could be returned" seems
> > a little too
> >         loose, but this isn't the forum to address that.  My real
> >         question is that there are a number of other descriptors
> >         that can be returned: EventsDescriptor, SignalsDescriptor,
> >         DigitMapDescriptor.  Are these returned with an under-
> >         or over-specified parameter? Or only if there was an
> >         embedded AuditDescriptor in the command? If, for example,
> >         the EventsDescriptor parameter was overspecified, would
> >         the MG then return the EventsDescriptor as being the
> >         event it chose to satisfy the overspecification?
> >
> >                 Regards,
> >         David Franklin
> >         Principal Software Engineer
> >         Natural MicroSystems Corp.
> >         david_franklin@nmss.com
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 16 10:20:26 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12585
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 16 Jun 2000 10:20:25 -0400 (EDT)
Received: from standards (47.234.32.16:1425) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76009@standards.nortelnetworks.com>; Fri, 16 Jun 2000 10:10:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1172 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 10:10:47 -0400
Received: from ns-inetext.inet.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB76008@standards.nortelnetworks.com>; Fri, 16 Jun 2000 10:10:47
          -0400
Received: from harpo.inetint.com (harpo [172.16.99.60]) by ns-inetext.inet.com
          (8.9.2/8.9.2) with ESMTP id JAA22609 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 16 Jun 2000 09:18:33
          -0500 (CDT)
Received: from inet.com ([172.16.63.49]) by harpo.inetint.com (Netscape
          Messaging Server 3.6)  with ESMTP id AAA1069; Fri, 16 Jun 2000
          09:24:44 -0500
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480AB3@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <394A3740.D28B5895@inet.com>
Date:         Fri, 16 Jun 2000 09:18:40 -0500
Reply-To: Mart Nurmet <mart.nurmet@INET.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Mart Nurmet <mart.nurmet@INET.COM>
Organization: Inet - Staff Engineer
Subject:      Re: Last Call: draft-ietf-megaco-merged-01.txt
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Tom and all:

The position here is to support  the currently approved documents so that we
fulfill the ITU-T
agreement and get it distributed.  It is appropriate to carry the merged series
as a living document in this rapidly evolving technology. Then we need to
incorporating corrections and clarifications mutually agreed upon by the IETF
and ITU-T as they take place.  I'm sure that the ITU will also expedite those
necessary inclusions after appropriate deliberations.  So we support your option
#2.

-Mart

Tom-PT Taylor wrote:

> The ITU-T today formally approved H.248.  draft-ietf-megaco-merged-01.txt
> provides the same text, obtained by merging
> draft-ietf-megaco-protocol-08.txt and draft-ietf-megaco-errata-03.txt.
> While the latter two have been approved for publication as standards-track
> RFCs, I believe that the industry would find it more convenient to have a
> single document to work from.
>
> We have two choices:
>
> (1) Run draft-ietf-megaco-merged-01.txt through Last Call and IESG review.
> As well as providing a single document, this would fulfill  to the letter
> our agreement with the ITU-T to republish H.248.
>
> (2) Consider the currently approved documents to fulfill the ITU-T agreement
> and carry the merged series as a living document, incorporating corrections
> and clarifications mutually agreed upon by the IETF and ITU-T.
>
> If we choose the first course of action, we have the problem of what to do
> with any comments received during the review process.
>
> I would like the advice of the list on where to go from here.  Above all, we
> must preserve the benefits of having a single standard for the industry to
> work with.
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 16 10:29:55 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12792
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 16 Jun 2000 10:29:55 -0400 (EDT)
Received: from standards (47.234.32.16:1425) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7601C@standards.nortelnetworks.com>; Fri, 16 Jun 2000 10:20:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1197 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 10:20:29 -0400
Received: from qhars002.nortel.com (47.101.112.102:43277) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7601B@standards.nortelnetworks.com>; Fri, 16 Jun 2000
          10:20:29 -0400
Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com;
          Fri, 16 Jun 2000 15:29:03 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Fri, 16 Jun 2000 09:20:36 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPD1YCYJ>; Fri, 16 Jun 2000 09:28:59 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480AC7@zcard00g.ca.nortel.com>
Date:         Fri, 16 Jun 2000 09:28:58 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Last Call: draft-ietf-megaco-merged-01.txt
X-To:         Mart Nurmet <mart.nurmet@inet.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Darn!  I sent out my E-mail as yours arrived.  We'll have to see whether
other people have the same opinion.

> -----Original Message-----
> From: Mart Nurmet [SMTP:mart.nurmet@inet.com]
> Sent: Friday, June 16, 2000 10:19 AM
> To:   Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Last Call: draft-ietf-megaco-merged-01.txt
>
> Tom and all:
>
> The position here is to support  the currently approved documents so that
> we
> fulfill the ITU-T
> agreement and get it distributed.  It is appropriate to carry the merged
> series
> as a living document in this rapidly evolving technology. Then we need to
> incorporating corrections and clarifications mutually agreed upon by the
> IETF
> and ITU-T as they take place.  I'm sure that the ITU will also expedite
> those
> necessary inclusions after appropriate deliberations.  So we support your
> option
> #2.
>
> -Mart
>
> Tom-PT Taylor wrote:
>
> > The ITU-T today formally approved H.248.
> draft-ietf-megaco-merged-01.txt
> > provides the same text, obtained by merging
> > draft-ietf-megaco-protocol-08.txt and draft-ietf-megaco-errata-03.txt.
> > While the latter two have been approved for publication as
> standards-track
> > RFCs, I believe that the industry would find it more convenient to have
> a
> > single document to work from.
> >
> > We have two choices:
> >
> > (1) Run draft-ietf-megaco-merged-01.txt through Last Call and IESG
> review.
> > As well as providing a single document, this would fulfill  to the
> letter
> > our agreement with the ITU-T to republish H.248.
> >
> > (2) Consider the currently approved documents to fulfill the ITU-T
> agreement
> > and carry the merged series as a living document, incorporating
> corrections
> > and clarifications mutually agreed upon by the IETF and ITU-T.
> >
> > If we choose the first course of action, we have the problem of what to
> do
> > with any comments received during the review process.
> >
> > I would like the advice of the list on where to go from here.  Above
> all, we
> > must preserve the benefits of having a single standard for the industry
> to
> > work with.
> >
> > Tom Taylor
> > Phone and FAX: +1 613 736 0961
> > E-mail: taylor@nortelnetworks.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 16 10:43:15 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13259
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 16 Jun 2000 10:43:15 -0400 (EDT)
Received: from standards (47.234.32.16:1425) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76037@standards.nortelnetworks.com>; Fri, 16 Jun 2000 10:33:51 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1235 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 10:33:50 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB76036@standards.nortelnetworks.com>; Fri, 16 Jun 2000 10:33:50
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id KAA10685; Fri, 16 Jun 2000 10:42:37 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id KAA09056; Fri, 16 Jun 2000 10:42:39 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <MR1Y438C>; Fri, 16 Jun 2000 10:42:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67847A@whq-msgusr-02.fore.com>
Date:         Fri, 16 Jun 2000 10:42:36 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: VTOA MG & ATM signaling
X-To:         "Xiaotian Bian(Bill)" <bianxiaotian@HUAWEI.COM.CN>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The requirements, and the ATM package, say -- both!

The MGC can ask the MG to establish ATM connections.
The MG can also use proxy signalling, and then tell
the MG to use a VC it established.

Of course, being a little picky, I just described
the originating end.  No one can tell from the
originating end whether the entity it's talking to
at the terminating end is using proxy signalling!

Brian

> -----Original Message-----
> From: Xiaotian Bian(Bill) [mailto:bianxiaotian@HUAWEI.COM.CN]
> Sent: Friday, June 16, 2000 12:36 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: VTOA MG & ATM signaling
>
>
> Hi,
>    Imagine a VTOA MG carrying media streams on ATM network.
> If MGC sends
> it an  ADD command asking it to establish connections with
> peer VTOA MG,
> then ATM signaling should be applied. Is the origination or
> termination
> of ATM signaling done by VTOA MG or else,by MGC?
>   Thanks.
>
> Bill.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 16 11:48:09 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14930
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 16 Jun 2000 11:48:09 -0400 (EDT)
Received: from standards (47.234.32.16:1668) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7608D@standards.nortelnetworks.com>; Fri, 16 Jun 2000 11:38:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1289 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 11:38:44 -0400
Received: from relay1.alcatel.be (alc119.alcatel.be) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB76061@standards.nortelnetworks.com>; Fri, 16 Jun 2000
          11:28:44 -0400
Received: from btm16s.se.bel.alcatel.be (localhost [127.0.0.1]) by
          relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id e5GFbej12236 for
          <MEGACO@standards.nortelnetworks.com>; Fri, 16 Jun 2000 17:37:40
          +0200 (MET DST)
Received: from alcatel.be (btmpfc [138.203.32.78]) by btm16s.se.bel.alcatel.be
          (8.8.8+Sun/8.8.8+SUN) with ESMTP id RAA16119 for
          <MEGACO@standards.nortelnetworks.com>; Fri, 16 Jun 2000 17:37:35
          +0200 (MET DST)
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <394A49BE.EEDC5DB8@alcatel.be>
Date:         Fri, 16 Jun 2000 17:37:35 +0200
Reply-To: Nicolas Dramais <nicolas.dramais@ALCATEL.BE>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Nicolas Dramais <nicolas.dramais@ALCATEL.BE>
Organization: Alcatel
Subject:      draft-ietf-megaco-merged-01.txt, section E.6.2, TerminationMethod
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Just a question over a possible editorial error:

draft-ietf-megaco-merged-01.txt in section E.6.2 about the Termination
Method, one can read :

Termination Method
        ------------------
        ParameterID:    Meth (0x0003)

        Type: enumeration

        Possible values:
                "UM" (0x0001) Unambiguous match
                "PM"  (0x0002) Partial match, completion by timer
                expiry or unmatched event
                "FM"  (0x0003) Full match, completion by timer expiry
                or unmatched event


My understanding is that one should suppress the "or unmatched event"
statement for the "FM" TerminationMethod so that we get the following
possible values :

Possible values:
                "UM" (0x0001) Unambiguous match
                "PM"  (0x0002) Partial match, completion by timer
                expiry or unmatched event
                "FM"  (0x0003) Full match, completion by timer expiry

Do you confirm this copy/paste editorial error ?


Thanks,
Nicolas Dramais - ALCATEL, Antwerpen, Belgium.
phone: +32 3 241 59 13
fax  : +32 3 240 99 62


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 16 12:16:42 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15691
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 16 Jun 2000 12:16:41 -0400 (EDT)
Received: from standards (47.234.32.16:4268) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7609F@standards.nortelnetworks.com>; Fri, 16 Jun 2000 12:07:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1359 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 12:07:10 -0400
Received: from qhars002.nortel.com (47.101.112.102:54000) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7609E@standards.nortelnetworks.com>; Fri, 16 Jun 2000
          12:07:05 -0400
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          qhars002.nortel.com; Fri, 16 Jun 2000 17:15:44 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Fri, 16 Jun 2000 12:15:18 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPQC57F0>; Fri, 16 Jun 2000 12:15:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFD7AE.0CC7B35E"
Message-ID:  <28560036253BD41191A10000F8BCBD11480ACC@zcard00g.ca.nortel.com>
Date:         Fri, 16 Jun 2000 12:15:13 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: draft-ietf-megaco-merged-01.txt, section E.6.2,
              TerminationMe thod
X-To:         Nicolas Dramais <nicolas.dramais@ALCATEL.BE>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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_01BFD7AE.0CC7B35E
Content-Type: text/plain

Actually, you can get a full match terminated by an unmatched event.  An
example would be a pattern like "x." terminated by detection of "#".

> -----Original Message-----
> From: Nicolas Dramais [SMTP:nicolas.dramais@ALCATEL.BE]
> Sent: Friday, June 16, 2000 11:38 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      draft-ietf-megaco-merged-01.txt, section E.6.2,
> TerminationMethod
>
> Just a question over a possible editorial error:
>
> draft-ietf-megaco-merged-01.txt in section E.6.2 about the Termination
> Method, one can read :
>
> Termination Method
>         ------------------
>         ParameterID:    Meth (0x0003)
>
>         Type: enumeration
>
>         Possible values:
>                 "UM" (0x0001) Unambiguous match
>                 "PM"  (0x0002) Partial match, completion by timer
>                 expiry or unmatched event
>                 "FM"  (0x0003) Full match, completion by timer expiry
>                 or unmatched event
>
>
> My understanding is that one should suppress the "or unmatched event"
> statement for the "FM" TerminationMethod so that we get the following
> possible values :
>
> Possible values:
>                 "UM" (0x0001) Unambiguous match
>                 "PM"  (0x0002) Partial match, completion by timer
>                 expiry or unmatched event
>                 "FM"  (0x0003) Full match, completion by timer expiry
>
> Do you confirm this copy/paste editorial error ?
>
>
> Thanks,
> Nicolas Dramais - ALCATEL, Antwerpen, Belgium.
> phone: +32 3 241 59 13
> fax  : +32 3 240 99 62

------_=_NextPart_001_01BFD7AE.0CC7B35E
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.2651.65">
<TITLE>RE: draft-ietf-megaco-merged-01.txt, section E.6.2, =
TerminationMethod</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Actually, you can =
get a full match terminated by an unmatched event.&nbsp; An example =
would be a pattern like &quot;x.&quot; terminated by detection of =
&quot;#&quot;.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Nicolas Dramais =
[SMTP:nicolas.dramais@ALCATEL.BE]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, June 16, 2000 11:38 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">draft-ietf-megaco-merged-01.txt, =
section E.6.2, TerminationMethod</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Just a question over a possible =
editorial error:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">draft-ietf-megaco-merged-01.txt in =
section E.6.2 about the Termination</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Method, one can read :</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Termination Method</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
------------------</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ParameterID:&nbsp;&nbsp;&nbsp; Meth (0x0003)</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Type: =
enumeration</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Possible =
values:</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;UM&quot; (0x0001) Unambiguous =
match</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;PM&quot;&nbsp; (0x0002) Partial =
match, completion by timer</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; expiry or unmatched event</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FM&quot;&nbsp; (0x0003) Full =
match, completion by timer expiry</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; or unmatched event</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">My understanding is that one should =
suppress the &quot;or unmatched event&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">statement for the &quot;FM&quot; =
TerminationMethod so that we get the following</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">possible values :</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Possible values:</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;UM&quot; (0x0001) Unambiguous =
match</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;PM&quot;&nbsp; (0x0002) Partial =
match, completion by timer</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; expiry or unmatched event</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FM&quot;&nbsp; (0x0003) Full =
match, completion by timer expiry</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Do you confirm this copy/paste =
editorial error ?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Nicolas Dramais - ALCATEL, Antwerpen, =
Belgium.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">phone: +32 3 241 59 13</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">fax&nbsp; : +32 3 240 99 62</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFD7AE.0CC7B35E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 16 13:08:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17371
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 16 Jun 2000 13:08:09 -0400 (EDT)
Received: from standards (47.234.32.16:1839) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB760BE@standards.nortelnetworks.com>; Fri, 16 Jun 2000 12:58:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1400 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 12:58:34 -0400
Received: from ns-inetext.inet.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB760BD@standards.nortelnetworks.com>; Fri, 16 Jun 2000 12:58:34
          -0400
Received: from harpo.inetint.com (harpo [172.16.99.60]) by ns-inetext.inet.com
          (8.9.2/8.9.2) with ESMTP id MAA27960 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 16 Jun 2000 12:06:20
          -0500 (CDT)
Received: from inet.com ([172.16.63.49]) by harpo.inetint.com (Netscape
          Messaging Server 3.6)  with ESMTP id AAA74A6; Fri, 16 Jun 2000
          12:12:32 -0500
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480ABA@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <394A5E94.C2F78FAA@inet.com>
Date:         Fri, 16 Jun 2000 12:06:28 -0500
Reply-To: Mart Nurmet <mart.nurmet@INET.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Mart Nurmet <mart.nurmet@INET.COM>
Organization: Inet - Staff Engineer
Subject:      Re: Rechartering
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I would support Rechartering -

One action we might add, is to formulate a process of H.248 update submissions
to the ITU-T on a quarterly basis.

-Mart

Tom-PT Taylor wrote:

> At the Adelaide meeting, attendees favoured continuance of the Working Group
> in order to ensure an IETF voice in the evolution of the Megaco/H.248
> protocol.  Since we have accomplished all of our original charter except for
> the MIBs, it is time to think about a new charter.  I would propose that
> this charter contain the following elements:
>
> (1) an introduction including a general definition of a Media Gateway and a
> description of work accomplished so far
>
> (2) a general description of the work to be carried out by the Working Group
> over the next year
>     -- identification of errors and clarifications required to the base
> protocol
>     -- review and standardization of additional packages
>     -- completion of the Megaco/H.248 MIBs
>     -- (suggested in Oslo) completion of a document giving the complete
> picture of the MIBs required to manage a Media Gateway

>    -- cooperation with MMUSIC on the detailed extensions to SDP required to
> support IP transport of media

>     -- review of proposed Megaco/H.248 profiles, upon request from other
> bodies
>     -- consideration of possible extensions to the base protocol all in
> cooperation with the ITU-T and other standards bodies and fora.
>
> (3) a detailed listing of all work currently in hand.
>
> Would the list care to comment on this proposal?  Do we agree to recharter,
> and does (2) have the right list of work items?
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Jun 17 13:28:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20087
	for <megaco-archive@LISTS.IETF.ORG>; Sat, 17 Jun 2000 13:28:01 -0400 (EDT)
Received: from standards (47.234.32.16:1371) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76307@standards.nortelnetworks.com>; Sat, 17 Jun 2000 13:18:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2151 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 17 Jun 2000 13:18:10 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB76304@standards.nortelnetworks.com>; Sat, 17 Jun 2000 13:08:10
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          MAA29499 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 17 Jun 2000
          12:15:12 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay1.usa.alcatel.com
          [143.209.238.6]) by fw7 via smap (V2.1) id xma029467; Sat, 17 Jun 00
          12:14:28 -0500
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id MAA12400 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 17 Jun 2000 12:13:22
          -0500 (CDT)
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id MAA23250 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 17
          Jun 2000 12:12:11 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA22941
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 17 Jun 2000 12:12:10
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------E35E0F019B4B07E70ED41DF2"
Message-ID:  <394BB169.B541341F@usa.alcatel.com>
Date:         Sat, 17 Jun 2000 12:12:09 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Tonegen Package
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------E35E0F019B4B07E70ED41DF2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi

Can soneone help me w/the syntax involving tonegen Package and cg
package?

Say I want to use tonegen/pt with tl (tone id list) of cg/rt and cg/cw
(just as an example)

Signals { tonegen/pt {tl = [cg/rt, cg/cw], ind = 100} }

Does this look right?

Can someone show a real world scenario and syntax on how tonegen package
is used?

In the description of tonegen, "interdigit" time delay was given as the
definition for "ind".
What does "interdigit time delay" really mean here?
Later in Section E.3.3 "ind" is defined as inter signal duration which
seems to make
some sense of how "ind" is supposed to be used.

---
Since Call Progress Tones Generator (cg) Package extends tonegen
package,
it does not really mean that you have to use the following syntax to use
cg:
        Signals {tonegen/pt {tl = cg/dt}}

One can just do        Signals{cg/dt}

----
E.7.3 under "Additional Values"
          "dt (0x0030) is defined as a tone id for playtone"

Does this imply one can do the following?
             Signals {tonegen/pt {tl = dt}}

In E.3.3 "tl" is defined as a list of tone ids.
Is tone id "dt" or "cg/dt"?

Thanks
Chuong


--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------E35E0F019B4B07E70ED41DF2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi
<p>Can soneone help me w/the syntax involving tonegen Package and cg package?
<p>Say I&nbsp;want to use tonegen/pt with tl (tone id list) of cg/rt and
cg/cw&nbsp; (just as an example)
<p>Signals { tonegen/pt {tl = [cg/rt, cg/cw], ind = 100} }
<p>Does this look right?
<p>Can someone show a real world scenario and syntax on how tonegen package
is used?
<p>In the description of tonegen, "interdigit" time delay was given as
the definition for "ind".
<br>What does "interdigit time delay" really mean here?
<br>Later in Section E.3.3 "ind" is defined as inter signal duration which
seems to make
<br>some sense of how "ind" is supposed to be used.
<p>---
<br>Since Call Progress Tones Generator (cg) Package extends tonegen package,
<br>it does not really mean that you have to use the following syntax to
use cg:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Signals {tonegen/pt {tl
= cg/dt}}
<p>One can just do&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Signals{cg/dt}
<p>----
<br>E.7.3 under "Additional Values"
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "dt (0x0030)
is defined as a tone id for playtone"
<p>Does this imply one can do the following?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Signals {tonegen/pt {tl = dt}}
<p>In E.3.3 "tl" is defined as a list of tone ids.
<br>Is tone id "dt" or "cg/dt"?
<p>Thanks
<br>Chuong
<br>&nbsp;
<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------E35E0F019B4B07E70ED41DF2--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 19 02:14:33 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27170
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 19 Jun 2000 02:14:33 -0400 (EDT)
Received: from standards (47.234.32.16:3644) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB765CA@standards.nortelnetworks.com>; Mon, 19 Jun 2000 2:04:41 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3054 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 02:04:41 -0400
Received: from mail.huawei.com.cn (202.96.135.132:58402) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB765C9@standards.nortelnetworks.com>; Mon, 19 Jun 2000
          2:04:40 -0400
Received: from huawei.com.cn ([10.105.29.194]) by mail.huawei.com.cn (Netscape
          Mail Server v2.02) with ESMTP id AAA18370; Mon, 19 Jun 2000 14:14:37
          +0800
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF67847A@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <394DB9ED.9106126C@huawei.com.cn>
Date:         Mon, 19 Jun 2000 14:13:01 +0800
Reply-To: "Xiaotian Bian(Bill)" <bianxiaotian@HUAWEI.COM.CN>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Xiaotian Bian(Bill)" <bianxiaotian@HUAWEI.COM.CN>
Subject:      Re: VTOA MG & ATM signaling
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Thanks.
That's to say, Sigtran signalling "backhaul" is used in case of ATM
signaling on VTOA MG,as in case of ISDN Q.931 on MG. Is that correct?


Rosen, Brian wrote:

> The requirements, and the ATM package, say -- both!
>
> The MGC can ask the MG to establish ATM connections.
> The MG can also use proxy signalling, and then tell
> the MG to use a VC it established.
>
> Of course, being a little picky, I just described
> the originating end.  No one can tell from the
> originating end whether the entity it's talking to
> at the terminating end is using proxy signalling!
>
> Brian
>
> > -----Original Message-----
> > From: Xiaotian Bian(Bill) [mailto:bianxiaotian@HUAWEI.COM.CN]
> > Sent: Friday, June 16, 2000 12:36 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: VTOA MG & ATM signaling
> >
> >
> > Hi,
> >    Imagine a VTOA MG carrying media streams on ATM network.
> > If MGC sends
> > it an  ADD command asking it to establish connections with
> > peer VTOA MG,
> > then ATM signaling should be applied. Is the origination or
> > termination
> > of ATM signaling done by VTOA MG or else,by MGC?
> >   Thanks.
> >
> > Bill.
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 19 03:23:30 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27451
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 19 Jun 2000 03:23:30 -0400 (EDT)
Received: from standards (47.234.32.16:2341) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7662E@standards.nortelnetworks.com>; Mon, 19 Jun 2000 3:13:51 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3172 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 03:13:51 -0400
Received: from mars.hss.co.in (202.54.26.197:53274) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7662D@standards.nortelnetworks.com>; Mon, 19 Jun 2000
          3:13:49 -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          mars.hss.co.in (8.10.0/8.10.0) with SMTP id e5J7OPv13710 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 19 Jun 2000 12:54:26
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256903.0027C4CC ; Mon, 19 Jun 2000 12:44:22 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256903.0027C35F.00@sandesh.hss.hns.com>
Date:         Mon, 19 Jun 2000 12:48:53 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Digit Map de-activatioin.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The digit map get activated while the events descriptor which invoked it is
active and it has not completed ( section 7.1.14.4 ).
There is some ambiguity regarding the cases where a digit map completes. The
third bullet indicates that when "an event has
been detected such that a match to a complete alternative event sequence of the
digitmap will be impossible no matter what
additional events are received", does this include events like ON-HOOK or any
other event present in the event descriptor?
If  this is not the case, what is the behavior at MG when the digit map is
active and user goes ON-HOOK, after dialling some digits?

-Madhu Babu.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 19 08:34:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02310
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 19 Jun 2000 08:34:55 -0400 (EDT)
Received: from standards (47.234.32.16:1301) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76716@standards.nortelnetworks.com>; Mon, 19 Jun 2000 8:25:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3471 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 08:25:11 -0400
Received: from qhars002.nortel.com (47.101.112.102:44557) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB76715@standards.nortelnetworks.com>; Mon, 19 Jun 2000
          8:25:11 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Mon, 19 Jun 2000 13:31:27 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Mon, 19 Jun 2000 07:29:33 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPD1Y89P>; Mon, 19 Jun 2000 07:30:30 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480AD8@zcard00g.ca.nortel.com>
Date:         Mon, 19 Jun 2000 07:30:29 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: VTOA MG & ATM signaling
X-To:         "Xiaotian Bian(Bill)" <bianxiaotian@HUAWEI.COM.CN>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a possibility too, but we are actually working on changes to SDP
which would allow the ATM signalling parameters to be embedded in the Local
and Remote descriptors.  We view ATM signalling as a matter of bearer
control, logically equivalent to providing IP address, port, diffserv label,
etc.

> -----Original Message-----
> From: Xiaotian Bian(Bill) [SMTP:bianxiaotian@HUAWEI.COM.CN]
> Sent: Monday, June 19, 2000 2:13 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: VTOA MG & ATM signaling
>
> Thanks.
> That's to say, Sigtran signalling "backhaul" is used in case of ATM
> signaling on VTOA MG,as in case of ISDN Q.931 on MG. Is that correct?
>
>
> Rosen, Brian wrote:
>
> > The requirements, and the ATM package, say -- both!
> >
> > The MGC can ask the MG to establish ATM connections.
> > The MG can also use proxy signalling, and then tell
> > the MG to use a VC it established.
> >
> > Of course, being a little picky, I just described
> > the originating end.  No one can tell from the
> > originating end whether the entity it's talking to
> > at the terminating end is using proxy signalling!
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Xiaotian Bian(Bill) [mailto:bianxiaotian@HUAWEI.COM.CN]
> > > Sent: Friday, June 16, 2000 12:36 AM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: VTOA MG & ATM signaling
> > >
> > >
> > > Hi,
> > >    Imagine a VTOA MG carrying media streams on ATM network.
> > > If MGC sends
> > > it an  ADD command asking it to establish connections with
> > > peer VTOA MG,
> > > then ATM signaling should be applied. Is the origination or
> > > termination
> > > of ATM signaling done by VTOA MG or else,by MGC?
> > >   Thanks.
> > >
> > > Bill.
> > >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 19 08:45:53 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02659
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 19 Jun 2000 08:45:52 -0400 (EDT)
Received: from standards (47.234.32.16:1301) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76733@standards.nortelnetworks.com>; Mon, 19 Jun 2000 8:36:23 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3509 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 08:36:23 -0400
Received: from qhars002.nortel.com (47.101.112.102:46487) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB76732@standards.nortelnetworks.com>; Mon, 19 Jun 2000
          8:36:23 -0400
Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com;
          Mon, 19 Jun 2000 13:34:24 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Mon, 19 Jun 2000 07:25:58 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPD1Y9BJ>; Mon, 19 Jun 2000 07:34:20 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480ADA@zcard00g.ca.nortel.com>
Date:         Mon, 19 Jun 2000 07:34:19 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      FW: Digit Map de-activatioin.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Forgot to copy the list.

> -----Original Message-----
> From: Taylor, Tom-PT [NORSE:B901:EXCH]
> Sent: Monday, June 19, 2000 8:33 AM
> To:   bmbabu@HSS.HNS.COM
> Subject:      RE: Digit Map de-activatioin.
>
> Your question assumes the on-hook event has no embedded Events descriptor
> and the MGC does not react to the on-hook by providing a new Events
> descriptor.  Under those assumptions, the digit map will time out and
> report completion accordingly.
>
>       -----Original Message-----
>       From:   Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
>       Sent:   Monday, June 19, 2000 3:19 AM
>       To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject:        Digit Map de-activatioin.
>
>       The digit map get activated while the events descriptor which
> invoked it is
>       active and it has not completed ( section 7.1.14.4 ).
>       There is some ambiguity regarding the cases where a digit map
> completes. The
>       third bullet indicates that when "an event has
>       been detected such that a match to a complete alternative event
> sequence of the
>       digitmap will be impossible no matter what
>       additional events are received", does this include events like
> ON-HOOK or any
>       other event present in the event descriptor?
>       If  this is not the case, what is the behavior at MG when the digit
> map is
>       active and user goes ON-HOOK, after dialling some digits?
>
>       -Madhu Babu.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 19 12:28:04 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13597
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 19 Jun 2000 12:28:04 -0400 (EDT)
Received: from standards (47.234.32.16:2162) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB767BE@standards.nortelnetworks.com>; Mon, 19 Jun 2000 12:18:24 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3679 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 12:18:24 -0400
Received: from qhars002.nortel.com (47.101.112.102:44860) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB767BA@standards.nortelnetworks.com>; Mon, 19 Jun 2000
          12:08:24 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Mon, 19 Jun 2000 17:16:35 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Mon, 19 Jun 2000 11:15:05 -0500
Received: from zrtpd006.us.nortel.com ([47.28.160.175]) by
          zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id MPD1Z2D7; Mon, 19 Jun 2000 11:16:01
          -0500
Received: from americasm01.nt.com (pnc1d05f.us.nortel.com [47.142.209.97]) by
          zrtpd006.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id L13ZDFDN; Mon, 19 Jun 2000 12:16:00
          -0400
X-Sybari-Space: 00000000 00000000 00000000
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <394E4799.3636B5DA@americasm01.nt.com>
Date:         Mon, 19 Jun 2000 12:17:29 -0400
Reply-To: Christopher Rigano <crigano@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christopher Rigano <crigano@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      MEGACO SECURITY
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello,
<p>How is security implemented as defined in Section 7. Security,&nbsp;
in the MEGACO Architecture and Requirements document? Does MEGACO depend
on its carrier (e.g., for IP IPSec, ATM ATM-NIC Security) or does it implement
its own security? Are they any concrete implementation examples or products
I could refer to?
<p>Best regards,
<p>Christopher</html>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 19 12:36:24 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13966
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 19 Jun 2000 12:36:23 -0400 (EDT)
Received: from standards (47.234.32.16:2162) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB767D1@standards.nortelnetworks.com>; Mon, 19 Jun 2000 12:26:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3707 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 12:26:48 -0400
Received: from qhars002.nortel.com (47.101.112.102:46765) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB767D0@standards.nortelnetworks.com>; Mon, 19 Jun 2000
          12:26:48 -0400
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          qhars002.nortel.com; Mon, 19 Jun 2000 17:34:45 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Mon, 19 Jun 2000 12:33:10 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPQC68BW>; Mon, 19 Jun 2000 12:33:08 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480AE2@zcard00g.ca.nortel.com>
Date:         Mon, 19 Jun 2000 12:33:06 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: MEGACO SECURITY
X-To:         Christopher Rigano <crigano@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Megaco depends on transport security -- it does not implement its own
security except as an interim measure until IPSEC is available in the
development environment.

> -----Original Message-----
> From: Rigano, Christopher [NCWIN:3H14:EXCH]
> Sent: Monday, June 19, 2000 12:17 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      MEGACO SECURITY
>
> Hello,
>
> How is security implemented as defined in Section 7. Security,  in the
> MEGACO Architecture and Requirements document? Does MEGACO depend on its
> carrier (e.g., for IP IPSec, ATM ATM-NIC Security) or does it implement
> its own security? Are they any concrete implementation examples or
> products I could refer to?
>
> Best regards,
>
> Christopher


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 19 13:53:48 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18548
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 19 Jun 2000 13:53:48 -0400 (EDT)
Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB767FB@standards.nortelnetworks.com>; Mon, 19 Jun 2000 13:44:06 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0054 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 13:44:06 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB767FA@standards.nortelnetworks.com>; Mon, 19 Jun 2000 13:44:05
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id NAA12050; Mon, 19 Jun 2000 13:53:05 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id NAA24730; Mon, 19 Jun 2000 13:53:04 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <NB7J876D>; Mon, 19 Jun 2000 13:53:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CFC99780@whq-msgusr-02.fore.com>
Date:         Mon, 19 Jun 2000 13:53:01 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: VTOA MG & ATM signaling
X-To:         "Xiaotian Bian(Bill)" <bianxiaotian@HUAWEI.COM.CN>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Megaco doesn't specify how backhaul is done.  SCTP (SIGTRAN) is
certainly a good choice if you are using IP.  There are other
alternatives if you are on an ATM network.

Brian

> -----Original Message-----
> From: Xiaotian Bian(Bill) [mailto:bianxiaotian@HUAWEI.COM.CN]
> Sent: Monday, June 19, 2000 2:13 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: VTOA MG & ATM signaling
>
>
> Thanks.
> That's to say, Sigtran signalling "backhaul" is used in case of ATM
> signaling on VTOA MG,as in case of ISDN Q.931 on MG. Is that correct?
>
>
> Rosen, Brian wrote:
>
> > The requirements, and the ATM package, say -- both!
> >
> > The MGC can ask the MG to establish ATM connections.
> > The MG can also use proxy signalling, and then tell
> > the MG to use a VC it established.
> >
> > Of course, being a little picky, I just described
> > the originating end.  No one can tell from the
> > originating end whether the entity it's talking to
> > at the terminating end is using proxy signalling!
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Xiaotian Bian(Bill) [mailto:bianxiaotian@HUAWEI.COM.CN]
> > > Sent: Friday, June 16, 2000 12:36 AM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: VTOA MG & ATM signaling
> > >
> > >
> > > Hi,
> > >    Imagine a VTOA MG carrying media streams on ATM network.
> > > If MGC sends
> > > it an  ADD command asking it to establish connections with
> > > peer VTOA MG,
> > > then ATM signaling should be applied. Is the origination or
> > > termination
> > > of ATM signaling done by VTOA MG or else,by MGC?
> > >   Thanks.
> > >
> > > Bill.
> > >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 19 15:02:34 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20485
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 19 Jun 2000 15:02:33 -0400 (EDT)
Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76907@standards.nortelnetworks.com>; Mon, 19 Jun 2000 14:48:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0380 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 14:48:55 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB76903@standards.nortelnetworks.com>; Mon, 19 Jun 2000 14:48:55
          -0400
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com
          [171.68.116.221]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id
          LAA08135; Mon, 19 Jun 2000 11:57:49 -0700 (PDT)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.3.1.2.20000619142452.00ab1220@dogwood.cisco.com>
Date:         Mon, 19 Jun 2000 14:49:10 -0400
Reply-To: Chip Sharp <chsharp@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chip Sharp <chsharp@CISCO.COM>
Subject:      Re: Rechartering
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <28560036253BD41191A10000F8BCBD11480ABA@zcard00g.ca.nortel. com>

In general, I prefer specific milestones and work items in a charter.  The
below looks too much like a Question in ITU.  If the WG cannot define
specific work items and deliverables, it should go dormant (i.e., mail list
only) until time to go to Draft Standard when it will have to deal with
removing all the options that don't have multiple interoperable
implementations. :-)

The current work items (i.e., MIBs) should be completed before taking on
other work.

Specific comments in-line:

At 03:37 PM 6/15/00 -0500, Tom-PT Taylor wrote:
>At the Adelaide meeting, attendees favoured continuance of the Working Group
>in order to ensure an IETF voice in the evolution of the Megaco/H.248
>protocol.  Since we have accomplished all of our original charter except for
>the MIBs, it is time to think about a new charter.  I would propose that
>this charter contain the following elements:
>
>(1) an introduction including a general definition of a Media Gateway and a
>description of work accomplished so far

This should be a non-starter. ITU SG15 is already attempting to do this in
its TIGIN work.  Also, I don't think IETF should start defining equipment.

Also, an IETF Working Group charter should not have a work item of
describing work done so far.


>(2) a general description of the work to be carried out by the Working Group
>over the next year
>     -- identification of errors and clarifications required to the base
>protocol

This could be done under the current charter by going dormant (i.e., mail
list only) and collecting bugs, etc. to be taken into account when moving
to Draft Standard.  The WG can be reactivated when it decides the protocol
is ready to move to DS.

>     -- review and standardization of additional packages

This should be dealt with via a BOF and possible chartering of a new WG for
additional packages.  In any case, specific packages should be identified
with enough interest shown to justify the work.

>     -- completion of the Megaco/H.248 MIBs

This falls under the current charter which is still to be
completed.  Perhaps the WG should focus on completing these work items
before taking on more work.

>     -- (suggested in Oslo) completion of a document giving the complete
>picture of the MIBs required to manage a Media Gateway

It isn't clear what this means or if it is needed.  Is this intended as an
operational document?

>     -- cooperation with MMUSIC on the detailed extensions to SDP required to
>support IP transport of media

One group needs to take ownership of this.  I believe MMUSIC is doing this
now.  There is no need for megaco to exist in order to cooperate with
MMUSIC.  Everyone in megaco is free to join the relevant mail lists and
work on the relevant items without the existence of megaco.

>     -- review of proposed Megaco/H.248 profiles, upon request from other
>bodies

This is terribly open-ended.  Need to identify particular work items and
decide on a case-by-case basis.  I suspect if there is interest in a
profile, a BOF should be formed and a decision need to be made on
chartering a WG to define a profile. Keeping a WG open in case something
happens is not SOP.

>     -- consideration of possible extensions to the base protocol
>   all in cooperation with the ITU-T and other standards bodies and fora.

Same as previous comment.


>(3) a detailed listing of all work currently in hand.

The current charter should be updated to mark "done" what has been
finished.  This isn't a work item.


>Would the list care to comment on this proposal?  Do we agree to recharter,
>and does (2) have the right list of work items?

Right now I don't see a need to recharter and certainly not with the above
work items.


>Tom Taylor
>Phone and FAX: +1 613 736 0961
>E-mail: taylor@nortelnetworks.com


-------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Change it.
http://www.netaid.org
-------------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 19 16:40:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23061
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 19 Jun 2000 16:40:19 -0400 (EDT)
Received: from standards (47.234.32.16:2263) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76975@standards.nortelnetworks.com>; Mon, 19 Jun 2000 16:30:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0519 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 16:30:45 -0400
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se)
          by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with
          SMTP id <0.FFB76972@standards.nortelnetworks.com>; Mon, 19 Jun 2000
          16:20:45 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP
          id e5JKThs16433; Mon, 19 Jun 2000 22:29:43 +0200 (MET DST)
Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by
          al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id
          WAA03585; Mon, 19 Jun 2000 22:29:43 +0200 (MET DST)
Received: from ericsson.com (arael25m119.ericsson.se [130.100.251.248]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          WAA29912; Mon, 19 Jun 2000 22:29:42 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480ABA@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <394DCD66.8AE66665@ericsson.com>
Date:         Mon, 19 Jun 2000 17:36:06 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Rechartering
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

I think this covers the discussions that we had at the Adeliade meeting
earlier in the year.

Cheers, Christian

Tom-PT Taylor wrote:
>
> At the Adelaide meeting, attendees favoured continuance of the Working Group
> in order to ensure an IETF voice in the evolution of the Megaco/H.248
> protocol.  Since we have accomplished all of our original charter except for
> the MIBs, it is time to think about a new charter.  I would propose that
> this charter contain the following elements:
>
> (1) an introduction including a general definition of a Media Gateway and a
> description of work accomplished so far
>
> (2) a general description of the work to be carried out by the Working Group
> over the next year
>     -- identification of errors and clarifications required to the base
> protocol
>     -- review and standardization of additional packages
>     -- completion of the Megaco/H.248 MIBs
>     -- (suggested in Oslo) completion of a document giving the complete
> picture of the MIBs required to manage a Media Gateway
>     -- cooperation with MMUSIC on the detailed extensions to SDP required to
> support IP transport of media
>     -- review of proposed Megaco/H.248 profiles, upon request from other
> bodies
>     -- consideration of possible extensions to the base protocol
>   all in cooperation with the ITU-T and other standards bodies and fora.
>
> (3) a detailed listing of all work currently in hand.
>
> Would the list care to comment on this proposal?  Do we agree to recharter,
> and does (2) have the right list of work items?
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 20 00:45:09 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01603
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 20 Jun 2000 00:45:09 -0400 (EDT)
Received: from standards (47.234.32.16:2607) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76B98@standards.nortelnetworks.com>; Tue, 20 Jun 2000 0:35:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1260 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 20 Jun 2000 00:35:34 -0400
Received: from unknown (ip76.atlanta11.ga.pub-ip.psi.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB76B96@standards.nortelnetworks.com>; Tue, 20 Jun 2000
          0:25:33 -0400
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <243.231638.257800@unknown>
Date:         Tue, 20 Jun 2000 00:35:34 -0400
Reply-To: Whiteer6drts@aol.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: vhjdty809y67853@aol.com
Subject:      Toner Cartridges for your  Printers
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

D&J PRINTING CORPORATION
  3103 LEXINGTON FARMS DR
  ALPHARETTA,  GA  30004
    (770) 619-0716

     --LASER, FAX AND COPIER PRINTER TONER CARTRIDGES--

*WE ACCEPT GOVERNMENT, SCHOOL AND UNIVERSITY PURCHASE ORDERS*


CHECK OUT OUR NEW CARTRIDGE PRICES:


APPLE

  LASER WRITER PRO 600 OR 16/600                $65
  LASER WRITER SELECT 300, 310, 360             $65
  LASER WRITER 300, 320                         $54
  LASER WRITER LS, NT, 2NTX, 2F, 2G AND 2SC     $54
  LASER WRITER 12/640                           $75

HEWLETT PACKARD


  LASERJET SERIES 2, 3 AND 3D (95A)             $49
  LASERJET SERIES 2P AND 3P (75A)               $54
  LASERJET SERIES 3SI AND 4SI (91A)             $75
  LASERJET SERIES 4L AND 4P                     $45
  LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A)        $55
  LASERJET SERIES 4000 HIGH YIELD (27X)         $95
  LASERJET SERIES 4V                            $90
  LASERJET SERIES 5SI, 8000                     $95
  LASERJET SERIES 5L AND 6L                     $49
  LASERJET SERIES 5P, 5MP, 6P, 6MP              $59
  LASERJET SERIES 5000 (29A)                    $125
  LASERJET SERIES 1100 (92A)                    $50
  LASERJET SERIES 2100 (96A)                    $80
  LASERJET SERIES 8100 (82X)                    $135


HEWLETT PACKARD LASERFAX

  LASERFAX 500, 700, FX1                        $57
  LASERFAX 5000, 7000, FX2                      $57
  LASERFAX FX3                                  $67
  LASERFAX FX4                                  $77






LEXMARK

  OPTRA 4019, 4029 HIGH YIELD                   $130
  OPTRA R, 4039, 4049 HIGH YIELD                $135
  OPTRA S, 4059 HIGH YIELD                      $135
  OPTRA E                                       $59
  OPTRA N                                       $110


EPSON

  EPL-7000, 8000                                $100
  EPL-1000, 1500                                $100


CANON

  LBP-430                                       $49
  LBP-460, 465                                  $59
  LBP-8 II                                      $54
  LBP-LX                                        $54
  LBP-MX                                        $95
  LBP-AX                                        $49
  LBP-EX                                        $59
  LBP-SX                                        $49
  LBP-BX                                        $95
  LBP-PX                                        $49
  LBP-WX                                        $95
  LBP-VX                                        $59
  CANON FAX L700 THRU L790 (FX1)                $59
  CANON FAX L5000 THRU L7000 (FX2)              $59


CANON COPIERS

  PC 3, 6RE, 7, 11 (A30)                        $69
  PC 320 THRU 780 (E40)                         $85


NEC

  SERIES 2 LASER MODEL 90, 95                   $105






PLEASE NOTE:

 * WE SHIP UPS GROUND.  ADD $6.50 FOR SHIPPING AND HANDLING
 * WE ACCEPT ALL MAJOR CREDIT CARDS OR "COD" ORDERS.
 * COD CHECK ORDERS ADD $3.50 TO YOUR SHIPPING COST.
 * OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS.
 * OUR STANDARD MERCHANDISE REPLACEMENT POLICY IS NET 90 DAYS.
 * WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS.
 * WE DO NOT CARRY: BROTHER, MINOLTA, KYOSERA, PANASONIC, XEROX,
                    FUJITSU, OKIDATA OR SHARP PRODUCTS.
 * WE ALSO DO NOT CARRY: COLOR PRINTER SUPPLIES, DESKJET/INKJET
                    OR BUBBLEJET SUPPLIES.
 * WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS.


           -PLACE YOUR ORDER AS FOLLOWS-

1) BY PHONE (770) 619-0716
2) BY MAIL:  D AND J PRINTING CORPORATION
             3103 LEXINGTON FARMS DR
             ALPHARETTA,   GA  30004

 INCLUDE THE FOLLOWING INFORMATION WHEN YOU PLACE YOUR ORDER:

1) YOUR PHONE NUMBER
2) COMPANY NAME
3) SHIPPING ADDRESS
4) CONTACT NAME
5) ITEMS NEEDED WITH QUANTITIES
6) METHOD OF PAYMENT (COD OR CREDIT CARD)
7) CREDIT CARD NUMBER WITH EXPIRATION DATE
**** IF YOU ARE ORDERING BY PURCHASE ORDER, PLEASE INCLUDE A
     SEPARATE BILLING ADDRESS AND SHIPPING ADDRESS WHEN NEEDED.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 20 02:08:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14077
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 20 Jun 2000 02:08:21 -0400 (EDT)
Received: from standards (47.234.32.16:2836) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76BBF@standards.nortelnetworks.com>; Tue, 20 Jun 2000 1:58:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1314 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 20 Jun 2000 01:58:49 -0400
Received: from mail.pi.se by standards.nortelnetworks.com (LSMTP for Windows NT
          v1.1b) with SMTP id <0.FFB76BBE@standards.nortelnetworks.com>; Tue,
          20 Jun 2000 1:58:49 -0400
Received: from pigpen (ap01-110.mp.pi.se [195.7.86.110]) by mail.pi.se
          (8.8.8/8.8.8) with SMTP id IAA07609; Tue, 20 Jun 2000 08:07:51 +0200
          (MET DST)
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
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.2919.6600
Message-ID:  <NDBBKHLAILCBFIHAKIKPIEJBCIAA.gunnar.hellstrom@omnitor.se>
Date:         Tue, 20 Jun 2000 08:09:03 +0200
Reply-To: Gunnar Hellstrom <gunnar.hellstrom@OMNITOR.SE>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Gunnar Hellstrom <gunnar.hellstrom@OMNITOR.SE>
Subject:      V.18 and H.248 Annex F: Documents for Q9/16 meeting in Edinburgh
X-To:         "Text Telephone Forum (Text Telephone Forum)"
              <textphone@lsv.pi.se>
X-cc:         ITU-T Question 4/16 reflector <tsg16q4@itu.int>,
              Sg16mailbag list <ITU-SG16@mailbag.cps.intel.com>,
              3GPP_TSG_SA_WG1_GLOBALTEXT
              <3GPP_TSG_SA_WG1_GLOBALTEXT@list.etsi.fr>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

For the coming ITU-T Q9/16 meeting in Edinburgh June 28-30, I have uploaded
the Q9 documents to
the ITU Informal ftp site

ties.itu.int/tsg16/sg16/wp1/q9/00-06_Edinburgh

As well as www.omnitor.se/English/standards

The documents are:
------------------
q09160001 Agenda and schedule
q09160002 V.18 Text telephone modem, version 3, white document candidate
q09160003 H.248 Annex F, Facsimile, Text conversation and Call
discrimination packages, white doc candidate.

Regards
------------------------------------------
Gunnar Hellstrom
LM Ericsson

E-mail gunnar.hellstrom@omnitor.se
Tel +46 8 556 002 03
Mob +46 708 204 288
fax +46 8 556 002 06


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 20 02:19:33 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14133
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 20 Jun 2000 02:19:33 -0400 (EDT)
Received: from standards (47.234.32.16:2836) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76BD9@standards.nortelnetworks.com>; Tue, 20 Jun 2000 2:09:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1334 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 20 Jun 2000 02:09:57 -0400
Received: from gw-nl4.philips.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB76BCE@standards.nortelnetworks.com>; Tue, 20 Jun 2000 1:59:57
          -0400
Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by
          gw-nl4.philips.com with ESMTP id IAA04364 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 20 Jun 2000 08:09:00
          +0200 (MEST) (envelope-from "CN=Nermeen
          Ismail/OU=SVL/OU=CE/O=PHILIPS@AMEC"@unregistered.philips.com)
Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com
          via mwrap (4.0a) id xma004362; Tue, 20 Jun 00 08:09:00 +0200
Received: from AMLMS01.DIAMOND.PHILIPS.COM (amlms01sv1.diamond.philips.com
          [161.88.79.213]) by smtprelay-nl1.philips.com
          (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id IAA09962 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 20 Jun 2000 08:08:59
          +0200 (MET DST)
Received: by AMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via
          AMEC id 0056910005617878; Tue, 20 Jun 2000 01:07:36 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; name="MEMO 06/20/00 01:10:49"
Content-Disposition: inline
Message-ID:  <0056910005617878000002L182*@MHS>
Date:         Tue, 20 Jun 2000 01:07:36 -0500
Reply-To: "CN=Nermeen              Ismail/OU=SVL/OU=CE/O=PHILIPS@AMEC"@UNREGISTERED.PHILIPS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "CN=Nermeen              Ismail/OU=SVL/OU=CE/O=PHILIPS@AMEC"@UNREGISTERED.PHILIPS.COM
Subject:      V.18 and H.248 Annex F: Documents for Q9/16 meeting in Edinburgh
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA14133

                   Status Distribution June 20, 2000 01:10:49                        

Sent by AMAUO01

The message regarding "V.18 and H.248 Annex F: Documents for Q9/16 meeting in Edinburgh" sent on June 20, 2000 08:10:49 was sent by

Status Recipient
          Type                To
          Native Name         MEGACO@STANDARDS.NORTELNETWORKS.COM
          Foreign Native Name MEGACO@STANDARDS.NORTELNETWORKS.COM/n/n/nSMTP



Recipients

Status Reporters
          Type                From
          Name Domain         LOTUS
          Native Name         CN=Nermeen Ismail/OU=SVL/OU=CE/O=PHILIPS@AMEC
          Foreign Native Name CN=Nermeen Ismail/OU=SVL/OU=CE/O=PHILIPS/nAMEC/n/n
          Organization        PHILIPS
          Org Unit 1          CE
          Org Unit 2          SVL
          Last Name           Ismail
          First Name          Nermeen



Status          769
Explanation     Invalid recipient

X.400 Status    769
Explanation     User Nermeen Ismail/SVL/CE/PHILIPS@AMEC not listed in public Name & Address Book


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 20 09:41:57 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21805
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 20 Jun 2000 09:41:57 -0400 (EDT)
Received: from standards (47.234.32.16:2816) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76D6F@standards.nortelnetworks.com>; Tue, 20 Jun 2000 9:32:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1843 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 20 Jun 2000 09:32:21 -0400
Received: from mars.hss.co.in (202.54.26.197:33302) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB76D6A@standards.nortelnetworks.com>; Tue, 20 Jun 2000
          9:22:19 -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          mars.hss.co.in (8.10.0/8.10.0) with SMTP id e5KDWwv07780 for
          <megaco@standards.nortelnetworks.com>; Tue, 20 Jun 2000 19:02:59
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256904.00497F27 ; Tue, 20 Jun 2000 18:52:46 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256904.00497E3D.00@sandesh.hss.hns.com>
Date:         Tue, 20 Jun 2000 18:57:17 +0530
Reply-To: rezhirpavai@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: rezhirpavai@HSS.HNS.COM
Subject:      Some discripencies between ASN.1 and ABNF notation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello,
     Some discripencies were found in ASN.1 and ABNF notation.

 TerminationStateDescriptor:

     In ASN.1 notation, this descriptor specifies the property params as
mandatory
but in ABNF, it says that at most one occurance of property param or
eventBufferControl or
serviceState may be present. Thus it is optional in ABNF. Also ABNF does not
impose
any order of occurance of these elements, but ASN.1 imposes an order.

Such discripencies were found in many places, e.g.,
actionRequest, localControlDescriptor, mediaParm etc.

Please indicate whether it is intentional or a genuine error.

                                         Regards,
                                         R. Ezhirpavai


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 20 11:12:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25547
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 20 Jun 2000 11:12:20 -0400 (EDT)
Received: from standards (47.234.32.16:1340) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76E18@standards.nortelnetworks.com>; Tue, 20 Jun 2000 11:02:39 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2064 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 20 Jun 2000 11:02:39 -0400
Received: from qhars002.nortel.com (47.101.112.102:43511) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB76E17@standards.nortelnetworks.com>; Tue, 20 Jun 2000
          11:02:39 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Tue, 20 Jun 2000 16:11:27 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Tue, 20 Jun 2000 11:03:28 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <MPQC8Y6L>; Tue, 20 Jun 2000 11:02:47 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480AE9@zcard00g.ca.nortel.com>
Date:         Tue, 20 Jun 2000 11:02:15 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Last Call: draft-ietf-megaco-merged-01.txt
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

My original message making this announcement on Friday got swallowed by our
list server, making my follow-up note to Mart Nurmet rather cryptic.
Anyway, I see a consensus in favour of putting
draft-ietf-megaco-merged-01.txt to Last Call in order to fulfill our
commitment to SG 16.  Further on that topic, I propose that we follow the
"errata document" system once again to handle any comments received, to
simplify coordination with Study Group 16.

View this as a process of successive approximations, with the hope that
eventually we have a single document describing the protocol with all
necessary corrections.  The result of the present call will be to have an
RFC whose contents match H.248 as approved by the ITU-T.

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 21 04:25:52 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24540
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 21 Jun 2000 04:25:51 -0400 (EDT)
Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77373@standards.nortelnetworks.com>; Wed, 21 Jun 2000 4:15:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3851 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 21 Jun 2000 04:15:42 -0400
Received: from mars.hss.co.in (202.54.26.197:38859) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB77372@standards.nortelnetworks.com>; Wed, 21 Jun 2000
          4:15:40 -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          mars.hss.co.in (8.10.0/8.10.0) with SMTP id e5L8QLv18392 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 21 Jun 2000 13:56:23
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256905.002D6F3A ; Wed, 21 Jun 2000 13:46:15 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256905.002D6E2E.00@sandesh.hss.hns.com>
Date:         Wed, 21 Jun 2000 13:50:19 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Scope for change in Signal Type.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Brian, list

A query regarding the scope for change in signal type.
If the signal type is specified in a SignalsDescriptor, it overrides the default
signal type.
1) Is this change confined for the given termination OR global for all
terminations.
2) Is this change intended only for duration of the call OR for permanent
modification?.
Regards,

-Madhubabu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 21 06:49:44 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25852
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 21 Jun 2000 06:49:44 -0400 (EDT)
Received: from standards (47.234.32.16:3292) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB773A9@standards.nortelnetworks.com>; Wed, 21 Jun 2000 6:39:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3920 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 21 Jun 2000 06:39:59 -0400
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB773A8@standards.nortelnetworks.com>; Wed, 21 Jun 2000
          6:39:59 -0400
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA17145
          for <MEGACO@standards.nortelnetworks.com>; Wed, 21 Jun 2000 06:49:06
          -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          GAA17138 for <MEGACO@standards.nortelnetworks.com>; Wed, 21 Jun 2000
          06:49:06 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA12873; Wed,
          21 Jun 2000 12:49:03 +0200 (MET DST)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          MAA12869; Wed, 21 Jun 2000 12:49:02 +0200 (MET DST)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <65256905.002D6E2E.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39509D49.F244CBEE@lucent.com>
Date:         Wed, 21 Jun 2000 12:47:37 +0200
Reply-To: John Segers <jsegers@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: John Segers <jsegers@LUCENT.COM>
Organization: Lucent Technologies
Subject:      Re: Scope for change in Signal Type.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Madhu,

The intention is that the scope of the override is local, that is it
only overrides the current invocation of the signal.  Even if the signal
is re-applied some time later in the same call without an explicit
signal type, the default type is used.

Cheers,

John

Madhu Babu wrote:
>
> Brian, list
>
> A query regarding the scope for change in signal type.
> If the signal type is specified in a SignalsDescriptor, it overrides the default
> signal type.
> 1) Is this change confined for the given termination OR global for all
> terminations.
> 2) Is this change intended only for duration of the call OR for permanent
> modification?.
> Regards,
>
> -Madhubabu

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 21 08:39:25 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29176
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 21 Jun 2000 08:39:24 -0400 (EDT)
Received: from standards (47.234.32.16:1600) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7745E@standards.nortelnetworks.com>; Wed, 21 Jun 2000 8:29:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4153 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 21 Jun 2000 08:29:45 -0400
Received: from mailcity.com (209.1.236.7:59218) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB7745D@standards.nortelnetworks.com>; Wed, 21 Jun 2000 8:29:44
          -0400
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Wed Jun 21 05:38:26
          2000
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
X-Sender-Ip: 216.6.88.34
Content-Type: multipart/mixed; boundary="=_-=_-JCABDOLPDGBDCAAA"
Content-Transfer-Encoding: 7bit
Message-ID:  <KOBFGOLPDGBDCAAA@mailcity.com>
Date:         Wed, 21 Jun 2000 05:38:26 -0700
Reply-To: hussainmf@mailcity.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hussain F Mohammad <hussainmf@mailcity.com>
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Subject:      Fwd: Tonegen Package
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
You need a MIME compliant mail reader to completely decode it.

--=_-=_-JCABDOLPDGBDCAAA
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Length: 1782
Content-Transfer-Encoding: 7bit

Interesting query! Any responses?
-MFH
--

--------- Forwarded Message ---------

DATE: Sat, 17 Jun 2000 12:12:09
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi

Can soneone help me w/the syntax involving tonegen Package and cg
package?

Say I want to use tonegen/pt with tl (tone id list) of cg/rt and cg/cw
(just as an example)

Signals { tonegen/pt {tl = [cg/rt, cg/cw], ind = 100} }

Does this look right?

Can someone show a real world scenario and syntax on how tonegen package
is used?

In the description of tonegen, "interdigit" time delay was given as the
definition for "ind".
What does "interdigit time delay" really mean here?
Later in Section E.3.3 "ind" is defined as inter signal duration which
seems to make
some sense of how "ind" is supposed to be used.

---
Since Call Progress Tones Generator (cg) Package extends tonegen
package,
it does not really mean that you have to use the following syntax to use
cg:
        Signals {tonegen/pt {tl = cg/dt}}

One can just do        Signals{cg/dt}

----
E.7.3 under "Additional Values"
          "dt (0x0030) is defined as a tone id for playtone"

Does this imply one can do the following?
             Signals {tonegen/pt {tl = dt}}

In E.3.3 "tl" is defined as a list of tone ids.
Is tone id "dt" or "cg/dt"?

Thanks
Chuong


--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------- End Forwarded Message ---------



Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct
--=_-=_-JCABDOLPDGBDCAAA
Content-Type: text/html; charset=us-ascii
Content-Language: en
Content-Length: 1890
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi
<p>Can soneone help me w/the syntax involving tonegen Package and cg package?
<p>Say I&nbsp;want to use tonegen/pt with tl (tone id list) of cg/rt and
cg/cw&nbsp; (just as an example)
<p>Signals { tonegen/pt {tl = [cg/rt, cg/cw], ind = 100} }
<p>Does this look right?
<p>Can someone show a real world scenario and syntax on how tonegen package
is used?
<p>In the description of tonegen, "interdigit" time delay was given as
the definition for "ind".
<br>What does "interdigit time delay" really mean here?
<br>Later in Section E.3.3 "ind" is defined as inter signal duration which
seems to make
<br>some sense of how "ind" is supposed to be used.
<p>---
<br>Since Call Progress Tones Generator (cg) Package extends tonegen package,
<br>it does not really mean that you have to use the following syntax to
use cg:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Signals {tonegen/pt {tl
= cg/dt}}
<p>One can just do&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Signals{cg/dt}
<p>----
<br>E.7.3 under "Additional Values"
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "dt (0x0030)
is defined as a tone id for playtone"
<p>Does this imply one can do the following?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Signals {tonegen/pt {tl = dt}}
<p>In E.3.3 "tl" is defined as a list of tone ids.
<br>Is tone id "dt" or "cg/dt"?
<p>Thanks
<br>Chuong
<br>&nbsp;
<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>
--=_-=_-JCABDOLPDGBDCAAA--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 21 08:48:26 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29679
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 21 Jun 2000 08:48:26 -0400 (EDT)
Received: from standards (47.234.32.16:1600) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7747C@standards.nortelnetworks.com>; Wed, 21 Jun 2000 8:38:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4195 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 21 Jun 2000 08:38:49 -0400
Received: from mars.hss.co.in (202.54.26.197:41358) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7747B@standards.nortelnetworks.com>; Wed, 21 Jun 2000
          8:38:48 -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          mars.hss.co.in (8.10.0/8.10.0) with SMTP id e5LCnTv23303 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 21 Jun 2000 18:19:30
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256905.00458491 ; Wed, 21 Jun 2000 18:09:19 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256905.004583CA.00@sandesh.hss.hns.com>
Date:         Wed, 21 Jun 2000 18:13:53 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Signal Descriptor returned in response.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi all,

When signal Descriptor is specified in Audit descriptor,
what is the response expected from MG?
 The Signal descriptor earlier sent by MGC?  OR
The list of signals that are presently active on the termination?
-Madhu Babu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 22 04:13:35 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23217
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 22 Jun 2000 04:13:25 -0400 (EDT)
Received: from standards (47.234.32.16:2841) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77646@standards.nortelnetworks.com>; Thu, 22 Jun 2000 3:56:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4777 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 22 Jun 2000 03:56:53 -0400
Received: from mars.hss.co.in (202.54.26.197:46990) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB77645@standards.nortelnetworks.com>; Thu, 22 Jun 2000
          3:56:51 -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          mars.hss.co.in (8.10.0/8.10.0) with SMTP id e5M87Vv04253 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 22 Jun 2000 13:37:32
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256906.002BB627 ; Thu, 22 Jun 2000 13:27:26 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256906.002BB501.00@sandesh.hss.hns.com>
Date:         Thu, 22 Jun 2000 13:31:57 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Order of descriptor processing.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

HI all,

"The descriptors SHALL be processed in the order in which they appear".
Is this true for descriptors present as part of Media descriptor?
For example, is the order important for local, remote and Local control
descriptors that appear inside stream descriptor?

-Madhubabu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 22 06:00:40 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24655
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 22 Jun 2000 06:00:30 -0400 (EDT)
Received: from standards (47.234.32.16:4033) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB776D9@standards.nortelnetworks.com>; Thu, 22 Jun 2000 5:46:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4978 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 22 Jun 2000 05:46:44 -0400
Received: from mars.hss.co.in (202.54.26.197:48076) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB776D8@standards.nortelnetworks.com>; Thu, 22 Jun 2000
          5:46:42 -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          mars.hss.co.in (8.10.0/8.10.0) with SMTP id e5M9vOv06363 for
          <megaco@standards.nortelnetworks.com>; Thu, 22 Jun 2000 15:27:26
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256906.0035C681 ; Thu, 22 Jun 2000 15:17:22 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256906.0035C627.00@sandesh.hss.hns.com>
Date:         Thu, 22 Jun 2000 15:21:53 +0530
Reply-To: rezhirpavai@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: rezhirpavai@HSS.HNS.COM
Subject:      Occurance of propertyParm
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Abdallah Rayhan, list

     localControlDescriptor can have more than one occurance of localParm.
It is specified in the ABNF grammer that only one occurance, each of streamMode,
propertyParm, reservedValueMode, reservedGroupMode should occur
for each localControlDescriptor.

     Does propertyParm as a whole have only one occurance or is it that multiple
propertyParm can occur within each localControlDescriptor, and the pkgdName
within the propertyParm should be unique.  If the second option is true then it
should be
specified in the grammer explicitly as specified for sigOther within
sigParameter
in signalDescriptor. If the first option is true then in ASN.1 notation, it is
not right to
quote the propertyParms as "SEQUENCE OF PropertyParm" within
LocalControlDescriptor.

                                              Regards,
                                              R. Ezhirpavai


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 22 09:01:00 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04463
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 22 Jun 2000 09:00:59 -0400 (EDT)
Received: from standards (47.234.32.16:2514) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77806@standards.nortelnetworks.com>; Thu, 22 Jun 2000 8:50:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5380 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 22 Jun 2000 08:50:38 -0400
Received: from qhars002.nortel.com (47.101.112.102:51848) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB77805@standards.nortelnetworks.com>; Thu, 22 Jun 2000
          8:50:38 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Thu, 22 Jun 2000 13:59:42 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Thu, 22 Jun 2000 07:57:20 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <NKANWM1M>; Thu, 22 Jun 2000 07:58:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFDC49.8F5EAF76"
Message-ID:  <28560036253BD41191A10000F8BCBD11480AF3@zcard00g.ca.nortel.com>
Date:         Thu, 22 Jun 2000 07:58:27 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Order of descriptor processing.
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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_01BFDC49.8F5EAF76
Content-Type: text/plain

Yes, order is definitely important for these descriptors.  Setting an active
Mode when the media stream is inadequately defined can lead to an error
condition.  Hence it is probably a good idea to put (and process)
LocalControl last.

> -----Original Message-----
> From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> Sent: Thursday, June 22, 2000 4:02 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Order of descriptor processing.
>
> HI all,
>
> "The descriptors SHALL be processed in the order in which they appear".
> Is this true for descriptors present as part of Media descriptor?
> For example, is the order important for local, remote and Local control
> descriptors that appear inside stream descriptor?
>
> -Madhubabu

------_=_NextPart_001_01BFDC49.8F5EAF76
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.2651.65">
<TITLE>RE: Order of descriptor processing.</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Yes, order is =
definitely important for these descriptors.&nbsp; Setting an active =
Mode when the media stream is inadequately defined can lead to an error =
condition.&nbsp; Hence it is probably a good idea to put (and process) =
LocalControl last. </FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, June 22, 2000 4:02 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Order of descriptor =
processing.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">HI all,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;The descriptors SHALL be =
processed in the order in which they appear&quot;.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Is this true for descriptors present =
as part of Media descriptor?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">For example, is the order important =
for local, remote and Local control</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">descriptors that appear inside stream =
descriptor?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-Madhubabu</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFDC49.8F5EAF76--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 22 09:28:48 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05359
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 22 Jun 2000 09:28:48 -0400 (EDT)
Received: from standards (47.234.32.16:2056) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7785E@standards.nortelnetworks.com>; Thu, 22 Jun 2000 9:18:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5501 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 22 Jun 2000 09:18:57 -0400
Received: from mars.hss.co.in (202.54.26.197:49940) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7785D@standards.nortelnetworks.com>; Thu, 22 Jun 2000
          9:18:55 -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          mars.hss.co.in (8.10.0/8.10.0) with SMTP id e5MDTev09746 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 22 Jun 2000 18:59:41
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256906.0049352A ; Thu, 22 Jun 2000 18:49:37 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=wrKfAorj9GZH2Jb6fEp8LgNAGoq4pPCV5DkBw415xRotI2PqZ0RSSlhT"
Content-Disposition: inline
Message-ID:  <65256906.0049344D.00@sandesh.hss.hns.com>
Date:         Thu, 22 Jun 2000 18:54:07 +0530
Reply-To: rezhirpavai@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: rezhirpavai@HSS.HNS.COM
Subject:      Re: Order of descriptor processing.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=wrKfAorj9GZH2Jb6fEp8LgNAGoq4pPCV5DkBw415xRotI2PqZ0RSSlhT
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



If these descriptors too need to be processed, based on the order as
  relevant in that scenario, then how will this be sent in ASN.1 notation.
  In ASN.1 notation, the order of these descriptors is predefined. Also
 in ASN.1 notation, localControlDescritor occurs the first in the sequence
(implying that it would be processed first)!!!

                                         Regards,
                                         R. Ezhirpavai





Tom-PT Taylor <taylor@NORTELNETWORKS.COM> on 22/06/2000 18:28:27

Please respond to Tom-PT Taylor <taylor@NORTELNETWORKS.COM>

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: R Ezhirpavai/HSS)

Subject:  Re: Order of descriptor processing.




Yes, order is definitely important for these descriptors.  Setting an active
Mode when the media stream is inadequately defined can lead to an error
condition.  Hence it is probably a good idea to put (and process)
LocalControl last.

> -----Original Message-----
> From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> Sent: Thursday, June 22, 2000 4:02 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Order of descriptor processing.
>
> HI all,
>
> "The descriptors SHALL be processed in the order in which they appear".
> Is this true for descriptors present as part of Media descriptor?
> For example, is the order important for local, remote and Local control
> descriptors that appear inside stream descriptor?
>
> -Madhubabu


--0__=wrKfAorj9GZH2Jb6fEp8LgNAGoq4pPCV5DkBw415xRotI2PqZ0RSSlhT
Content-type: text/html;
        name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i
TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTEuNjUiPg0KPFRJVExFPlJFOiBPcmRl
ciBvZiBkZXNjcmlwdG9yIHByb2Nlc3NpbmcuPC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8
UD48Rk9OVCBDT0xPUj0iIzAwMDBGRiIgU0laRT0yIEZBQ0U9IkFyaWFsIj5ZZXMsIG9yZGVyIGlz
IGRlZmluaXRlbHkgaW1wb3J0YW50IGZvciB0aGVzZSBkZXNjcmlwdG9ycy4mbmJzcDsgU2V0dGlu
ZyBhbiBhY3RpdmUgTW9kZSB3aGVuIHRoZSBtZWRpYSBzdHJlYW0gaXMgaW5hZGVxdWF0ZWx5IGRl
ZmluZWQgY2FuIGxlYWQgdG8gYW4gZXJyb3IgY29uZGl0aW9uLiZuYnNwOyBIZW5jZSBpdCBpcyBw
cm9iYWJseSBhIGdvb2QgaWRlYSB0byBwdXQgKGFuZCBwcm9jZXNzKSBMb2NhbENvbnRyb2wgbGFz
dC4gPC9GT05UPjwvUD4NCjxVTD4NCjxQPjxGT05UIFNJWkU9MSBGQUNFPSJBcmlhbCI+LS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+PEI+PEZPTlQgU0laRT0xIEZBQ0U9IkFy
aWFsIj5Gcm9tOiZuYnNwOyZuYnNwOzwvRk9OVD48L0I+IDxGT05UIFNJWkU9MSBGQUNFPSJBcmlh
bCI+TWFkaHUgQmFidSBbU01UUDpibWJhYnVASFNTLkhOUy5DT01dPC9GT05UPg0KPEJSPjxCPjxG
T05UIFNJWkU9MSBGQUNFPSJBcmlhbCI+U2VudDombmJzcDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9O
VCBTSVpFPTEgRkFDRT0iQXJpYWwiPlRodXJzZGF5LCBKdW5lIDIyLCAyMDAwIDQ6MDIgQU08L0ZP
TlQ+DQo8QlI+PEI+PEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFsIj5UbzombmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTEgRkFDRT0iQXJpYWwiPk1FR0FDT0BTVEFO
REFSRFMuTk9SVEVMTkVUV09SS1MuQ09NPC9GT05UPg0KPEJSPjxCPjxGT05UIFNJWkU9MSBGQUNF
PSJBcmlhbCI+U3ViamVjdDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTEgRkFDRT0iQXJpYWwiPk9yZGVyIG9mIGRlc2NyaXB0
b3IgcHJvY2Vzc2luZy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh
bCI+SEkgYWxsLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4m
cXVvdDtUaGUgZGVzY3JpcHRvcnMgU0hBTEwgYmUgcHJvY2Vzc2VkIGluIHRoZSBvcmRlciBpbiB3
aGljaCB0aGV5IGFwcGVhciZxdW90Oy48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj5JcyB0aGlzIHRydWUgZm9yIGRlc2NyaXB0b3JzIHByZXNlbnQgYXMgcGFydCBvZiBNZWRp
YSBkZXNjcmlwdG9yPzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkZvciBl
eGFtcGxlLCBpcyB0aGUgb3JkZXIgaW1wb3J0YW50IGZvciBsb2NhbCwgcmVtb3RlIGFuZCBMb2Nh
bCBjb250cm9sPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ZGVzY3JpcHRv
cnMgdGhhdCBhcHBlYXIgaW5zaWRlIHN0cmVhbSBkZXNjcmlwdG9yPzwvRk9OVD4NCjwvUD4NCg0K
PFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4tTWFkaHViYWJ1PC9GT05UPg0KPC9QPg0KPC9V
TD4NCjwvQk9EWT4NCjwvSFRNTD4NCg==

--0__=wrKfAorj9GZH2Jb6fEp8LgNAGoq4pPCV5DkBw415xRotI2PqZ0RSSlhT--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 22 14:10:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12014
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 22 Jun 2000 14:10:00 -0400 (EDT)
Received: from standards (47.234.32.16:1751) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB779B0@standards.nortelnetworks.com>; Thu, 22 Jun 2000 14:00:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5939 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 22 Jun 2000 14:00:22 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB779AF@standards.nortelnetworks.com>; Thu, 22 Jun 2000 14:00:21
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id OAA27976; Thu, 22 Jun 2000 14:09:26 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id OAA05810; Thu, 22 Jun 2000 14:09:28 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <NL95G6AA>; Thu, 22 Jun 2000 14:09:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CFC99938@whq-msgusr-02.fore.com>
Date:         Thu, 22 Jun 2000 14:09:25 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      First Megaco Interop;
X-cc:         msf-media@msforum.com, isc_devicecontrol@inventures.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I am very pleased to announce the details of the first Megaco/H.248
Interop event.

Dates:
        August 28 - Setup
        August 29-30 testing
        August 31 - teardown (if needed)

Venue: University of New Hampshire, Interoperability Lab, Durham, NH

Co-Sponsors:
        Multiservice Switching Forum
        International Softswitch Consortium
        University of New Hampshire, IOL

Host: Marconi

Open to anyone with an implementation (MG and/or MGC) to test
No observers, please

For further information, please join the megaco-interop list
megaco-interop@eng.fore.com.  To join, send email to
majordomo@eng.fore.com and specify "subscribe megaco-interop"
as the body of your message.

Brian
------------
Brian Rosen, Office of the CTO
Marconi, plc
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:brian.rosen@marconi.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 22 20:40:12 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17947
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 22 Jun 2000 20:40:12 -0400 (EDT)
Received: from standards (47.234.32.16:3363) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77A8E@standards.nortelnetworks.com>; Thu, 22 Jun 2000 20:30:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6230 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 22 Jun 2000 20:30:38 -0400
Received: from turin.trillium.com (38.187.146.197:1616) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB77A8D@standards.nortelnetworks.com>; Thu, 22 Jun 2000
          20:20:38 -0400
Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com
          (Content Technologies SMTPRS 4.1.5) with ESMTP id
          <T26bb92c56b4cf5f1c12e@turin.trillium.com> for
          <MEGACO@standards.nortelnetworks.com>; Thu, 22 Jun 2000 17:42:56 -0700
Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by
          aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id RAA06869 for
          <MEGACO@standards.nortelnetworks.com>; Thu, 22 Jun 2000 17:29:45
          -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <N1RMH2VA>; Thu, 22 Jun 2000 17:27:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5D78C784@aega.trillium.com>
Date:         Thu, 22 Jun 2000 17:27:04 -0700
Reply-To: Vivek Jaiswal <v_jaiswal@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Vivek Jaiswal <v_jaiswal@TRILLIUM.COM>
Subject:      ServiceChangeAddress
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi
I have a few doubts regarding the ServiceChangeAddress parameter.

1) What can be the value of ServiceChangeAddress for IP based networks? The
binary defination of this parameter says that it can be a IP address or a
port number, whereas the ABNF says that it is quotedString.

2) Can MG specify a ServiceChangeAddress different than its own address. In
what probable scenarios this may happen?

Regards
Vivek Jaiswal
Trillium DIgital Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 23 02:58:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04804
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 23 Jun 2000 02:58:37 -0400 (EDT)
Received: from standards (47.234.32.16:3737) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77BD4@standards.nortelnetworks.com>; Fri, 23 Jun 2000 2:49:00 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6643 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 02:49:00 -0400
Received: from ficon-tech.com (12.10.198.190:3518) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB77BCE@standards.nortelnetworks.com>; Fri, 23 Jun 2000
          2:38:54 -0400
Received: from hemantag (vacant4.india.ficon-tech.com [172.25.1.131]) by
          ficon-tech.com (8.9.3/8.9.3) with SMTP id MAA66698; Fri, 23 Jun 2000
          12:16:49 +0530 (IST) (envelope-from hemantag@globespan.net)
References:  <28560036253BD41191A10000F8BCBD11480AF3@zcard00g.ca.nortel.com>
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 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <00ab01bfdcde$e0849920$830119ac@india.ficontech.com>
Date:         Fri, 23 Jun 2000 12:17:04 +0530
Reply-To: Hemant Agrawal <hemantag@GLOBESPAN.NET>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hemant Agrawal <hemantag@GLOBESPAN.NET>
Organization: GlobeSpan.net
Subject:      Re: Order of descriptor processing.
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Tom, list.
         The Local Control has the value for reservedValueMode and
reservedGroupMode, which are required in the processing of local and remote
descriptors.
Hence I believe, LocalControlDesc should be processed first.

Thanks
Hemant Agrawal

----- Original Message -----
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Sent: Thursday, June 22, 2000 6:28 PM
Subject: Re: Order of descriptor processing.


> Yes, order is definitely important for these descriptors.  Setting an
> active Mode when the media stream is inadequately defined can lead to an
> error condition.  Hence it is probably a good idea to put (and process)
> LocalControl last.
>
> -----Original Message-----
> From:   Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> Sent:   Thursday, June 22, 2000 4:02 AM
> To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:        Order of descriptor processing.
>
> HI all,
>
> "The descriptors SHALL be processed in the order in which they
> appear".
> Is this true for descriptors present as part of Media descriptor?
> For example, is the order important for local, remote and Local control
> descriptors that appear inside stream descriptor?
>
> -Madhubabu
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 23 03:47:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05095
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 23 Jun 2000 03:47:01 -0400 (EDT)
Received: from standards (47.234.32.16:2408) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77BF5@standards.nortelnetworks.com>; Fri, 23 Jun 2000 3:37:23 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6694 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 03:37:23 -0400
Received: from mars.hss.co.in (202.54.26.197:55604) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB77BF4@standards.nortelnetworks.com>; Fri, 23 Jun 2000
          3:37:21 -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          mars.hss.co.in (8.10.0/8.10.0) with SMTP id e5N7m7v20650 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 23 Jun 2000 13:18:09
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256907.0029EDF2 ; Fri, 23 Jun 2000 13:07:58 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256907.0029EC46.00@sandesh.hss.hns.com>
Date:         Fri, 23 Jun 2000 13:12:28 +0530
Reply-To: rezhirpavai@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: rezhirpavai@HSS.HNS.COM
Subject:      Termination ID in request
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello,
     AmmRequest, Subtract Request, Notify Request should have one and
only one terminationID (which may be wildcarded) specified. Thus in ASN.1
notation,
these requests should not have TerminationIDList, but TerminationID.

Two Queries:

1. Based on what request would an audit reply be sent with
contextTerminationAudit?

2. In section 7.2.7, (Notify) it is mentioned that "The TerminationID shall be a
fully qualified name."
     Does this mean that TerminationID in NotifyRequest should not be
wildcarded?

                                              Regards,
                                              R. Ezhirpavai


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 23 08:24:35 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08136
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 23 Jun 2000 08:24:34 -0400 (EDT)
Received: from standards (47.234.32.16:3615) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77C74@standards.nortelnetworks.com>; Fri, 23 Jun 2000 8:14:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6837 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 08:14:31 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB77C73@standards.nortelnetworks.com>; Fri, 23 Jun 2000 8:14:31
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id IAA17975; Fri, 23 Jun 2000 08:19:18 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id IAA06836; Fri, 23 Jun 2000 08:19:20 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <N3BABSSQ>; Fri, 23 Jun 2000 08:19:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6784A5@whq-msgusr-02.fore.com>
Date:         Fri, 23 Jun 2000 08:19:18 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: First Megaco Interop;
X-To:         Chuong Nguyen <Chuong.Nguyen@usa.alcatel.com>,
              "rajeev@empowertel.com" <rajeev@empowertel.com>,
              =?iso-8859-1?Q?=27Jos=E9_Dom=EDnguez=27?=
              <jad@network-services.uoregon.edu>,
              "Huang, Alex" <huang@tri.sbc.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Well, I made a mistake.  The subscription instructions for the
megaco-interop list are wrong!

To subscribe, send email to majordomo@fore.com and specify
"subscribe megaco-interop" as the body.

Note that it's "fore.com" not "eng.fore.com".  We have two
majordomo servers, and I sent you to the wrong one.  Sorry.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 23 08:27:44 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08228
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 23 Jun 2000 08:27:43 -0400 (EDT)
Received: from standards (47.234.32.16:3615) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77C95@standards.nortelnetworks.com>; Fri, 23 Jun 2000 8:17:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6880 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 08:17:19 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB77C94@standards.nortelnetworks.com>; Fri, 23 Jun 2000 8:17:19
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id IAA18405; Fri, 23 Jun 2000 08:26:31 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id IAA07871; Fri, 23 Jun 2000 08:26:33 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <N3BABSYG>; Fri, 23 Jun 2000 08:26:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6784A6@whq-msgusr-02.fore.com>
Date:         Fri, 23 Jun 2000 08:26:31 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Termination ID in request
X-To:         "rezhirpavai@HSS.HNS.COM" <rezhirpavai@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> Two Queries:
>
> 1. Based on what request would an audit reply be sent with
> contextTerminationAudit?
contextAudit
For example: Context=1124 {ContextAudit{Topology}}

>
> 2. In section 7.2.7, (Notify) it is mentioned that "The
> TerminationID shall be a
> fully qualified name."
>      Does this mean that TerminationID in NotifyRequest should not be
> wildcarded?
No, you could ask that an event be looked for on a whole bunch
of terminations.  When it occurs on any of them, you get a notify,
for that one termination.  If it occurred on another, you
would get another notify.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 23 08:32:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08404
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 23 Jun 2000 08:32:56 -0400 (EDT)
Received: from standards (47.234.32.16:3615) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77CB0@standards.nortelnetworks.com>; Fri, 23 Jun 2000 8:23:12 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6916 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 08:23:11 -0400
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB77CAF@standards.nortelnetworks.com>; Fri, 23 Jun 2000
          8:23:11 -0400
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA04089
          for <MEGACO@standards.nortelnetworks.com>; Fri, 23 Jun 2000 08:32:25
          -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          IAA04078 for <MEGACO@standards.nortelnetworks.com>; Fri, 23 Jun 2000
          08:32:24 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA14476; Fri,
          23 Jun 2000 14:32:22 +0200 (MET DST)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          OAA14468; Fri, 23 Jun 2000 14:32:22 +0200 (MET DST)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480AF3@zcard00g.ca.nortel.com>
            <00ab01bfdcde$e0849920$830119ac@india.ficontech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39535880.6AAB70CA@lucent.com>
Date:         Fri, 23 Jun 2000 14:30:56 +0200
Reply-To: John Segers <jsegers@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: John Segers <jsegers@LUCENT.COM>
Organization: Lucent Technologies
Subject:      Re: Order of descriptor processing.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hemant,

You have a very valid point.  Taken together with Tom's comment, it
leads me to conclude that the local, remote and localcontrol descriptors
are so closely related that they should be processed together.  That is,
if all three are present, the MG shouldn't set the mode of the stream
before having processed local and remote.  Similarly, if local happens
to occur before localcontrol, the MG should inspect the reserveGroup and
reserveValue fields before reserving resources.

Cheers,

John

Hemant Agrawal wrote:
>
> Hi Tom, list.
>          The Local Control has the value for reservedValueMode and
> reservedGroupMode, which are required in the processing of local and remote
> descriptors.
> Hence I believe, LocalControlDesc should be processed first.
>
> Thanks
> Hemant Agrawal
>
> ----- Original Message -----
> From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
> To: <MEGACO@STANDARDS.NORTELNETWORKS.COM>
> Sent: Thursday, June 22, 2000 6:28 PM
> Subject: Re: Order of descriptor processing.
>
> > Yes, order is definitely important for these descriptors.  Setting an
> > active Mode when the media stream is inadequately defined can lead to an
> > error condition.  Hence it is probably a good idea to put (and process)
> > LocalControl last.
> >
> > -----Original Message-----
> > From:   Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> > Sent:   Thursday, June 22, 2000 4:02 AM
> > To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject:        Order of descriptor processing.
> >
> > HI all,
> >
> > "The descriptors SHALL be processed in the order in which they
> > appear".
> > Is this true for descriptors present as part of Media descriptor?
> > For example, is the order important for local, remote and Local control
> > descriptors that appear inside stream descriptor?
> >
> > -Madhubabu
> >
> >

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 23 08:32:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08407
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 23 Jun 2000 08:32:56 -0400 (EDT)
Received: from standards (47.234.32.16:3615) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77CB9@standards.nortelnetworks.com>; Fri, 23 Jun 2000 8:23:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6927 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 08:23:22 -0400
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB77CB8@standards.nortelnetworks.com>; Fri, 23 Jun 2000
          8:23:22 -0400
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA04224
          for <MEGACO@standards.nortelnetworks.com>; Fri, 23 Jun 2000 08:32:36
          -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          IAA04218 for <MEGACO@standards.nortelnetworks.com>; Fri, 23 Jun 2000
          08:32:35 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA14631; Fri,
          23 Jun 2000 14:32:34 +0200 (MET DST)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          OAA14616; Fri, 23 Jun 2000 14:32:34 +0200 (MET DST)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <65256907.0029EC46.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3953588C.5D38381E@lucent.com>
Date:         Fri, 23 Jun 2000 14:31:08 +0200
Reply-To: John Segers <jsegers@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: John Segers <jsegers@LUCENT.COM>
Organization: Lucent Technologies
Subject:      Re: Termination ID in request
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

R.,

Please see the note preceding the ASN.1 definition.  It reads "The ASN.1
specification below contains a clause defining TerminationIDList as a
sequence of TerminationIDs.  The length of this sequence SHALL be one,
except possibly when used in contextAuditResult."

1. In response to an Audit request with ContextID=* and
TerminationID=ROOT.
2. This sentence puzzles me.  If your interpretation is correct, then it
is not possible to instruct multiple terminations to listen for the same
set of events (ouch!).  Any other comments?

Cheers,

John

rezhirpavai@hss.hns.com wrote:
>
> Hello,
>      AmmRequest, Subtract Request, Notify Request should have one and
> only one terminationID (which may be wildcarded) specified. Thus in ASN.1
> notation,
> these requests should not have TerminationIDList, but TerminationID.
>
> Two Queries:
>
> 1. Based on what request would an audit reply be sent with
> contextTerminationAudit?
>
> 2. In section 7.2.7, (Notify) it is mentioned that "The TerminationID shall be a
> fully qualified name."
>      Does this mean that TerminationID in NotifyRequest should not be
> wildcarded?
>
>                                               Regards,
>                                               R. Ezhirpavai

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 23 10:19:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11333
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 23 Jun 2000 10:19:21 -0400 (EDT)
Received: from standards (47.234.32.16:1473) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77D34@standards.nortelnetworks.com>; Fri, 23 Jun 2000 10:09:34 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7080 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 10:09:33 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB77D2E@standards.nortelnetworks.com>; Fri, 23 Jun 2000 9:59:33
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          JAA17129 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 23 Jun 2000
          09:06:47 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay2-alt.usa.alcatel.com
          [143.209.167.22]) by fw7 via smap (V2.1) id xma017046; Fri, 23 Jun 00
          09:06:26 -0500
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id JAA04186 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 23 Jun 2000 09:10:00
          -0500 (CDT)
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id JAA13969 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 23
          Jun 2000 09:07:52 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA17497
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 23 Jun 2000 09:07:51
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------726044645E9169F98E59BAA7"
Message-ID:  <39536F36.75F92D9B@usa.alcatel.com>
Date:         Fri, 23 Jun 2000 09:07:51 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Signal and event
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------726044645E9169F98E59BAA7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all


I have a TDM and RTP terminations in one context w/the following
transaction:

Transaction = 1 {Context = 100 {
                                 Add = TDM{Signals{al/ri},
                                                        Events = 123
{al/of} },
                                 Add = RTP{Signals{al/ri},
                                                        Events = 123
{al/of} } }}

Looking through the archive, the accepted convention is that any event
detected will STOP
ALL active signals.

Is this true?
If yes, can someone point me to the text in the Standard regarding this?

If not, will the following be a way to turn of ringing signal upon
detection of off-hook event?

Transaction = 1 {Context = 100 {
                                 Add = TDM{Signals{al/ri},
                                                        Events = 123
{al/of {Embed{Signals{} } } },
                                 Add = RTP{Signals{al/ri},
                                                        Events = 123
{al/of} {Embed{Signals{} }  } }}
---


Is the event scoped to termination or context?

In the above example, I want to stop the ringing signal being applied to
the TDM and RTP
terminations upon detection of an off-hook event.

Normally one would think that only the TDM termination would detect the
off-hook event
so does making the RTP termination detect an off-hook event invalid?
In general can RTP termination detect event?

Does anyone have any sugggestion on how I can apply ringing signal to
the TDM and RTP
terminations and stop the signal upon detection of an off-hook event?

Thanks
Chuong


--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------726044645E9169F98E59BAA7
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi all
<br>&nbsp;
<p>I have a TDM and RTP terminations in one context w/the following transaction:
<p>Transaction = 1 {Context = 100 {
<br>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add = TDM{Signals{al/ri},
<br>&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;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Events = 123 {al/of} },
<br>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add = RTP{Signals{al/ri},
<br>&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;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Events = 123 {al/of} } }}
<p>Looking through the archive, the accepted convention is that any event
detected will STOP
<br>ALL active signals.
<p>Is this true?
<br>If yes, can someone point me to the text in the Standard regarding
this?
<br>If not, will the following be a way to turn of ringing signal upon
detection of off-hook event?
<p>Transaction = 1 {Context = 100 {
<br>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add = TDM{Signals{al/ri},
<br>&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;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Events = 123 {al/of {Embed{Signals{} } } },
<br>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add = RTP{Signals{al/ri},
<br>&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;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Events = 123 {al/of} {Embed{Signals{} }&nbsp; } }}
<br>---
<br>&nbsp;
<p>Is the event scoped to termination or context?
<p>In the above example, I&nbsp;want to stop the ringing signal being applied
to the TDM and RTP
<br>terminations upon detection of an off-hook event.
<p>Normally one would think that only the TDM termination would detect
the off-hook event
<br>so does making the RTP termination detect an off-hook event invalid?
<br>In general can RTP termination detect event?
<p>Does anyone have any sugggestion on how I&nbsp;can apply ringing signal
to the TDM and RTP
<br>terminations and stop the signal upon detection of an off-hook event?
<p>Thanks
<br>Chuong
<br>&nbsp;
<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------726044645E9169F98E59BAA7--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 23 10:40:40 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11986
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 23 Jun 2000 10:40:40 -0400 (EDT)
Received: from standards (47.234.32.16:1473) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77D62@standards.nortelnetworks.com>; Fri, 23 Jun 2000 10:30:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7127 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 10:30:53 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB77D53@standards.nortelnetworks.com>; Fri, 23 Jun 2000 10:20:52
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          JAA23241 for <megaco@standards.nortelnetworks.com>; Fri, 23 Jun 2000
          09:28:06 -0500 (CDT)
Received: from <mmonteir@usa.alcatel.com> (relay2-alt.usa.alcatel.com
          [143.209.167.22]) by fw7 via smap (V2.1) id xma023167; Fri, 23 Jun 00
          09:27:23 -0500
Received: from auds906.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id JAA14769; Fri, 23
          Jun 2000 09:30:57 -0500 (CDT)
Received: from usa.alcatel.com (acta5u.dt.usa.alcatel.com [143.209.168.117]) by
          auds906.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id JAA11348;
          Fri, 23 Jun 2000 09:29:50 -0500 (CDT)
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD   (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3953741A.EF454DF4@usa.alcatel.com>
Date:         Fri, 23 Jun 2000 09:28:42 -0500
Reply-To: Mario Monteiro <mmonteir@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Mario Monteiro <mmonteir@USA.ALCATEL.COM>
Organization: Alcatel USA, Inc.
Subject:      Event Detection
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

If there are two termination ids within a context, an SCN and an RTP
termination, will an event which occurs on the SCN termination also be
"seen" at the RTP termination?

The specific case I am refering to is a terminating circuit where an
off-hook (answer) detected on the SCN is also seen at the RTP. The RTP
termination is connected via a IP network path to the originating side.
Would like this event detection to trigger removal of the signal applied
at the RTP (KeepActive off and off-hook event detection at RTP armed)
when the off-hook occurs. Also is my understanding correct that the
StreamMode at the RTP termination does not affect this event detection?

Another question. Can the MediaDescriptor (StreamMode) be set as an
embedded event such that the stream mode gets changed when a specified
event occurs? Only noticed Signal Descriptor and Event Descriptor in the
spec.

An eary response will be much appreciated.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 23 12:55:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15030
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 23 Jun 2000 12:55:17 -0400 (EDT)
Received: from standards (47.234.32.16:1475) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77DCB@standards.nortelnetworks.com>; Fri, 23 Jun 2000 12:45:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7281 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 12:45:25 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB77DCA@standards.nortelnetworks.com>; Fri, 23 Jun 2000 12:45:24
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id MAA11940; Fri, 23 Jun 2000 12:54:32 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id MAA12205; Fri, 23 Jun 2000 12:54:24 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <N3BAB9WM>; Fri, 23 Jun 2000 12:54:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6784B7@whq-msgusr-02.fore.com>
Date:         Fri, 23 Jun 2000 12:54:22 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Signal and event
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The following text occurs in section 7.1.11

Production of a Signal on a Termination is stopped by application of
   a new SignalsDescriptor, or detection of an Event on the Termination
   (see section 7.1.9).

Events are scoped to termination, not context.

Your example is pretty contrived, in that normally, power ring is
sent to the analog line, and ringback is sent to the RTP termination.
Detection of off hook would stop power ring, but not ringback,
because off hook would not be detected on the RTP.  In fact,
it would be most unusual to implement the al package on an RTP
flow.

So, your second example will not work to stop ringback to the RTP,
because al/of will not be detected (actually, detectable) on the RTP.

I don't know of a way to stop the ringback without MGC interaction.
You would need a real script.

Brian

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM]
Sent: Friday, June 23, 2000 10:08 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Signal and event


Hi all

I have a TDM and RTP terminations in one context w/the following
transaction:
Transaction = 1 {Context = 100 {
                                 Add = TDM{Signals{al/ri},
                                                        Events = 123 {al/of}
},
                                 Add = RTP{Signals{al/ri},
                                                        Events = 123 {al/of}
} }}
Looking through the archive, the accepted convention is that any event
detected will STOP
ALL active signals.
Is this true?
If yes, can someone point me to the text in the Standard regarding this?
If not, will the following be a way to turn of ringing signal upon detection
of off-hook event?
Transaction = 1 {Context = 100 {
                                 Add = TDM{Signals{al/ri},
                                                        Events = 123 {al/of
{Embed{Signals{} } } },
                                 Add = RTP{Signals{al/ri},
                                                        Events = 123 {al/of}
{Embed{Signals{} }  } }}
---

Is the event scoped to termination or context?
In the above example, I want to stop the ringing signal being applied to the
TDM and RTP
terminations upon detection of an off-hook event.
Normally one would think that only the TDM termination would detect the
off-hook event
so does making the RTP termination detect an off-hook event invalid?
In general can RTP termination detect event?
Does anyone have any sugggestion on how I can apply ringing signal to the
TDM and RTP
terminations and stop the signal upon detection of an off-hook event?
Thanks
Chuong

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 23 13:22:12 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15750
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 23 Jun 2000 13:22:11 -0400 (EDT)
Received: from standards (47.234.32.16:2883) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77E12@standards.nortelnetworks.com>; Fri, 23 Jun 2000 13:11:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7373 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 13:11:13 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB77E11@standards.nortelnetworks.com>; Fri, 23 Jun 2000 13:11:12
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id NAA13996; Fri, 23 Jun 2000 13:20:24 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id NAA17559; Fri, 23 Jun 2000 13:20:26 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <N3BAB0SJ>; Fri, 23 Jun 2000 13:20:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6784BC@whq-msgusr-02.fore.com>
Date:         Fri, 23 Jun 2000 13:20:22 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Event Detection
X-To:         Mario Monteiro <mmonteir@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hmm, did you just see the message from Chuong Nguyen or
is there a warp in the space/time fabric of the universe?

The reply is the same - events are scoped to a termination,
not a context.  Off hook is not detectable on the RTP.
It occurs to me to wonder if this is the same as MGCP.
We intended it to be.  You can set an event using a
wildcard, as with MGCP, but I think that detection is
on an endpoint, not a connection, and you can't stop
the ringback signal on the RTP with the off hook event
on the analog line.

Stream mode does not affect events.

You can't have a Media Descriptor in an embedded event.

Brian

> -----Original Message-----
> From: Mario Monteiro [mailto:mmonteir@USA.ALCATEL.COM]
> Sent: Friday, June 23, 2000 10:29 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Event Detection
>
>
> If there are two termination ids within a context, an SCN and an RTP
> termination, will an event which occurs on the SCN termination also be
> "seen" at the RTP termination?
>
> The specific case I am refering to is a terminating circuit where an
> off-hook (answer) detected on the SCN is also seen at the RTP. The RTP
> termination is connected via a IP network path to the
> originating side.
> Would like this event detection to trigger removal of the
> signal applied
> at the RTP (KeepActive off and off-hook event detection at RTP armed)
> when the off-hook occurs. Also is my understanding correct that the
> StreamMode at the RTP termination does not affect this event
> detection?
>
> Another question. Can the MediaDescriptor (StreamMode) be set as an
> embedded event such that the stream mode gets changed when a specified
> event occurs? Only noticed Signal Descriptor and Event
> Descriptor in the
> spec.
>
> An eary response will be much appreciated.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 23 14:54:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17387
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 23 Jun 2000 14:54:16 -0400 (EDT)
Received: from standards (47.234.32.16:2883) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77EB6@standards.nortelnetworks.com>; Fri, 23 Jun 2000 14:44:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7579 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 14:44:29 -0400
Received: from turin.trillium.com (38.187.146.197:2294) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB77EB5@standards.nortelnetworks.com>; Fri, 23 Jun 2000
          14:44:29 -0400
Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com
          (Content Technologies SMTPRS 4.1.5) with ESMTP id
          <T26bb92c56b4cf9e46156@turin.trillium.com> for
          <megaco@standards.nortelnetworks.com>; Fri, 23 Jun 2000 12:06:48 -0700
Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by
          aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id LAA19438 for
          <megaco@standards.nortelnetworks.com>; Fri, 23 Jun 2000 11:52:06
          -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <N1RMH207>; Fri, 23 Jun 2000 11:49:21 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5DAFF386@aega.trillium.com>
Date:         Fri, 23 Jun 2000 11:49:20 -0700
Reply-To: Naren Tulpule <naren@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Naren Tulpule <naren@TRILLIUM.COM>
Subject:      One-to-one correspondance between text and binary for remote/loca
              l descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi list,
  I'd like to know if eventually (when ATM SDP is defined etc) there SHALL
be a one-to-one correspondance between (a revised) annex C and SDP. It
largely exists now in Megaco/H.248 for annex A and annex B. (As a sidebar,
as someone from Hughes pointed out; we COULD have had things better - to
enforce the at-most-once restriction in syntax itself. e.g.

Megaco ABNF:
contextAudit = contextAuditToken LBRKT contextAuditProperties *(COMMA
contextAuditProperties) RBRKT
; at-most-once
contextAuditProperties = (TopologyToken / EmergencyToken / PriorityToken)

This could have been, for example:
contextAudit =  contextAuditToken LBRKT [TopologyToken] [EmergencyToken]
[PriorityToken] RBRKT

The "price" we would have paid would be to have a fixed order among the
three choices. )

Still, is the same thing true for annex C properties? I.e. will sub-fields
within attributes which have to be all present (or "-") together in SDP will
be grouped in a sub-sequence in binary encoding? E.g. for ATM traffic
descriptor?



-- Naren.
Narendra C. Tulpule
SMTS, Trillium Digital Systems Inc
12100 Wilshire Bl #1800 LA CA 90025
Ph:  +1-310-442-9222
Fax: +1-310-442-1162


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 23 19:34:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22892
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 23 Jun 2000 19:34:37 -0400 (EDT)
Received: from standards (47.234.32.16:4745) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7803E@standards.nortelnetworks.com>; Fri, 23 Jun 2000 19:25:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8095 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 19:25:02 -0400
Received: from qhars002.nortel.com (47.101.112.102:48121) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7803A@standards.nortelnetworks.com>; Fri, 23 Jun 2000
          19:25:02 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Fri, 23 Jun 2000 20:39:25 +0100
Received: from zrtpd00y.us.nortel.com (actually zrtpd00y) by
          ertpg14e1.nortelnetworks.com; Fri, 23 Jun 2000 14:43:20 -0400
Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <NQCDNQ86>; Fri, 23 Jun 2000 14:42:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFDD42.CF30AA1A"
Message-ID:  <F9CCA681DDB6D1118F480000F8C1BF7804A5FCC3@zrtpd006.us.nortel.com>
Date:         Fri, 23 Jun 2000 14:42:38 -0400
Reply-To: Christopher Rigano <crigano@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christopher Rigano <crigano@NORTELNETWORKS.COM>
Subject:      XDSL, ADSL, DSL
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Hello everyone,

Have there been Megaco packages developed to support DXL ADSL XDSL?

Best regards,

Chris

------_=_NextPart_001_01BFDD42.CF30AA1A
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.65">
<TITLE>XDSL, ADSL, DSL</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">Hello everyone,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Have there been Megaco packages developed to support DXL ADSL XDSL?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Best regards,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Chris</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFDD42.CF30AA1A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Jun 24 02:40:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10293
	for <megaco-archive@LISTS.IETF.ORG>; Sat, 24 Jun 2000 02:40:20 -0400 (EDT)
Received: from standards (47.234.32.16:3996) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78177@standards.nortelnetworks.com>; Sat, 24 Jun 2000 2:30:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8510 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 24 Jun 2000 02:30:38 -0400
Received: from mail.huawei.com.cn (202.96.135.132:45941) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB78176@standards.nortelnetworks.com>; Sat, 24 Jun 2000
          2:30:37 -0400
Received: from huawei.com.cn ([10.105.29.194]) by mail.huawei.com.cn (Netscape
          Mail Server v2.02) with ESMTP id AAA12176 for
          <megaco@standards.nortelnetworks.com>; Sat, 24 Jun 2000 14:40:50 +0800
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3954578F.60677623@huawei.com.cn>
Date:         Sat, 24 Jun 2000 14:39:11 +0800
Reply-To: "Xiaotian Bian(Bill)" <bianxiaotian@HUAWEI.COM.CN>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Xiaotian Bian(Bill)" <bianxiaotian@HUAWEI.COM.CN>
Subject:      RG ATM example
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,
    Can someone give me an example scenario to illustrate the use of the
MeGaCo/H.248 protocol to setup a RG to RG call over an ATM network,as
Appendix A does,yet in IP network?
    Thanks!


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jun 25 09:26:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07962
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 25 Jun 2000 09:26:17 -0400 (EDT)
Received: from standards (47.234.32.16:3049) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7851C@standards.nortelnetworks.com>; 25 Jun 2000 9:16:19 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9790 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 25 Jun 2000 09:16:19 -0400
Received: from pwr.pwradio.pl by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB7851B@standards.nortelnetworks.com>; 25 Jun 2000 9:06:16 -0400
Received: from host (cranston-ip-1-2.dynamic.ziplink.net [209.206.4.2]) by
          pwr.pwradio.pl (8.9.1/8.9.0) with ESMTP id OAA22157; Sun, 25 Jun 2000
          14:31:24 +0200
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <200006251231.OAA22157@pwr.pwradio.pl>
Date:         Sun, 25 Jun 2000 07:24:58 -0500
Reply-To: Jack Sonnay <brnt25@MAIL.KMSP.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Jack Sonnay <brnt25@MAIL.KMSP.COM>
Subject:      Your Web Site  # 3F5
X-To:         open29d@pwr.pwradio.pl
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA07962

WE MAKE IT EASY & AFFORDABLE TO ACCEPT CREDIT CARDS FOR YOUR BUSINESS
!

INTERNET (Auction Vendors & Online Mall Stores Too!)
STOREFRONT OR MAIL ORDER MERCHANTS

WE SPECIALIZE IN APPROVING YOU!


APPLY TODAY AND START FOR JUST $9.95!

FREE APPLICATION!!
FREE PROGRAMMING!!

DON'T LOSE ANOTHER SALE!

APPLY TO ACCEPT CREDIT CARDS
AND CALL (888) 264-9272


DON'T FORGET TO ASK ABOUT OUR WEB DESIGN AND HOSTING PACKAGE !!!



************************************************************
If you receive this message and have never joined one of our
email lists you can be removed  by replying to:
mailto:brnt25r@netscape.net?subject=remove
************************************************************


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 26 00:08:25 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14383
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 26 Jun 2000 00:08:25 -0400 (EDT)
Received: from standards (47.234.32.16:4921) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7865C@standards.nortelnetworks.com>; 25 Jun 2000 23:58:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10227 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 25 Jun 2000 23:58:28 -0400
Received: from mars.hss.co.in (202.54.26.197:65467) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7865B@standards.nortelnetworks.com>; 25 Jun 2000 23:58:18
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          mars.hss.co.in (8.10.0/8.10.0) with SMTP id e5Q46Rv09822; Mon, 26 Jun
          2000 09:36:29 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525690A.0015A2F5 ; Mon, 26 Jun 2000 09:26:19 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525690A.0015A118.00@sandesh.hss.hns.com>
Date:         Mon, 26 Jun 2000 09:30:49 +0530
Reply-To: rezhirpavai@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: rezhirpavai@HSS.HNS.COM
Subject:      Re: Termination ID in request
X-To:         John Segers <jsegers@LUCENT.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello John,
     After reading the NOTE, the usage of TerminationIDList is clear.

     As regards the second query, it could be possible that MGC instructs MG to
detect for 'OFF HOOK" for a group of terminations (through wildcarding). MG on
detection of
"OFF HOOK" for a set of terminations (almost at the same time), can club these
Notifications and
send back Notify wildcarded!!

                                                   Regards,
                                                   R. Ezhirpavai





John Segers <jsegers@LUCENT.COM> on 23/06/2000 18:01:08

Please respond to John Segers <jsegers@LUCENT.COM>

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: R Ezhirpavai/HSS)

Subject:  Re: Termination ID in request




R.,

Please see the note preceding the ASN.1 definition.  It reads "The ASN.1
specification below contains a clause defining TerminationIDList as a
sequence of TerminationIDs.  The length of this sequence SHALL be one,
except possibly when used in contextAuditResult."

1. In response to an Audit request with ContextID=* and
TerminationID=ROOT.
2. This sentence puzzles me.  If your interpretation is correct, then it
is not possible to instruct multiple terminations to listen for the same
set of events (ouch!).  Any other comments?

Cheers,

John

rezhirpavai@hss.hns.com wrote:
>
> Hello,
>      AmmRequest, Subtract Request, Notify Request should have one and
> only one terminationID (which may be wildcarded) specified. Thus in ASN.1
> notation,
> these requests should not have TerminationIDList, but TerminationID.
>
> Two Queries:
>
> 1. Based on what request would an audit reply be sent with
> contextTerminationAudit?
>
> 2. In section 7.2.7, (Notify) it is mentioned that "The TerminationID shall be
a
> fully qualified name."
>      Does this mean that TerminationID in NotifyRequest should not be
> wildcarded?
>
>                                               Regards,
>                                               R. Ezhirpavai

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 26 07:40:18 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01023
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 26 Jun 2000 07:40:18 -0400 (EDT)
Received: from standards (47.234.32.16:4723) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7875A@standards.nortelnetworks.com>; Mon, 26 Jun 2000 7:30:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10565 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 26 Jun 2000 07:30:20 -0400
Received: from qhars002.nortel.com (47.101.112.102:57065) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB78759@standards.nortelnetworks.com>; Mon, 26 Jun 2000
          7:30:20 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Mon, 26 Jun 2000 12:39:19 +0100
Received: from zcard015.ca.nortel.com (actually zcard015) by
          ertpg14e1.nortelnetworks.com; Mon, 26 Jun 2000 07:38:25 -0400
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id NQD28X3C; Mon, 26 Jun 2000 07:38:25
          -0400
Received: from americasm10.nt.com (pnc1d070.us.nortel.com [47.142.209.170]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id M38DWWFJ; Mon, 26 Jun 2000 07:38:25
          -0400
X-Sybari-Space: 00000000 00000000 00000000
X-Sender: "Sophia Scoggins" <scoggins@zrtpd00z>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <F9CCA681DDB6D1118F480000F8C1BF7804A5FCC3@zrtpd006.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <395740B6.92642EE8@americasm10.nt.com>
Date:         Mon, 26 Jun 2000 07:38:30 -0400
Reply-To: Sophia Scoggins <scoggins@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sophia Scoggins <scoggins@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: XDSL, ADSL, DSL
X-To:         Christopher Rigano <crigano@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Chris,


I discussed this issue with a few people here worked on XDSL before. Our
view is that no additional packages is required for XDSL. The XDSL is
mainly a physical layer implementation (using a spliter). After the
spliter splits data from voice, the voice is treated the same as the
POTS voice, and the data is treated the same as any packets (most of the
time, ATM packets).


Regards, Sophia

"Rigano, Christopher" wrote:
>
> Hello everyone,
>
> Have there been Megaco packages developed to support DXL ADSL XDSL?
>
> Best regards,
>
> Chris


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 26 13:57:54 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12203
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 26 Jun 2000 13:57:53 -0400 (EDT)
Received: from standards (47.234.32.16:2573) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7891A@standards.nortelnetworks.com>; Mon, 26 Jun 2000 13:47:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0427 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 26 Jun 2000 13:47:41 -0400
Received: from turin.trillium.com (38.187.146.197:1773) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB78919@standards.nortelnetworks.com>; Mon, 26 Jun 2000
          13:47:41 -0400
Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com
          (Content Technologies SMTPRS 4.1.5) with ESMTP id
          <T26bb92c59b4d0923dc5a@turin.trillium.com> for
          <MEGACO@standards.nortelnetworks.com>; Mon, 26 Jun 2000 11:10:26 -0700
Received: from gaea.trillium.com (gaea.trillium.com [192.168.1.11]) by
          aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id KAA29014 for
          <MEGACO@standards.nortelnetworks.com>; Mon, 26 Jun 2000 10:57:03
          -0700 (PDT)
Received: by gaea.trillium.com with Internet Mail Service (5.5.2650.21) id
          <N1RS57FK>; Mon, 26 Jun 2000 10:55:13 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <0E7AA454E229D411A1CB0090274661FF19F6F2@gaea.trillium.com>
Date:         Mon, 26 Jun 2000 10:55:12 -0700
Reply-To: Mukesh Goel <mukesh@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Mukesh Goel <mukesh@TRILLIUM.COM>
Subject:      MG Service Change w.r.t. TCP as transport
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,

Q1: Is MG allowed to include ServiceChangeAddress parameter in case of TCP
as a transport?
Q2: If answer to Q1 is yes, then is MGC supposed to establish connection
back to MG on
      the changed address?

If Q1 and Q2 hold, then MG needs to has to implement a TCP Server.  I
remember the discussion
along the line of MG implementing Server and MGC initiating connection did
not reach any
conclusion.

Any explanation on this issue would be hightly appreciated.

Regards,
Mukesh Goel
Trillium Digital Systems.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 26 13:57:54 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12205
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 26 Jun 2000 13:57:54 -0400 (EDT)
Received: from standards (47.234.32.16:2573) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78923@standards.nortelnetworks.com>; Mon, 26 Jun 2000 13:48:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0438 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 26 Jun 2000 13:48:22 -0400
Received: from turin.trillium.com (38.187.146.197:1781) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB78922@standards.nortelnetworks.com>; Mon, 26 Jun 2000
          13:48:21 -0400
Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com
          (Content Technologies SMTPRS 4.1.5) with ESMTP id
          <T26bb92c59b4d09243864@turin.trillium.com> for
          <MEGACO@standards.nortelnetworks.com>; Mon, 26 Jun 2000 11:10:50 -0700
Received: from gaea.trillium.com (gaea.trillium.com [192.168.1.11]) by
          aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id KAA29033 for
          <MEGACO@standards.nortelnetworks.com>; Mon, 26 Jun 2000 10:57:27
          -0700 (PDT)
Received: by gaea.trillium.com with Internet Mail Service (5.5.2650.21) id
          <N1RS57FP>; Mon, 26 Jun 2000 10:55:37 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <0E7AA454E229D411A1CB0090274661FF19F6F3@gaea.trillium.com>
Date:         Mon, 26 Jun 2000 10:55:36 -0700
Reply-To: Mukesh Goel <mukesh@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Mukesh Goel <mukesh@TRILLIUM.COM>
Subject:      ServiceChangeAddress ASN.1 vs ABNF
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,

Please see the descripency in definition of ServiceChangeAddress in
ASN.1 and ABNF.

Please see the excerpt from the document.

A.2 ASN.1 Syntax Specification
------------------------------
ServiceChangeAddress ::= CHOICE
{
portNumber INTEGER(0..65535), -- TCP/UDP port number
ip4Address IP4Address,
ip6Address IP6Address,
domainName DomainName,
deviceName PathName,
mtpAddress OCTET STRING(SIZE(2)),
...
}

B.2 ABNF Specification
----------------------
serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE
VALUE = quotedString / 1*(SafeChar)



Proposed ABNF Syntax
--------------------
serviceChangeAddress = portNumber /
                       (( domainAddress / domainName )[":" portNumber]) /
                       mtpAddress / deviceName


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 26 20:46:25 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17631
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 26 Jun 2000 20:46:25 -0400 (EDT)
Received: from standards (47.234.32.16:2323) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78A55@standards.nortelnetworks.com>; Mon, 26 Jun 2000 20:36:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0832 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 26 Jun 2000 20:36:32 -0400
Received: from qhars002.nortel.com (47.101.112.102:45078) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB78A54@standards.nortelnetworks.com>; Mon, 26 Jun 2000
          20:36:31 -0400
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          qhars002.nortel.com; Tue, 27 Jun 2000 01:45:47 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Mon, 26 Jun 2000 20:44:50 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <NQCAS6NH>; Mon, 26 Jun 2000 20:44:50 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480B0B@zcard00g.ca.nortel.com>
Date:         Mon, 26 Jun 2000 20:44:48 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Tonegen Package
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Sorry to take so long to answer this.  If you check out the ABNF, you see
that signal parameter syntax reduces to

NAME parmValue

As a result, the toneIDs themselves are NOT prefixed by package name.  The
square bracket syntax denotes a sublist (from the alternativeValue
production).  I think that's wrong: the package defines the parameter as a
list, not a sub-list.  Thus curly brackets should be used, and the
interpretation is "list of values" rather than "list of alternatives"
because the package definition says so.

The fact that toneIDs are not prefixed by package name leads to potential
ambiguity.  Either toneIDs have to be unique, which may implying an IANA
registration process, or else we indicate which package the toneIDs come
from by using the package name for the toneIDs instead of tonegen to prefix
the pt signal.  The latter mechanism would restrict the playing of tones in
one signal to a single package, so I think we have to go with unique
toneIDs.  Therefore the correct syntax for your example is

Signals { tonegen/pt {tl = {rt, cw}, ind = 100} }

The example is really not very appealing -- one would have to assume that
the durations of rt and cw are provisioned.  (Note that tonegen is
characterized as BR by default.)

The fact that we define toneIDs in packages implies that they come in
closely related sets, which must be supported on an all-or-nothing basis.

Further comments below.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Saturday, June 17, 2000 1:12 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Tonegen Package
>
> Hi
>
> Can soneone help me w/the syntax involving tonegen Package and cg package?
>
>
> Say I want to use tonegen/pt with tl (tone id list) of cg/rt and cg/cw
> (just as an example)
>
> Signals { tonegen/pt {tl = [cg/rt, cg/cw], ind = 100} }
>
> Does this look right?
>
> Can someone show a real world scenario and syntax on how tonegen package
> is used?
        [PTT]
        Two cases:

        Case 1: DTMF outpulsing of the digits "5551212" (e.g. on a PBX
trunk), with 10 ms gaps between the individual tones.

           Signals { tonegen/pt {tl = {d5, d5, d5, d1, d2, d1, d2}, ind=10}
}

        Case 2: Play ringing tone for a maximum of 3 minutes.  Notify the
MGC if the tone terminates abnormally or by timeout.  (No notification is
needed if the tone is interrupted by an event or replacement.)  If any
signals remain active when the signal completion event is recognized, allow
them to continue.

           Signals { tonegen/pt {tl = {rg}, ind=0, sy=to, nc= {to, or} },
           Events = 666 { g/sc{ka} }

> In the description of tonegen, "interdigit" time delay was given as the
> definition for "ind".
> What does "interdigit time delay" really mean here?
> Later in Section E.3.3 "ind" is defined as inter signal duration which
> seems to make
> some sense of how "ind" is supposed to be used.
        [PTT]
        The "interdigit" is in quotes in the description because the tones
aren't necessarily digits.  However, as you can see, the most natural use of
the "list of tones" feature is for digit outpulsing.

> ---
> Since Call Progress Tones Generator (cg) Package extends tonegen package,
> it does not really mean that you have to use the following syntax to use
> cg:
>         Signals {tonegen/pt {tl = cg/dt}}
>
> One can just do        Signals{cg/dt}
        [PTT]
        Sorry, no.  "dt" is not a signal, merely a possible value of a
signal  parameter.

> ----
> E.7.3 under "Additional Values"
>           "dt (0x0030) is defined as a tone id for playtone"
>
> Does this imply one can do the following?
>              Signals {tonegen/pt {tl = dt}}
>
> In E.3.3 "tl" is defined as a list of tone ids.
> Is tone id "dt" or "cg/dt"?
        [PTT]
        Answered above.  The ABNF for signal parameter value forces us to
use "dt".

> Thanks
> Chuong
>
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 26 20:57:24 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17684
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 26 Jun 2000 20:57:24 -0400 (EDT)
Received: from standards (47.234.32.16:2323) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78A72@standards.nortelnetworks.com>; Mon, 26 Jun 2000 20:47:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0871 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 26 Jun 2000 20:47:37 -0400
Received: from qhars002.nortel.com (47.101.112.102:45222) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB78A71@standards.nortelnetworks.com>; Mon, 26 Jun 2000
          20:47:33 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Tue, 27 Jun 2000 01:56:22 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Mon, 26 Jun 2000 20:55:51 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <NQCAS6PQ>; Mon, 26 Jun 2000 20:55:52 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480B0E@zcard00g.ca.nortel.com>
Date:         Mon, 26 Jun 2000 20:55:25 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      FW: Tonegen Package
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In my case 2 example below, I forgot to set the timeout interval.  The
correct Signals descriptor is:
 Signals { tonegen/pt {tl = {rg}, ind=0, sy=to, dr=1800, nc= {to, or} }

> -----Original Message-----
> From: Taylor, Tom-PT [NORSE:B901:EXCH]
> Sent: Monday, June 26, 2000 8:45 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Tonegen Package
>
> Sorry to take so long to answer this.  If you check out the ABNF, you see
> that signal parameter syntax reduces to
>
> NAME parmValue
>
> As a result, the toneIDs themselves are NOT prefixed by package name.  The
> square bracket syntax denotes a sublist (from the alternativeValue
> production).  I think that's wrong: the package defines the parameter as a
> list, not a sub-list.  Thus curly brackets should be used, and the
> interpretation is "list of values" rather than "list of alternatives"
> because the package definition says so.
>
> The fact that toneIDs are not prefixed by package name leads to potential
> ambiguity.  Either toneIDs have to be unique, which may implying an IANA
> registration process, or else we indicate which package the toneIDs come
> from by using the package name for the toneIDs instead of tonegen to
> prefix
> the pt signal.  The latter mechanism would restrict the playing of tones
> in
> one signal to a single package, so I think we have to go with unique
> toneIDs.  Therefore the correct syntax for your example is
>
> Signals { tonegen/pt {tl = {rt, cw}, ind = 100} }
>
> The example is really not very appealing -- one would have to assume that
> the durations of rt and cw are provisioned.  (Note that tonegen is
> characterized as BR by default.)
>
> The fact that we define toneIDs in packages implies that they come in
> closely related sets, which must be supported on an all-or-nothing basis.
>
> Further comments below.
>
> > -----Original Message-----
> > From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> > Sent: Saturday, June 17, 2000 1:12 PM
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Tonegen Package
> >
> > Hi
> >
> > Can soneone help me w/the syntax involving tonegen Package and cg
> package?
> >
> >
> > Say I want to use tonegen/pt with tl (tone id list) of cg/rt and cg/cw
> > (just as an example)
> >
> > Signals { tonegen/pt {tl = [cg/rt, cg/cw], ind = 100} }
> >
> > Does this look right?
> >
> > Can someone show a real world scenario and syntax on how tonegen package
> > is used?
>         [PTT]
>         Two cases:
>
>         Case 1: DTMF outpulsing of the digits "5551212" (e.g. on a PBX
> trunk), with 10 ms gaps between the individual tones.
>
>            Signals { tonegen/pt {tl = {d5, d5, d5, d1, d2, d1, d2},
> ind=10}
> }
>
>         Case 2: Play ringing tone for a maximum of 3 minutes.  Notify the
> MGC if the tone terminates abnormally or by timeout.  (No notification is
> needed if the tone is interrupted by an event or replacement.)  If any
> signals remain active when the signal completion event is recognized,
> allow
> them to continue.
>
>            Signals { tonegen/pt {tl = {rg}, ind=0, sy=to, nc= {to, or} },
>            Events = 666 { g/sc{ka} }
>
> > In the description of tonegen, "interdigit" time delay was given as the
> > definition for "ind".
> > What does "interdigit time delay" really mean here?
> > Later in Section E.3.3 "ind" is defined as inter signal duration which
> > seems to make
> > some sense of how "ind" is supposed to be used.
>         [PTT]
>         The "interdigit" is in quotes in the description because the tones
> aren't necessarily digits.  However, as you can see, the most natural use
> of
> the "list of tones" feature is for digit outpulsing.
>
> > ---
> > Since Call Progress Tones Generator (cg) Package extends tonegen
> package,
> > it does not really mean that you have to use the following syntax to use
> > cg:
> >         Signals {tonegen/pt {tl = cg/dt}}
> >
> > One can just do        Signals{cg/dt}
>         [PTT]
>         Sorry, no.  "dt" is not a signal, merely a possible value of a
> signal  parameter.
>
> > ----
> > E.7.3 under "Additional Values"
> >           "dt (0x0030) is defined as a tone id for playtone"
> >
> > Does this imply one can do the following?
> >              Signals {tonegen/pt {tl = dt}}
> >
> > In E.3.3 "tl" is defined as a list of tone ids.
> > Is tone id "dt" or "cg/dt"?
>         [PTT]
>         Answered above.  The ABNF for signal parameter value forces us to
> use "dt".
>
> > Thanks
> > Chuong
> >
> > --
> >   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
> >   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jun 26 21:32:11 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18062
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 26 Jun 2000 21:32:10 -0400 (EDT)
Received: from standards (47.234.32.16:1146) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78A9F@standards.nortelnetworks.com>; Mon, 26 Jun 2000 21:22:18 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0923 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 26 Jun 2000 21:22:18 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB78A98@standards.nortelnetworks.com>; Mon, 26 Jun 2000 21:12:18
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          UAA16547 for <megaco@standards.nortelnetworks.com>; Mon, 26 Jun 2000
          20:19:33 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay2-alt.usa.alcatel.com
          [143.209.167.22]) by fw7 via smap (V2.1) id xma016332; Mon, 26 Jun 00
          20:18:34 -0500
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id UAA01484 for
          <megaco@standards.nortelnetworks.com>; Mon, 26 Jun 2000 20:22:11
          -0500 (CDT)
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id UAA10908 for <megaco@standards.nortelnetworks.com>; Mon, 26
          Jun 2000 20:19:46 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id UAA01229
          for <megaco@standards.nortelnetworks.com>; Mon, 26 Jun 2000 20:19:45
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480B0B@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------01525E2387302F76A2DA8B3C"
Message-ID:  <39580131.CDBF02F3@usa.alcatel.com>
Date:         Mon, 26 Jun 2000 20:19:45 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: Tonegen Package
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------01525E2387302F76A2DA8B3C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for the reply.

See comments below

Tom-PT Taylor wrote:

>
>
> Sorry to take so long to answer this.  If you check out the ABNF, you
> see that signal parameter syntax reduces to
>
> NAME parmValue
>
> As a result, the toneIDs themselves are NOT prefixed by package name.
> The square bracket syntax denotes a sublist (from the alternativeValue
> production).  I think that's wrong: the package defines the parameter
> as a list, not a sub-list.  Thus curly brackets should be used, and
> the interpretation is "list of values" rather than "list of
> alternatives" because the package definition says so.

<cnn> I agreed w/you about the curly bracket.  But I think you meant the
square bracket syntax denotes
an alternatives list.
So are you also saying that the ABNF needs to be clarified that sublist
is the same thing as
"list of values"?


>
>
> The fact that toneIDs are not prefixed by package name leads to
> potential ambiguity.  Either toneIDs have to be unique, which may
> implying an IANA registration process, or else we indicate which
> package the toneIDs come from by using the package name for the
> toneIDs instead of tonegen to prefix the pt signal.  The latter
> mechanism would restrict the playing of tones in one signal to a
> single package, so I think we have to go with unique toneIDs.
> Therefore the correct syntax for your example is
>

VALUE = quotedString / 1*(SafeChar)
So why can't VALUE = "cg/rt" instead of just "rt"?  But of course all
these could get pretty hairy
if we have several levels of extension.
Does VALUE has a limit on # of characters?

I guess this also depends on how the ASN deals with this.


>
> Signals { tonegen/pt {tl = {rt, cw}, ind = 100} }
>
> The example is really not very appealing -- one would have to assume
> that the durations of rt and cw are provisioned.  (Note that tonegen
> is characterized as BR by default.)
>
> The fact that we define toneIDs in packages implies that they come in
> closely related sets, which must be supported on an all-or-nothing
> basis.
>
>
>
>      ---
>      Since Call Progress Tones Generator (cg) Package extends tonegen
>      package,
>      it does not really mean that you have to use the following syntax
>      to use cg:
>              Signals {tonegen/pt {tl = cg/dt}}
>
>      One can just do        Signals{cg/dt}
>      [PTT]
>      Sorry, no.  "dt" is not a signal, merely a possible value of a
>      signal  parameter.
>
>
<cnn>  I don't know about this because the cg package defines dt as
either a signal id/tone id.
In Appendix A, example cg/dt is used as
            Signals {cg/dt}                Step 8, page 158

>
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------01525E2387302F76A2DA8B3C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Thanks for the reply.
<p>See comments below
<p>Tom-PT Taylor wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>Sorry to take
so long to answer this.&nbsp; If you check out the ABNF, you see that signal
parameter syntax reduces to</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>NAME parmValue</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>As a result,
the toneIDs themselves are NOT prefixed by package name.&nbsp; The square
bracket syntax denotes a sublist (from the alternativeValue production).&nbsp;
I think that's wrong: the package defines the parameter as a list, not
a sub-list.&nbsp; Thus curly brackets should be used, and the interpretation
is "list of values" rather than "list of alternatives" because the package
definition says so.</font></font></font></blockquote>

<p><br>&lt;cnn> I agreed w/you about the curly bracket.&nbsp; But I think
you meant the square bracket syntax denotes
<br>an alternatives list.
<br>So are you also saying that the ABNF needs to be clarified that sublist
is the same thing as
<br>"list of values"?
<br>&nbsp;
<blockquote TYPE=CITE><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>The fact that
toneIDs are not prefixed by package name leads to potential ambiguity.&nbsp;
Either toneIDs have to be unique, which may implying an IANA registration
process, or else we indicate which package the toneIDs come from by using
the package name for the toneIDs instead of tonegen to prefix the pt signal.&nbsp;
The latter mechanism would restrict the playing of tones in one signal
to a single package, so I think we have to go with unique toneIDs.&nbsp;
Therefore the correct syntax for your example is</font></font></font>
<br>&nbsp;</blockquote>
VALUE = quotedString / 1*(SafeChar)
<br>So why can't VALUE = "cg/rt" instead of just "rt"?&nbsp; But of course
all these could get pretty hairy
<br>if we have several levels of extension.
<br>Does VALUE&nbsp;has a limit on # of characters?
<p>I&nbsp;guess this also depends on how the ASN deals with this.
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<br><font face="Arial"><font size=-1>Signals { tonegen/pt {tl = {rt, cw},
ind = 100} }</font></font>
<p><font face="Arial"><font size=-1>The example is really not very appealing
-- one would have to assume that the durations of rt and cw are provisioned.&nbsp;
(Note that tonegen is characterized as BR by default.)</font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>The fact that
we define toneIDs in packages implies that they come in closely related
sets, which must be supported on an all-or-nothing basis.</font></font></font>
<br>&nbsp;
<ul>&nbsp;
<br><font face="Arial"><font size=-1>---</font></font>
<br><font face="Arial"><font size=-1>Since Call Progress Tones Generator
(cg) Package extends tonegen package,</font></font>
<br><font face="Arial"><font size=-1>it does not really mean that you have
to use the following syntax to use cg:</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Signals {tonegen/pt {tl = cg/dt}}</font></font>
<p><font face="Arial"><font size=-1>One can just do&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Signals{cg/dt}</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[PTT]</font></font></font></i></b>
<br><font face="Arial"><font color="#0000FF"><font size=-1>Sorry, no.&nbsp;
"dt" is not a signal, merely a possible value of a signal&nbsp; parameter.</font></font></font>
<br>&nbsp;</ul>
</blockquote>
&lt;cnn>&nbsp; I&nbsp;don't know about this because the cg package defines
dt as either a signal id/tone id.
<br>In Appendix A, example cg/dt is used as
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Signals {cg/dt}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Step 8, page 158
<blockquote TYPE=CITE>
<ul>&nbsp;</ul>
</blockquote>

<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------01525E2387302F76A2DA8B3C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 08:55:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10514
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 08:55:10 -0400 (EDT)
Received: from standards (47.234.32.16:2328) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78BC6@standards.nortelnetworks.com>; Tue, 27 Jun 2000 8:45:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1319 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 08:45:11 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB78BC5@standards.nortelnetworks.com>; Tue, 27 Jun 2000 8:45:11
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id IAA26541; Tue, 27 Jun 2000 08:54:36 -0400 (EDT)
Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com
          [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id IAA00594; Tue, 27 Jun 2000 08:54:36 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <NJWYSWF7>; Tue, 27 Jun 2000 08:54:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6784CE@whq-msgusr-02.fore.com>
Date:         Tue, 27 Jun 2000 08:54:26 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: MG Service Change w.r.t. TCP as transport
X-To:         Mukesh Goel <mukesh@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> Q1: Is MG allowed to include ServiceChangeAddress parameter
> in case of TCP
> as a transport?
Yes, but it would be pretty unusual.

> Q2: If answer to Q1 is yes, then is MGC supposed to establish
> connection
> back to MG on
>       the changed address?
No, I think the MG would have to do that.

>
> If Q1 and Q2 hold, then MG needs to has to implement a TCP Server.  I
> remember the discussion
> along the line of MG implementing Server and MGC initiating
> connection did
> not reach any
> conclusion.
I don't think the MG needs a TCP server

Brian
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 08:57:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10605
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 08:57:32 -0400 (EDT)
Received: from standards (47.234.32.16:2328) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78BD4@standards.nortelnetworks.com>; Tue, 27 Jun 2000 8:46:06 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1318 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 08:46:06 -0400
Received: from smtprich. (47.100.129.12:37568) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB78BC4@standards.nortelnetworks.com>; Tue, 27 Jun 2000 8:36:00
          -0400
Received: from zrchb213.us.nortel.com by smtprich. (SMI-8.6/SMI-SVR4) id
          HAA27602; Tue, 27 Jun 2000 07:37:05 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <NQCKL474>; Tue, 27 Jun 2000 07:45:24 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480B0F@zcard00g.ca.nortel.com>
Date:         Tue, 27 Jun 2000 07:45:24 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: Tonegen Package
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

And my comments after yours.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Monday, June 26, 2000 9:20 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Tonegen Package
>
> Thanks for the reply.
>
> See comments below
>
> Tom-PT Taylor wrote:
>
>
>
>       Sorry to take so long to answer this.  If you check out the ABNF,
> you see that signal parameter syntax reduces to
>
>       NAME parmValue
>
>       As a result, the toneIDs themselves are NOT prefixed by package
> name.  The square bracket syntax denotes a sublist (from the
> alternativeValue production).  I think that's wrong: the package defines
> the parameter as a list, not a sub-list.  Thus curly brackets should be
> used, and the interpretation is "list of values" rather than "list of
> alternatives" because the package definition says so.
>
>
> <cnn> I agreed w/you about the curly bracket.  But I think you meant the
> square bracket syntax denotes
> an alternatives list.
        [PTT]
        No, check the alternativeValue production (reproduced below):

       alternativeValue     = ( VALUE
                                / LSBRKT VALUE *(COMMA VALUE) RSBRKT
                         ; sublist (i.e. A AND B AND ...)
                                / LBRKT VALUE *(COMMA VALUE) RBRKT
                                 ; alternatives (i.e. A OR B OR ...)
                                /  LSBRKT VALUE COLON VALUE RSBRKT )
                                         ; range

> So are you also saying that the ABNF needs to be clarified that sublist is
> the same thing as
> "list of values"?
        [PTT]
        I don't think it is, for two reasons: sublist doesn't imply ordering
(but of course, we should have specified "ordered list"or "sequence" in the
package description), and I'm not sure that sublist would allow repeated
values.  We had better be clear on this, so people should jump in if they
disagree that "list of values" for a parameter value implies the use of
curly brackets.
>
>
>
>
>       The fact that toneIDs are not prefixed by package name leads to
> potential ambiguity.  Either toneIDs have to be unique, which may implying
> an IANA registration process, or else we indicate which package the
> toneIDs come from by using the package name for the toneIDs instead of
> tonegen to prefix the pt signal.  The latter mechanism would restrict the
> playing of tones in one signal to a single package, so I think we have to
> go with unique toneIDs.  Therefore the correct syntax for your example is
>
>
> VALUE = quotedString / 1*(SafeChar)
> So why can't VALUE = "cg/rt" instead of just "rt"?
        [PTT]
        Primarily because the package defines the name to be "rt".  And I
really hope no one puts a slash where it doesn't belong.  At first
opportunity we should add that restriction to the rules for parameter
naming.

> But of course all these could get pretty hairy
> if we have several levels of extension.
> Does VALUE has a limit on # of characters?
>
> I guess this also depends on how the ASN deals with this.
>
>
>
>       [PTT]  ...
>
>
>       ---
>       Since Call Progress Tones Generator (cg) Package extends tonegen
> package,
>       it does not really mean that you have to use the following syntax to
> use cg:
>               Signals {tonegen/pt {tl = cg/dt}}
>
>               One can just do        Signals{cg/dt}
>       [PTT]
>       Sorry, no.  "dt" is not a signal, merely a possible value of a
> signal  parameter.
>
>
> <cnn>  I don't know about this because the cg package defines dt as either
> a signal id/tone id.
> In Appendix A, example cg/dt is used as
>             Signals {cg/dt}                Step 8, page 158
        [PTT]
        Oops, you're absolutely right.  So as you say, one can simply do
Signals { cg/dt }.  Not sure it was worth the bother to define the toneIDs
in the cg package, given that the signal list mechanism will play them in
sequence if absolutely necessary.

>
>
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 09:05:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10879
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 09:05:20 -0400 (EDT)
Received: from standards (47.234.32.16:2328) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78C02@standards.nortelnetworks.com>; Tue, 27 Jun 2000 8:55:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1400 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 08:55:27 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB78C01@standards.nortelnetworks.com>; Tue, 27 Jun 2000 8:55:27
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id JAA27369; Tue, 27 Jun 2000 09:04:52 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id JAA02660; Tue, 27 Jun 2000 09:04:52 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <NVY8H95R>; Tue, 27 Jun 2000 09:04:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6784D2@whq-msgusr-02.fore.com>
Date:         Tue, 27 Jun 2000 09:04:52 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Termination ID in request
X-To:         "rezhirpavai@HSS.HNS.COM" <rezhirpavai@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

>      As regards the second query, it could be possible that
> MGC instructs MG to
> detect for 'OFF HOOK" for a group of terminations (through
> wildcarding). MG on
> detection of
> "OFF HOOK" for a set of terminations (almost at the same
> time), can club these
> Notifications and
> send back Notify wildcarded!!

I believe the syntax allows this, so the MGC had better be
prepared to deal with it.  I'd be surprised if it was implemented
for off hook, but for some kind of error, it might be worthwhile.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 10:02:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12914
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 10:02:01 -0400 (EDT)
Received: from standards (47.234.32.16:1995) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78C3E@standards.nortelnetworks.com>; Tue, 27 Jun 2000 9:51:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1468 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 09:51:59 -0400
Received: from mail12.freechal.com (211.169.243.57:53460) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB78C35@standards.nortelnetworks.com>; Tue, 27 Jun 2000
          9:41:58 -0400
Received: from nt09 (10.6.0.9) by mail12.freechal.com (NPlex 4.5.049) id
          3951FE570000597B for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun
          2000 22:51:24 +0900
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=1530.962113882781FreechalMail
X-Priority: 3
X-Mailer: Freechal Mailer version 1.1
Message-ID:  <1519.962113882781.JavaMail.Administrator@smtp01>
Date:         Tue, 27 Jun 2000 22:51:22 +0900
Reply-To: =?EUC-KR?B?wPzH/MHY?= <hjjun@freechal.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: =?EUC-KR?B?wPzH/MHY?= <hjjun@freechal.com>
Subject:      The difference between MGCP & MEGACO
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Mime Prologue

--1530.962113882781FreechalMail
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 8bit

i'm preparing to implement mgc and mg which supports mgcp, because, as i know,
megaco is not yet fixed as an standard.
but we still want to design the mgcp supporting mgc and mg easily migrate to support megaco.

so i investigated the differences, cons & pros between those two protocols.
i found that mgcp only defines text encoding, but megaco guides to mgc support text and binary
encoding. the gateway control commands look similar(only a few differences in their names and
syntax). megaco supports tcp (i think it's for binary encoding.).

is there anybody who can explain the other differences between mgcp and megaco?
and could you advise me how to design mgcp mgc and mg to easily move to megaco supporting systems?

thanks in advance!
--1530.962113882781FreechalMail
Content-Type: text/html; charset=EUC-KR
Content-Transfer-Encoding: 7bit

<html>
<head>
<style>P {margin-top:2px;margin-bottom:2px;}</style>
</head>
<body>
<P>I'm preparing to implement MGC and MG which supports MGCP, because, as I know,</P>
<P>MEGACO is not yet fixed as an standard.</P>
<P>But we still want to design the MGCP&nbsp;supporting MGC and MG&nbsp;easily migrate to support MEGACO.</P>
<P>&nbsp;</P>
<P>So I&nbsp;investigated the differences, cons &amp; pros between those two protocols.</P>
<P>I found that MGCP only defines text encoding, but MEGACO guides to MGC support text and binary</P>
<P>encoding. The gateway control commands&nbsp;look similar(Only a few differences in their names and</P>
<P>syntax). MEGACO supports TCP (I think it's for binary encoding.).</P>
<P>&nbsp;</P>
<P>Is there anybody who can explain the other differences between MGCP and MEGACO?</P>
<P>And could you advise me how to design MGCP MGC and MG to easily move to MEGACO supporting systems?</P>
<P>&nbsp;</P>
<P>Thanks in advance!</P>
</body>
</html>
--1530.962113882781FreechalMail--
Mime Epilogue


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 10:34:41 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13900
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 10:34:40 -0400 (EDT)
Received: from standards (47.234.32.16:1995) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78C63@standards.nortelnetworks.com>; Tue, 27 Jun 2000 10:24:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1524 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 10:24:38 -0400
Received: from qhars002.nortel.com (47.101.112.102:45901) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB78C62@standards.nortelnetworks.com>; Tue, 27 Jun 2000
          10:24:37 -0400
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          qhars002.nortel.com; Tue, 27 Jun 2000 15:33:16 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Tue, 27 Jun 2000 10:31:58 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <NQCATFYK>; Tue, 27 Jun 2000 10:31:55 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480B16@zcard00g.ca.nortel.com>
Date:         Tue, 27 Jun 2000 10:31:48 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: The difference between MGCP & MEGACO
X-To:         ??? <hjjun@freechal.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Just to correct your first misconception: Megaco/H.248 is a standard twice
over.  It has been approved both by the IESG and by the ITU-T.

You might try Hughes Software Systems for their paper on the differences
between the protocols.

> -----Original Message-----
> From: hjjun@FREECHAL.COM [SMTP:hjjun@FREECHAL.COM]
> Sent: Tuesday, June 27, 2000 9:51 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      The difference between MGCP & MEGACO
>
> I'm preparing to implement MGC and MG which supports MGCP, because, as I
> know,
>
> MEGACO is not yet fixed as an standard.
>
> But we still want to design the MGCP supporting MGC and MG easily migrate
> to support MEGACO.
>
>
>
> So I investigated the differences, cons & pros between those two
> protocols.
>
> I found that MGCP only defines text encoding, but MEGACO guides to MGC
> support text and binary
>
> encoding. The gateway control commands look similar(Only a few differences
> in their names and
>
> syntax). MEGACO supports TCP (I think it's for binary encoding.).
>
>
>
> Is there anybody who can explain the other differences between MGCP and
> MEGACO?
>
> And could you advise me how to design MGCP MGC and MG to easily move to
> MEGACO supporting systems?
>
>
>
> Thanks in advance!
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 10:39:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14018
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 10:39:20 -0400 (EDT)
Received: from standards (47.234.32.16:1995) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78C77@standards.nortelnetworks.com>; Tue, 27 Jun 2000 10:29:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1520 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 10:29:13 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB78C5F@standards.nortelnetworks.com>; Tue, 27 Jun 2000 10:19:13
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          JAA20357 for <megaco@standards.nortelnetworks.com>; Tue, 27 Jun 2000
          09:26:37 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay1.usa.alcatel.com
          [143.209.238.6]) by fw7 via smap (V2.1) id xma020259; Tue, 27 Jun 00
          09:26:05 -0500
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id JAA15238 for
          <megaco@standards.nortelnetworks.com>; Tue, 27 Jun 2000 09:25:09
          -0500 (CDT)
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id JAA20607 for <megaco@standards.nortelnetworks.com>; Tue, 27
          Jun 2000 09:24:25 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA02674
          for <megaco@standards.nortelnetworks.com>; Tue, 27 Jun 2000 09:24:25
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480B0B@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------020181BB8FC4B93D888BBA0C"
Message-ID:  <3958B918.BF551C71@usa.alcatel.com>
Date:         Tue, 27 Jun 2000 09:24:24 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: Tonegen Package
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------020181BB8FC4B93D888BBA0C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom-PT Taylor wrote:

>      Can someone show a real world scenario and syntax on how tonegen
>      package is used?
>
<cnn> Sorry I meant an example of tonegen and cg being used together.
            I think your example 2 could have been done w/o using
tonegen.


>
>      [PTT]
>      Two cases:
>
>      Case 1: DTMF outpulsing of the digits "5551212" (e.g. on a PBX
>      trunk), with 10 ms gaps between the individual tones.
>
>         Signals { tonegen/pt {tl = {d5, d5, d5, d1, d2, d1, d2},
>      ind=10} }
>
>      Case 2: Play ringing tone for a maximum of 3 minutes.  Notify the
>      MGC if the tone terminates abnormally or by timeout.  (No
>      notification is needed if the tone is interrupted by an event or
>      replacement.)  If any signals remain active when the signal
>      completion event is recognized, allow them to continue.
>
>         Signals { tonegen/pt {tl = {rg}, ind=0, sy=to, nc= {to, or} },
>
>         Events = 666 { g/sc{ka} }
>
<cnn>  Maybe it is just me but this look pretty challenging and time
consuming to parse.
             How would one knows that tl, ind, sy, nc and ka represent
package parameter name
             versus Megaco token name?
             One would have to make sure that it is not a Megaco token
name first.
             Then search through all package databases that extend
tonegen package.


             tonegen package: signal type = Brief and duration =
Provisioned.
             cg package          : signal type = Timeout and duration =
Provisioned

             Does cg package (cg) override tonegen signal type, etc?
             So in general does extension package overide package that
it extends?

             Is there any restriction that "tl" can only contain tone
from one package or multiple
             packages as long as these packages extend tonegen?

             Do you know where I can find all the packages defined so
far.
             One would have to build some kind of tree to keep track of
these package extension.
             It would be a nightmare if one is looking at binary values
of these package
             parameter Ids in hex.

Thanks
Chuong



--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------020181BB8FC4B93D888BBA0C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Tom-PT Taylor wrote:
<blockquote TYPE=CITE>
<ul><font face="Arial"><font size=-1>Can someone show a real world scenario
and syntax on how tonegen package is used?</font></font></ul>
</blockquote>
&lt;cnn> Sorry I meant an example of tonegen and cg being used together.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
I think your example 2 could have been done w/o using tonegen.
<br>&nbsp;
<blockquote TYPE=CITE>
<ul><font face="Arial"><font size=-1></font></font>&nbsp;
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[PTT]</font></font></font></i></b>
<br><font face="Arial"><font color="#0000FF"><font size=-1>Two cases:</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>Case 1: DTMF
outpulsing of the digits "5551212" (e.g. on a PBX trunk), with 10 ms gaps
between the individual tones.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;
Signals { tonegen/pt {tl = {d5, d5, d5, d1, d2, d1, d2}, ind=10} }</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>Case 2: Play
ringing tone for a maximum of 3 minutes.&nbsp; Notify the MGC if the tone
terminates abnormally or by timeout.&nbsp; (No notification is needed if
the tone is interrupted by an event or replacement.)&nbsp; If any signals
remain active when the signal completion event is recognized, allow them
to continue.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;
Signals { tonegen/pt {tl = {rg}, ind=0, sy=to, nc= {to, or} },</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;
Events = 666 { g/sc{ka} }</font></font></font></ul>
</blockquote>
&lt;cnn>&nbsp; Maybe it is just me but this look pretty challenging and
time consuming to parse.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
How would one knows that tl, ind, sy, nc and ka represent package parameter
name
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
versus Megaco token name?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
One would have to make sure that it is not a Megaco token name first.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Then search through all package databases that extend tonegen package.
<br>&nbsp;
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
tonegen package: signal type = Brief and duration = Provisioned.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
cg package&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : signal
type = Timeout and duration = Provisioned
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Does cg package (cg) override tonegen signal type, etc?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
So in general does extension package overide package that it extends?
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Is there any restriction that "tl" can only contain tone from one package
or multiple
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
packages as long as these packages extend tonegen?
<br>&nbsp;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Do you know where I can find all the packages defined so far.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
One would have to build some kind of tree to keep track of these package
extension.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
It would be a nightmare if one is looking at binary values of these package
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
parameter Ids in hex.
<p>Thanks
<br>Chuong
<br>&nbsp;
<br>&nbsp;
<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------020181BB8FC4B93D888BBA0C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 14:16:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20133
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 14:16:55 -0400 (EDT)
Received: from standards (47.234.32.16:4988) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78D51@standards.nortelnetworks.com>; Tue, 27 Jun 2000 14:06:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1824 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 14:06:48 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB78D48@standards.nortelnetworks.com>; Tue, 27 Jun 2000 13:56:47
          -0400
Received: from cisco.com (sj-dial-1-75.cisco.com [171.68.179.76]) by
          mailman.cisco.com (8.9.3/8.9.1) with ESMTP id LAA13406; Tue, 27 Jun
          2000 11:06:11 -0700 (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF6784BC@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3958EDE4.8300F90B@cisco.com>
Date:         Tue, 27 Jun 2000 14:09:41 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Subject:      Re: Event Detection
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:

> Hmm, did you just see the message from Chuong Nguyen or
> is there a warp in the space/time fabric of the universe?
>
> The reply is the same - events are scoped to a termination,
> not a context.  Off hook is not detectable on the RTP.
> It occurs to me to wonder if this is the same as MGCP.

It is. In MGCP, if you want to detect an event on the endpoint you use the
normal event detection syntax, i.e. simply include the event in the list of
RequestedEvents for the endpoint. If you want to detect the event on the
connection, you use the "event@connection" syntax instead however not all
events can be detected on a connection (and vice versa actually). The
off-hook event (as defined right now) cannot be detected on a connection.

One note related to Chuong's message. MGCP's single endpoint model
inherently contains the synchronization you are looking for to turn off
ringback on a connection when detecting off-hook on the endpoint. To achieve
something similar in Megaco's dual endpoint model, you either need some form
of script as Brian suggested, or an event/signal construct similar to MGCP's
"@connection", e.g. "@termination". You could for example achieve the latter
by simply defining such a signal and define the semantics accordingly - the
worst that can happen is that the protocol police will come looking for you.

-- Flemming


>
> We intended it to be.  You can set an event using a
> wildcard, as with MGCP, but I think that detection is
> on an endpoint, not a connection, and you can't stop
> the ringback signal on the RTP with the off hook event
> on the analog line.
>
> Stream mode does not affect events.
>
> You can't have a Media Descriptor in an embedded event.
>
> Brian
>
> > -----Original Message-----
> > From: Mario Monteiro [mailto:mmonteir@USA.ALCATEL.COM]
> > Sent: Friday, June 23, 2000 10:29 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Event Detection
> >
> >
> > If there are two termination ids within a context, an SCN and an RTP
> > termination, will an event which occurs on the SCN termination also be
> > "seen" at the RTP termination?
> >
> > The specific case I am refering to is a terminating circuit where an
> > off-hook (answer) detected on the SCN is also seen at the RTP. The RTP
> > termination is connected via a IP network path to the
> > originating side.
> > Would like this event detection to trigger removal of the
> > signal applied
> > at the RTP (KeepActive off and off-hook event detection at RTP armed)
> > when the off-hook occurs. Also is my understanding correct that the
> > StreamMode at the RTP termination does not affect this event
> > detection?
> >
> > Another question. Can the MediaDescriptor (StreamMode) be set as an
> > embedded event such that the stream mode gets changed when a specified
> > event occurs? Only noticed Signal Descriptor and Event
> > Descriptor in the
> > spec.
> >
> > An eary response will be much appreciated.
> >

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 14:42:13 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21455
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 14:42:13 -0400 (EDT)
Received: from standards (47.234.32.16:4988) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78D89@standards.nortelnetworks.com>; Tue, 27 Jun 2000 14:32:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1883 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 14:32:02 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB78D74@standards.nortelnetworks.com>; Tue, 27 Jun 2000 14:22:02
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          NAA00024 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 27 Jun 2000
          13:29:19 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay1.usa.alcatel.com
          [143.209.238.6]) by fw7 via smap (V2.1) id xma029822; Tue, 27 Jun 00
          13:28:44 -0500
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id NAA28439 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 27 Jun 2000 13:31:10
          -0500 (CDT)
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id NAA27571 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 27
          Jun 2000 13:29:37 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA03409
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 27 Jun 2000 13:29:37
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF6784BC@whq-msgusr-02.fore.com>
            <3958EDE4.8300F90B@cisco.com>
Content-Type: multipart/alternative;
              boundary="------------F88635EBD65AFDA4C8EF0FE4"
Message-ID:  <3958F290.5B639595@usa.alcatel.com>
Date:         Tue, 27 Jun 2000 13:29:36 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: Event Detection
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------F88635EBD65AFDA4C8EF0FE4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Well Tom can something be done now?

It is a very important feature which can prevent speech clipping.
If the off-hook detected by the endpoint (TDM termination) has to result in MG
sending a notify to MGC.
Upon which MGC has to send a Modify to connection (RTP termination) to stop
ringback.
If there is any network delay, speech clipping could be pronounced.

I thought one of the goal of Megaco is to at a minimun maintain the same
capability as MGCP.

I guess the MG can always buffer the speech until the RTP ringing is stopped.
Or just send the speech w/the ringing until ringing is stopped by MGC.
Or somehow has the MG detected speech ("signal"?) and stop ringing - a new
package?


Thanks
Chuong

Flemming Andreasen wrote:

> "Rosen, Brian" wrote:
>
> > Hmm, did you just see the message from Chuong Nguyen or
> > is there a warp in the space/time fabric of the universe?
> >
> > The reply is the same - events are scoped to a termination,
> > not a context.  Off hook is not detectable on the RTP.
> > It occurs to me to wonder if this is the same as MGCP.
>
> It is. In MGCP, if you want to detect an event on the endpoint you use the
> normal event detection syntax, i.e. simply include the event in the list of
> RequestedEvents for the endpoint. If you want to detect the event on the
> connection, you use the "event@connection" syntax instead however not all
> events can be detected on a connection (and vice versa actually). The
> off-hook event (as defined right now) cannot be detected on a connection.
>
> One note related to Chuong's message. MGCP's single endpoint model
> inherently contains the synchronization you are looking for to turn off
> ringback on a connection when detecting off-hook on the endpoint. To achieve
> something similar in Megaco's dual endpoint model, you either need some form
> of script as Brian suggested, or an event/signal construct similar to MGCP's
> "@connection", e.g. "@termination". You could for example achieve the latter
> by simply defining such a signal and define the semantics accordingly - the
> worst that can happen is that the protocol police will come looking for you.
>
> -- Flemming
>
> >
> > We intended it to be.  You can set an event using a
> > wildcard, as with MGCP, but I think that detection is
> > on an endpoint, not a connection, and you can't stop
> > the ringback signal on the RTP with the off hook event
> > on the analog line.
> >
> > Stream mode does not affect events.
> >
> > You can't have a Media Descriptor in an embedded event.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Mario Monteiro [mailto:mmonteir@USA.ALCATEL.COM]
> > > Sent: Friday, June 23, 2000 10:29 AM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Event Detection
> > >
> > >
> > > If there are two termination ids within a context, an SCN and an RTP
> > > termination, will an event which occurs on the SCN termination also be
> > > "seen" at the RTP termination?
> > >
> > > The specific case I am refering to is a terminating circuit where an
> > > off-hook (answer) detected on the SCN is also seen at the RTP. The RTP
> > > termination is connected via a IP network path to the
> > > originating side.
> > > Would like this event detection to trigger removal of the
> > > signal applied
> > > at the RTP (KeepActive off and off-hook event detection at RTP armed)
> > > when the off-hook occurs. Also is my understanding correct that the
> > > StreamMode at the RTP termination does not affect this event
> > > detection?
> > >
> > > Another question. Can the MediaDescriptor (StreamMode) be set as an
> > > embedded event such that the stream mode gets changed when a specified
> > > event occurs? Only noticed Signal Descriptor and Event
> > > Descriptor in the
> > > spec.
> > >
> > > An eary response will be much appreciated.
> > >
>
> --
> Flemming Andreasen                Phone: +1 732 452 1667
> Cisco Systems                     Fax:   +1 240 359 5839

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------F88635EBD65AFDA4C8EF0FE4
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Well Tom can something be done now?
<p>It is a very important feature which can prevent speech clipping.
<br>If the off-hook detected by the endpoint (TDM termination) has to result
in MG sending a notify to MGC.
<br>Upon which MGC has to send a Modify to connection (RTP termination)
to stop ringback.
<br>If there is any network delay, speech clipping could be pronounced.
<p>I&nbsp;thought one of the goal of Megaco is to at a minimun maintain
the same capability as MGCP.
<p>I&nbsp;guess the MG can always buffer the speech until the RTP ringing
is stopped.
<br>Or just send the speech w/the ringing until ringing is stopped by MGC.
<br>Or somehow has the MG detected speech ("signal"?) and stop ringing
- a new package?
<br>&nbsp;
<p>Thanks
<br>Chuong
<p>Flemming Andreasen wrote:
<blockquote TYPE=CITE>"Rosen, Brian" wrote:
<p>> Hmm, did you just see the message from Chuong Nguyen or
<br>> is there a warp in the space/time fabric of the universe?
<br>>
<br>> The reply is the same - events are scoped to a termination,
<br>> not a context.&nbsp; Off hook is not detectable on the RTP.
<br>> It occurs to me to wonder if this is the same as MGCP.
<p>It is. In MGCP, if you want to detect an event on the endpoint you use
the
<br>normal event detection syntax, i.e. simply include the event in the
list of
<br>RequestedEvents for the endpoint. If you want to detect the event on
the
<br>connection, you use the "event@connection" syntax instead however not
all
<br>events can be detected on a connection (and vice versa actually). The
<br>off-hook event (as defined right now) cannot be detected on a connection.
<p>One note related to Chuong's message. MGCP's single endpoint model
<br>inherently contains the synchronization you are looking for to turn
off
<br>ringback on a connection when detecting off-hook on the endpoint. To
achieve
<br>something similar in Megaco's dual endpoint model, you either need
some form
<br>of script as Brian suggested, or an event/signal construct similar
to MGCP's
<br>"@connection", e.g. "@termination". You could for example achieve the
latter
<br>by simply defining such a signal and define the semantics accordingly
- the
<br>worst that can happen is that the protocol police will come looking
for you.
<p>-- Flemming
<p>>
<br>> We intended it to be.&nbsp; You can set an event using a
<br>> wildcard, as with MGCP, but I think that detection is
<br>> on an endpoint, not a connection, and you can't stop
<br>> the ringback signal on the RTP with the off hook event
<br>> on the analog line.
<br>>
<br>> Stream mode does not affect events.
<br>>
<br>> You can't have a Media Descriptor in an embedded event.
<br>>
<br>> Brian
<br>>
<br>> > -----Original Message-----
<br>> > From: Mario Monteiro [<a href="mailto:mmonteir@USA.ALCATEL.COM">mailto:mmonteir@USA.ALCATEL.COM</a>]
<br>> > Sent: Friday, June 23, 2000 10:29 AM
<br>> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
<br>> > Subject: Event Detection
<br>> >
<br>> >
<br>> > If there are two termination ids within a context, an SCN and an
RTP
<br>> > termination, will an event which occurs on the SCN termination
also be
<br>> > "seen" at the RTP termination?
<br>> >
<br>> > The specific case I am refering to is a terminating circuit where
an
<br>> > off-hook (answer) detected on the SCN is also seen at the RTP.
The RTP
<br>> > termination is connected via a IP network path to the
<br>> > originating side.
<br>> > Would like this event detection to trigger removal of the
<br>> > signal applied
<br>> > at the RTP (KeepActive off and off-hook event detection at RTP
armed)
<br>> > when the off-hook occurs. Also is my understanding correct that
the
<br>> > StreamMode at the RTP termination does not affect this event
<br>> > detection?
<br>> >
<br>> > Another question. Can the MediaDescriptor (StreamMode) be set as
an
<br>> > embedded event such that the stream mode gets changed when a specified
<br>> > event occurs? Only noticed Signal Descriptor and Event
<br>> > Descriptor in the
<br>> > spec.
<br>> >
<br>> > An eary response will be much appreciated.
<br>> >
<p>--
<br>Flemming Andreasen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Phone: +1 732 452 1667
<br>Cisco Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax:&nbsp;&nbsp; +1 240 359 5839</blockquote>

<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------F88635EBD65AFDA4C8EF0FE4--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 15:05:53 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22157
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 15:05:52 -0400 (EDT)
Received: from standards (47.234.32.16:4988) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78DC9@standards.nortelnetworks.com>; Tue, 27 Jun 2000 14:55:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1994 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 14:55:48 -0400
Received: from qhars002.nortel.com (47.101.112.102:37574) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB78DC8@standards.nortelnetworks.com>; Tue, 27 Jun 2000
          14:55:48 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Tue, 27 Jun 2000 20:01:22 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Tue, 27 Jun 2000 13:49:22 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <NQCKMHCP>; Tue, 27 Jun 2000 13:50:54 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480B1A@zcard00g.ca.nortel.com>
Date:         Tue, 27 Jun 2000 13:50:39 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Event Detection
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I think you've got the ends of the conversation confused.  Off-hook happens
in the terminating MG, while ringback happens in the originating MG.  The
originating MG has no in-band way of detecting that the called party has
answered.  Instead, the terminating MG tells the terminating MGC, which
signals the originating MGC, which in turn modifies the terminations
associated with the call in the originating MG.  Agreed that speech clipping
could occur, but this is a normal hazard of VoIP operation.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Tuesday, June 27, 2000 2:30 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Event Detection
>
> Well Tom can something be done now?
>
> It is a very important feature which can prevent speech clipping.
> If the off-hook detected by the endpoint (TDM termination) has to result
> in MG sending a notify to MGC.
> Upon which MGC has to send a Modify to connection (RTP termination) to
> stop ringback.
> If there is any network delay, speech clipping could be pronounced.
>
> I thought one of the goal of Megaco is to at a minimun maintain the same
> capability as MGCP.
>
> I guess the MG can always buffer the speech until the RTP ringing is
> stopped.
> Or just send the speech w/the ringing until ringing is stopped by MGC.
> Or somehow has the MG detected speech ("signal"?) and stop ringing - a new
> package?
>
>
> Thanks
> Chuong
>
> Flemming Andreasen wrote:
>
>       "Rosen, Brian" wrote:
>
>       > Hmm, did you just see the message from Chuong Nguyen or
>       > is there a warp in the space/time fabric of the universe?
>       >
>       > The reply is the same - events are scoped to a termination,
>       > not a context.  Off hook is not detectable on the RTP.
>       > It occurs to me to wonder if this is the same as MGCP.
>
>       It is. In MGCP, if you want to detect an event on the endpoint you
> use the
>       normal event detection syntax, i.e. simply include the event in the
> list of
>       RequestedEvents for the endpoint. If you want to detect the event on
> the
>       connection, you use the "event@connection" syntax instead however
> not all
>       events can be detected on a connection (and vice versa actually).
> The
>       off-hook event (as defined right now) cannot be detected on a
> connection.
>
>       One note related to Chuong's message. MGCP's single endpoint model
>       inherently contains the synchronization you are looking for to turn
> off
>       ringback on a connection when detecting off-hook on the endpoint. To
> achieve
>       something similar in Megaco's dual endpoint model, you either need
> some form
>       of script as Brian suggested, or an event/signal construct similar
> to MGCP's
>       "@connection", e.g. "@termination". You could for example achieve
> the latter
>       by simply defining such a signal and define the semantics
> accordingly - the
>       worst that can happen is that the protocol police will come looking
> for you.
>
>       -- Flemming
>
>       >
>       > We intended it to be.  You can set an event using a
>       > wildcard, as with MGCP, but I think that detection is
>       > on an endpoint, not a connection, and you can't stop
>       > the ringback signal on the RTP with the off hook event
>       > on the analog line.
>       >
>       > Stream mode does not affect events.
>       >
>       > You can't have a Media Descriptor in an embedded event.
>       >
>       > Brian
>       >
>       > > -----Original Message-----
>       > > From: Mario Monteiro [ <mailto:mmonteir@USA.ALCATEL.COM>]
>       > > Sent: Friday, June 23, 2000 10:29 AM
>       > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>       > > Subject: Event Detection
>       > >
>       > >
>       > > If there are two termination ids within a context, an SCN and an
> RTP
>       > > termination, will an event which occurs on the SCN termination
> also be
>       > > "seen" at the RTP termination?
>       > >
>       > > The specific case I am refering to is a terminating circuit
> where an
>       > > off-hook (answer) detected on the SCN is also seen at the RTP.
> The RTP
>       > > termination is connected via a IP network path to the
>       > > originating side.
>       > > Would like this event detection to trigger removal of the
>       > > signal applied
>       > > at the RTP (KeepActive off and off-hook event detection at RTP
> armed)
>       > > when the off-hook occurs. Also is my understanding correct that
> the
>       > > StreamMode at the RTP termination does not affect this event
>       > > detection?
>       > >
>       > > Another question. Can the MediaDescriptor (StreamMode) be set as
> an
>       > > embedded event such that the stream mode gets changed when a
> specified
>       > > event occurs? Only noticed Signal Descriptor and Event
>       > > Descriptor in the
>       > > spec.
>       > >
>       > > An eary response will be much appreciated.
>       > >
>
>       --
>       Flemming Andreasen                Phone: +1 732 452 1667
>       Cisco Systems                     Fax:   +1 240 359 5839
>
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 15:45:48 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22894
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 15:45:48 -0400 (EDT)
Received: from standards (47.234.32.16:3164) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78DF7@standards.nortelnetworks.com>; Tue, 27 Jun 2000 15:35:06 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2042 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 15:35:06 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB78DED@standards.nortelnetworks.com>; Tue, 27 Jun 2000 15:25:05
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          OAA19330 for <megaco@standards.nortelnetworks.com>; Tue, 27 Jun 2000
          14:32:30 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay1.usa.alcatel.com
          [143.209.238.6]) by fw7 via smap (V2.1) id xma019188; Tue, 27 Jun 00
          14:32:10 -0500
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id OAA01693 for
          <megaco@standards.nortelnetworks.com>; Tue, 27 Jun 2000 14:31:10
          -0500 (CDT)
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id OAA05346 for <megaco@standards.nortelnetworks.com>; Tue, 27
          Jun 2000 14:30:02 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA03561
          for <megaco@standards.nortelnetworks.com>; Tue, 27 Jun 2000 14:30:02
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480B1A@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------93D6E760690CFDC6A18E2BFC"
Message-ID:  <395900B9.BEFE7265@usa.alcatel.com>
Date:         Tue, 27 Jun 2000 14:30:02 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: Event Detection
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------93D6E760690CFDC6A18E2BFC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The approach that I am talking about is different than the one given in
Appendix A example.

What we want to do is apply ringing to the terminating TDM (al/ri) and
RTP (cg/rt) terminations
and upon detection of off-hook at the TDM termnation, we want to be able
to stop
the signals, al/ri and cg/rt respectively at TDM and RTP terminations.

The cg/rt will get propagated from the terminating RTP termination to
the originating RTP
termination thus to the originating TDM termination and finally to the
caller.

With Appendix A, example, the ringing is applied at the orginating and
termination TDM terminations.
Thus requiring a Notify be sent from terminating MG to MGC upon
detection of off-hook at the
terminating TDM termination.
Upon receipt of the Notify by MGC, MGC sends a Modify to originating MW
to turn off ringing
at the originating TDM termination.

We are trying to cut out the Notify and Modify messages to prevent any
possible
speech clipping.

Any thoughts on this approach?


Tom-PT Taylor wrote:

>
>
> I think you've got the ends of the conversation confused.  Off-hook
> happens in the terminating MG, while ringback happens in the
> originating MG.  The originating MG has no in-band way of detecting
> that the called party has answered.  Instead, the terminating MG tells
> the terminating MGC, which signals the originating MGC, which in turn
> modifies the terminations associated with the call in the originating
> MG.  Agreed that speech clipping could occur, but this is a normal
> hazard of VoIP operation.
>
>      -----Original Message-----
>      From:  Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
>      Sent:  Tuesday, June 27, 2000 2:30 PM
>      To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:       Re: Event Detection
>
>      Well Tom can something be done now?
>
>      It is a very important feature which can prevent speech clipping.
>
>      If the off-hook detected by the endpoint (TDM termination) has to
>      result in MG sending a notify to MGC.
>      Upon which MGC has to send a Modify to connection (RTP
>      termination) to stop ringback.
>      If there is any network delay, speech clipping could be
>      pronounced.
>
>      I thought one of the goal of Megaco is to at a minimun maintain
>      the same capability as MGCP.
>
>      I guess the MG can always buffer the speech until the RTP ringing
>      is stopped.
>      Or just send the speech w/the ringing until ringing is stopped by
>      MGC.
>      Or somehow has the MG detected speech ("signal"?) and stop
>      ringing - a new package?
>
>
>      Thanks
>      Chuong
>
>      Flemming Andreasen wrote:
>           "Rosen, Brian" wrote:
>
>           > Hmm, did you just see the message from Chuong Nguyen or
>           > is there a warp in the space/time fabric of the universe?
>           >
>           > The reply is the same - events are scoped to a
>           termination,
>           > not a context.  Off hook is not detectable on the RTP.
>           > It occurs to me to wonder if this is the same as MGCP.
>
>           It is. In MGCP, if you want to detect an event on the
>           endpoint you use the
>           normal event detection syntax, i.e. simply include the event
>           in the list of
>           RequestedEvents for the endpoint. If you want to detect the
>           event on the
>           connection, you use the "event@connection" syntax instead
>           however not all
>           events can be detected on a connection (and vice versa
>           actually). The
>           off-hook event (as defined right now) cannot be detected on
>           a connection.
>
>           One note related to Chuong's message. MGCP's single endpoint
>           model
>           inherently contains the synchronization you are looking for
>           to turn off
>           ringback on a connection when detecting off-hook on the
>           endpoint. To achieve
>           something similar in Megaco's dual endpoint model, you
>           either need some form
>           of script as Brian suggested, or an event/signal construct
>           similar to MGCP's
>           "@connection", e.g. "@termination". You could for example
>           achieve the latter
>           by simply defining such a signal and define the semantics
>           accordingly - the
>           worst that can happen is that the protocol police will come
>           looking for you.
>
>           -- Flemming
>
>           >
>           > We intended it to be.  You can set an event using a
>           > wildcard, as with MGCP, but I think that detection is
>           > on an endpoint, not a connection, and you can't stop
>           > the ringback signal on the RTP with the off hook event
>           > on the analog line.
>           >
>           > Stream mode does not affect events.
>           >
>           > You can't have a Media Descriptor in an embedded event.
>           >
>           > Brian
>           >
>           > > -----Original Message-----
>           > > From: Mario Monteiro [
>           <mailto:mmonteir@USA.ALCATEL.COM>]
>           > > Sent: Friday, June 23, 2000 10:29 AM
>           > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>           > > Subject: Event Detection
>           > >
>           > >
>           > > If there are two termination ids within a context, an
>           SCN and an RTP
>           > > termination, will an event which occurs on the SCN
>           termination also be
>           > > "seen" at the RTP termination?
>           > >
>           > > The specific case I am refering to is a terminating
>           circuit where an
>           > > off-hook (answer) detected on the SCN is also seen at
>           the RTP. The RTP
>           > > termination is connected via a IP network path to the
>           > > originating side.
>           > > Would like this event detection to trigger removal of
>           the
>           > > signal applied
>           > > at the RTP (KeepActive off and off-hook event detection
>           at RTP armed)
>           > > when the off-hook occurs. Also is my understanding
>           correct that the
>           > > StreamMode at the RTP termination does not affect this
>           event
>           > > detection?
>           > >
>           > > Another question. Can the MediaDescriptor (StreamMode)
>           be set as an
>           > > embedded event such that the stream mode gets changed
>           when a specified
>           > > event occurs? Only noticed Signal Descriptor and Event
>           > > Descriptor in the
>           > > spec.
>           > >
>           > > An eary response will be much appreciated.
>           > >
>
>           --
>           Flemming Andreasen                Phone: +1 732 452 1667
>           Cisco Systems                     Fax:   +1 240 359 5839
>      --
>        Alcatel USA, Inc             Internet:
>      Chuong.Nguyen@usa.alcatel.com
>        1000 Coit Road Plano, Texas 75075           Phone:    (972)
>      519-4613
>        **** The opinions expressed are not those of Alcatel USA, Inc
>      ****
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------93D6E760690CFDC6A18E2BFC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
The approach that I&nbsp;am talking about is different than the one given
in Appendix A example.
<p>What we want to do is apply ringing to the terminating TDM (al/ri) and
RTP&nbsp;(cg/rt) terminations
<br>and upon detection of off-hook at the TDM termnation, we want to be
able to stop
<br>the signals, al/ri and cg/rt respectively at TDM and RTP terminations.
<p>The cg/rt will get propagated from the terminating RTP termination to
the originating RTP
<br>termination thus to the originating TDM termination and finally to
the caller.
<p>With Appendix A, example, the ringing is applied at the orginating and
termination TDM terminations.
<br>Thus requiring a Notify be sent from terminating MG to MGC upon detection
of off-hook at the
<br>terminating TDM termination.
<br>Upon receipt of the Notify by MGC, MGC sends a Modify to originating
MW to turn off ringing
<br>at the originating TDM termination.
<p>We are trying to cut out the Notify and Modify messages to prevent any
possible
<br>speech clipping.
<p>Any thoughts on this approach?
<br>&nbsp;
<p>Tom-PT Taylor wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>I think you've
got the ends of the conversation confused.&nbsp; Off-hook happens in the
terminating MG, while ringback happens in the originating MG.&nbsp; The
originating MG has no in-band way of detecting that the called party has
answered.&nbsp; Instead, the terminating MG tells the terminating MGC,
which signals the originating MGC, which in turn modifies the terminations
associated with the call in the originating MG.&nbsp; Agreed that speech
clipping could occur, but this is a normal hazard of VoIP operation.</font></font></font>
<ul><font face="Arial"><font size=-2>-----Original Message-----</font></font>
<br><font face="Arial"><font size=-2><b>From:&nbsp; </b>Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]</font></font>
<br><font face="Arial"><font size=-2><b>Sent:&nbsp; </b>Tuesday, June 27,
2000 2:30 PM</font></font>
<br><font face="Arial"><font size=-2><b>To:&nbsp;&nbsp;&nbsp; </b>MEGACO@STANDARDS.NORTELNETWORKS.COM</font></font>
<br><font face="Arial"><font size=-2><b>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</b>Re: Event Detection</font></font>
<p><font face="Arial">Well Tom can something be done now?</font>
<p><font face="Arial">It is a very important feature which can prevent
speech clipping.</font>
<br><font face="Arial">If the off-hook detected by the endpoint (TDM termination)
has to result in MG sending a notify to MGC.</font>
<br><font face="Arial">Upon which MGC has to send a Modify to connection
(RTP termination) to stop ringback.</font>
<br><font face="Arial">If there is any network delay, speech clipping could
be pronounced.</font>
<p><font face="Arial">I thought one of the goal of Megaco is to at a minimun
maintain the same capability as MGCP.</font>
<p><font face="Arial">I guess the MG can always buffer the speech until
the RTP ringing is stopped.</font>
<br><font face="Arial">Or just send the speech w/the ringing until ringing
is stopped by MGC.</font>
<br><font face="Arial">Or somehow has the MG detected speech ("signal"?)
and stop ringing - a new package?</font>
<br>&nbsp;
<p><font face="Arial">Thanks</font>
<br><font face="Arial">Chuong</font>
<p><font face="Arial">Flemming Andreasen wrote:</font>
<ul><font face="Arial">"Rosen, Brian" wrote:</font>
<p><font face="Arial">> Hmm, did you just see the message from Chuong Nguyen
or</font>
<br><font face="Arial">> is there a warp in the space/time fabric of the
universe?</font>
<br><font face="Arial">></font>
<br><font face="Arial">> The reply is the same - events are scoped to a
termination,</font>
<br><font face="Arial">> not a context.&nbsp; Off hook is not detectable
on the RTP.</font>
<br><font face="Arial">> It occurs to me to wonder if this is the same
as MGCP.</font>
<p><font face="Arial">It is. In MGCP, if you want to detect an event on
the endpoint you use the</font>
<br><font face="Arial">normal event detection syntax, i.e. simply include
the event in the list of</font>
<br><font face="Arial">RequestedEvents for the endpoint. If you want to
detect the event on the</font>
<br><font face="Arial">connection, you use the "event@connection" syntax
instead however not all</font>
<br><font face="Arial">events can be detected on a connection (and vice
versa actually). The</font>
<br><font face="Arial">off-hook event (as defined right now) cannot be
detected on a connection.</font>
<p><font face="Arial">One note related to Chuong's message. MGCP's single
endpoint model</font>
<br><font face="Arial">inherently contains the synchronization you are
looking for to turn off</font>
<br><font face="Arial">ringback on a connection when detecting off-hook
on the endpoint. To achieve</font>
<br><font face="Arial">something similar in Megaco's dual endpoint model,
you either need some form</font>
<br><font face="Arial">of script as Brian suggested, or an event/signal
construct similar to MGCP's</font>
<br><font face="Arial">"@connection", e.g. "@termination". You could for
example achieve the latter</font>
<br><font face="Arial">by simply defining such a signal and define the
semantics accordingly - the</font>
<br><font face="Arial">worst that can happen is that the protocol police
will come looking for you.</font>
<p><font face="Arial">-- Flemming</font>
<p><font face="Arial">></font>
<br><font face="Arial">> We intended it to be.&nbsp; You can set an event
using a</font>
<br><font face="Arial">> wildcard, as with MGCP, but I think that detection
is</font>
<br><font face="Arial">> on an endpoint, not a connection, and you can't
stop</font>
<br><font face="Arial">> the ringback signal on the RTP with the off hook
event</font>
<br><font face="Arial">> on the analog line.</font>
<br><font face="Arial">></font>
<br><font face="Arial">> Stream mode does not affect events.</font>
<br><font face="Arial">></font>
<br><font face="Arial">> You can't have a Media Descriptor in an embedded
event.</font>
<br><font face="Arial">></font>
<br><font face="Arial">> Brian</font>
<br><font face="Arial">></font>
<br><font face="Arial">> > -----Original Message-----</font>
<br><font face="Arial">> > From: Mario Monteiro [<u> <font color="#0000FF">&lt;<a href="mailto:mmonteir@USA.ALCATEL.COM">mailto:mmonteir@USA.ALCATEL.COM</a>></font></u>]</font>
<br><font face="Arial">> > Sent: Friday, June 23, 2000 10:29 AM</font>
<br><font face="Arial">> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM</font>
<br><font face="Arial">> > Subject: Event Detection</font>
<br><font face="Arial">> ></font>
<br><font face="Arial">> ></font>
<br><font face="Arial">> > If there are two termination ids within a context,
an SCN and an RTP</font>
<br><font face="Arial">> > termination, will an event which occurs on the
SCN termination also be</font>
<br><font face="Arial">> > "seen" at the RTP termination?</font>
<br><font face="Arial">> ></font>
<br><font face="Arial">> > The specific case I am refering to is a terminating
circuit where an</font>
<br><font face="Arial">> > off-hook (answer) detected on the SCN is also
seen at the RTP. The RTP</font>
<br><font face="Arial">> > termination is connected via a IP network path
to the</font>
<br><font face="Arial">> > originating side.</font>
<br><font face="Arial">> > Would like this event detection to trigger removal
of the</font>
<br><font face="Arial">> > signal applied</font>
<br><font face="Arial">> > at the RTP (KeepActive off and off-hook event
detection at RTP armed)</font>
<br><font face="Arial">> > when the off-hook occurs. Also is my understanding
correct that the</font>
<br><font face="Arial">> > StreamMode at the RTP termination does not affect
this event</font>
<br><font face="Arial">> > detection?</font>
<br><font face="Arial">> ></font>
<br><font face="Arial">> > Another question. Can the MediaDescriptor (StreamMode)
be set as an</font>
<br><font face="Arial">> > embedded event such that the stream mode gets
changed when a specified</font>
<br><font face="Arial">> > event occurs? Only noticed Signal Descriptor
and Event</font>
<br><font face="Arial">> > Descriptor in the</font>
<br><font face="Arial">> > spec.</font>
<br><font face="Arial">> ></font>
<br><font face="Arial">> > An eary response will be much appreciated.</font>
<br><font face="Arial">> ></font>
<p><font face="Arial">--</font>
<br><font face="Arial">Flemming Andreasen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Phone: +1 732 452 1667</font>
<br><font face="Arial">Cisco Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax:&nbsp;&nbsp; +1 240 359 5839</font></ul>
<font face="Courier New"><font size=-1>--</font></font>
<br><font face="Courier New"><font size=-1>&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Internet: Chuong.Nguyen@usa.alcatel.com</font></font>
<br><font face="Courier New"><font size=-1>&nbsp; 1000 Coit Road Plano,
Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613</font></font>
<br><font face="Courier New"><font size=-1>&nbsp; **** The opinions expressed
are not those of Alcatel USA, Inc ****</font></font></ul>
</blockquote>

<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------93D6E760690CFDC6A18E2BFC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 16:35:28 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24064
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 16:35:27 -0400 (EDT)
Received: from standards (47.234.32.16:1822) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78E21@standards.nortelnetworks.com>; Tue, 27 Jun 2000 16:25:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2105 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 16:25:35 -0400
Received: from qhars002.nortel.com (47.101.112.102:40363) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB78E20@standards.nortelnetworks.com>; Tue, 27 Jun 2000
          16:25:34 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Tue, 27 Jun 2000 21:33:42 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Tue, 27 Jun 2000 15:50:28 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <NQCATR2Z>; Tue, 27 Jun 2000 15:49:56 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480B21@zcard00g.ca.nortel.com>
Date:         Tue, 27 Jun 2000 15:49:50 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Tonegen Package
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Tuesday, June 27, 2000 10:24 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Tonegen Package
>
> Tom-PT Taylor wrote:
>
>               Can someone show a real world scenario and syntax on how
> tonegen package is used?
>
> <cnn> Sorry I meant an example of tonegen and cg being used together.
>             I think your example 2 could have been done w/o using tonegen.
>
        [PTT]
        I can't think of a realistic example using the specific tones in cg.
Assuming that some new package provides "stutter dial tone" (toneId sdt)
which indicates a waiting message, then one could imagine a Signals
descriptor like
                  Signals { tonegen/pt {tl = { sdt, dt}, ind = 10} }
        The assumption is that the durations of the respective tones are
provisioned.

        Again, I don't see this as realistic -- a signal list would work
better.
>
>
>
>       [PTT]
>       Two cases:
>
>               Case 1: DTMF outpulsing of the digits "5551212" (e.g. on a
> PBX trunk), with 10 ms gaps between the individual tones.
>
>                  Signals { tonegen/pt {tl = {d5, d5, d5, d1, d2, d1, d2},
> ind=10} }
>
>               Case 2: Play ringing tone for a maximum of 3 minutes.
> Notify the MGC if the tone terminates abnormally or by timeout.  (No
> notification is needed if the tone is interrupted by an event or
> replacement.)  If any signals remain active when the signal completion
> event is recognized, allow them to continue.
>
>                  Signals { tonegen/pt {tl = {rg}, ind=0, sy=to, nc= {to,
> or} },
>          Events = 666 { g/sc{ka} }
>
> <cnn>  Maybe it is just me but this look pretty challenging and time
> consuming to parse.
>              How would one knows that tl, ind, sy, nc and ka represent
> package parameter name
>              versus Megaco token name?
        [PTT]
        Per the syntax for signals, your parser should be primed to look for
sy, nc, ka, and one or two others, because these are defined in Annex B.
Anything else is package dependent.  It's exactly as you say, but you may be
able to stick all the toneIDs into a single working database, since the
package they come from is irrelevant so long as the other party also
supports that package.

>              One would have to make sure that it is not a Megaco token
> name first.
>              Then search through all package databases that extend tonegen
> package.
>
>
>              tonegen package: signal type = Brief and duration =
> Provisioned.
>              cg package          : signal type = Timeout and duration =
> Provisioned
>
>              Does cg package (cg) override tonegen signal type, etc?
>              So in general does extension package overide package that it
> extends?
        [PTT]
        Leaving aside the thought that defining cg as an extension of
tonegen may have been wasted effort, we have two possibilities: you are
using signal tonegen/pt, or you are using a signal in the cg package.  These
are different signals, and may therefore be of different types.  If you are
using tonegen/pt with a toneID from cg, then the fact that cg supports TO
signals is irrelevant.

>              Is there any restriction that "tl" can only contain tone from
> one package or multiple
>              packages as long as these packages extend tonegen?
        [PTT]
        Not so long as we ensure that toneIDs are unique across all
packages.
>
>              Do you know where I can find all the packages defined so far.
>
>              One would have to build some kind of tree to keep track of
> these package extension.
>              It would be a nightmare if one is looking at binary values of
> these package
>              parameter Ids in hex.
        [PTT]
        I published a list a little while back, but can't find the message
at the moment.  It's about time I set up the IANA tabulations.

> Thanks
> Chuong
>
>
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 16:53:42 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24463
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 16:53:41 -0400 (EDT)
Received: from standards (47.234.32.16:3247) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78E3A@standards.nortelnetworks.com>; Tue, 27 Jun 2000 16:43:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2139 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 16:43:42 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB78E39@standards.nortelnetworks.com>; Tue, 27 Jun 2000 16:43:42
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id QAA10734; Tue, 27 Jun 2000 16:53:07 -0400 (EDT)
Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com
          [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id QAA23372; Tue, 27 Jun 2000 16:53:07 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <NJWYSZWZ>; Tue, 27 Jun 2000 16:53:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CFC99AEA@whq-msgusr-02.fore.com>
Date:         Tue, 27 Jun 2000 16:53:01 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: One-to-one correspondance between text and binary for remote/
              loca l descriptor
X-To:         Naren Tulpule <naren@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Right at the moment, there is not an attempt to force a one-to-one
between Annex C and SDP.  The ATM stuff is designed to at least
have the SDP have all of the ATM stuff in Annex C.

Some day, we will have to do some more rationalization.  Perhaps we
will use the ideas of defining packages that specify the dialect of
SDP, and the corresponding Annex C properties.

Brian

> -----Original Message-----
> From: Naren Tulpule [mailto:naren@TRILLIUM.COM]
> Sent: Friday, June 23, 2000 2:49 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: One-to-one correspondance between text and binary for
> remote/loca l descriptor
>
>
> Hi list,
>   I'd like to know if eventually (when ATM SDP is defined
> etc) there SHALL
> be a one-to-one correspondance between (a revised) annex C and SDP. It
> largely exists now in Megaco/H.248 for annex A and annex B.
> (As a sidebar,
> as someone from Hughes pointed out; we COULD have had things
> better - to
> enforce the at-most-once restriction in syntax itself. e.g.
>
> Megaco ABNF:
> contextAudit = contextAuditToken LBRKT contextAuditProperties *(COMMA
> contextAuditProperties) RBRKT
> ; at-most-once
> contextAuditProperties = (TopologyToken / EmergencyToken /
> PriorityToken)
>
> This could have been, for example:
> contextAudit =  contextAuditToken LBRKT [TopologyToken]
> [EmergencyToken]
> [PriorityToken] RBRKT
>
> The "price" we would have paid would be to have a fixed order
> among the
> three choices. )
>
> Still, is the same thing true for annex C properties? I.e.
> will sub-fields
> within attributes which have to be all present (or "-")
> together in SDP will
> be grouped in a sub-sequence in binary encoding? E.g. for ATM traffic
> descriptor?
>
>
>
> -- Naren.
> Narendra C. Tulpule
> SMTS, Trillium Digital Systems Inc
> 12100 Wilshire Bl #1800 LA CA 90025
> Ph:  +1-310-442-9222
> Fax: +1-310-442-1162
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 17:06:38 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24777
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 17:06:38 -0400 (EDT)
Received: from standards (47.234.32.16:3247) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78E57@standards.nortelnetworks.com>; Tue, 27 Jun 2000 16:56:41 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2178 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 16:56:41 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB78E56@standards.nortelnetworks.com>; Tue, 27 Jun 2000 16:56:41
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id RAA11834; Tue, 27 Jun 2000 17:06:06 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com
          [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id RAA25603; Tue, 27 Jun 2000 17:06:07 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <NVY82Q3Y>; Tue, 27 Jun 2000 17:06:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6784D9@whq-msgusr-02.fore.com>
Date:         Tue, 27 Jun 2000 17:06:07 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: ServiceChangeAddress ASN.1 vs ABNF
X-To:         Mukesh Goel <mukesh@trillium.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Anything we can do to clear up inconsistencies is good.
In this case, I think the intent is quite clear, and we
don't expect anyone to have any difficulties specifying
or interpreting a ServiceChangeAddress.

The address has to make sense in the domain of the transport
mechanism. I'm not too fond of overspecifying this kind of
thing, because it requires changes when you allow additional
transports.

Brian

> -----Original Message-----
> From: Mukesh Goel [mailto:mukesh@trillium.com]
> Sent: Tuesday, June 27, 2000 1:19 PM
> To: Rosen, Brian
> Subject: FW: ServiceChangeAddress ASN.1 vs ABNF
>
>
> Hi Brian,
>
> Sorry for sending direct mail to you again.
>
> We are going ahead with interop, but I think
> there are still issues with syntax.  Like the one I
> pointed out in the mail included below.
>
> How is ServiceChangeAddress to be interpreted.  In ASN.1
> it is clearly defined, but in ABNF it is TOKEN. How is
> this token supposed to be interpreted.
>
> We need to fix issues like these for having a successful
> interop.
>
> Regards,
> Mukesh.
>
> -----Original Message-----
> From: Mukesh Goel [mailto:mukesh@trillium.com]
> Sent: Monday, June 26, 2000 10:56 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: ServiceChangeAddress ASN.1 vs ABNF
>
>
> Hi,
>
> Please see the descripency in definition of ServiceChangeAddress in
> ASN.1 and ABNF.
>
> Please see the excerpt from the document.
>
> A.2 ASN.1 Syntax Specification
> ------------------------------
> ServiceChangeAddress ::= CHOICE
> {
> portNumber INTEGER(0..65535), -- TCP/UDP port number
> ip4Address IP4Address,
> ip6Address IP6Address,
> domainName DomainName,
> deviceName PathName,
> mtpAddress OCTET STRING(SIZE(2)),
> ...
> }
>
> B.2 ABNF Specification
> ----------------------
> serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE
> VALUE = quotedString / 1*(SafeChar)
>
>
>
> Proposed ABNF Syntax
> --------------------
> serviceChangeAddress = portNumber /
>                        (( domainAddress / domainName )[":"
> portNumber]) /
>                        mtpAddress / deviceName
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 17:27:40 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25154
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 17:27:40 -0400 (EDT)
Received: from standards (47.234.32.16:3247) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78E88@standards.nortelnetworks.com>; Tue, 27 Jun 2000 17:17:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2244 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 17:17:38 -0400
Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB78E87@standards.nortelnetworks.com>; Tue, 27 Jun 2000
          17:17:38 -0400
Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA01070
          for <MEGACO@standards.nortelnetworks.com>; Tue, 27 Jun 2000 17:27:05
          -0400 (EDT)
Received: from ihgp2.ih.lucent.com (h135-1-53-26.lucent.com [135.1.53.26]) by
          hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA01066
          for <MEGACO@standards.nortelnetworks.com>; Tue, 27 Jun 2000 17:27:05
          -0400 (EDT)
Received: by ihgp2.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA05461; Tue, 27
          Jun 2000 16:27:03 -0500 (CDT)
Received: from il0015varney2.lucent.com by ihgp2.ih.lucent.com
          (8.8.8+Sun/EMS-1.5 sol2) id QAA05346; Tue, 27 Jun 2000 16:26:53 -0500
          (CDT)
X-Sender: varney@ihgp2.ih.lucent.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <4.3.1.2.20000627151506.00af4a90@ihgp2.ih.lucent.com>
Date:         Tue, 27 Jun 2000 16:26:48 -0500
Reply-To: Al Varney <varney@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Al Varney <varney@LUCENT.COM>
Subject:      Re: Event Detection
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <28560036253BD41191A10000F8BCBD11480B1A@zcard00g.ca.nortel. com>

At 13:50 06/27/2000 -0500, Tom-PT Taylor wrote:
>I think you've got the ends of the conversation confused.  Off-hook happens
>in the terminating MG, while ringback happens in the originating MG.  The
>originating MG has no in-band way of detecting that the called party has
>answered.  Instead, the terminating MG tells the terminating MGC, which
>signals the originating MGC, which in turn modifies the terminations
>associated with the call in the originating MG.  Agreed that speech clipping
>could occur, but this is a normal hazard of VoIP operation.

    In the original models of H.323, SIP and other "VoIP" applications, the Audible Ringing tone (also called "ringback") is provided by the originating MG under control of an originating MGC.  That MGC has to trust that the terminating MGC/MG can reliably indicate when Alerting (power ringing) has begun, and can quickly signal when Answer (off-hook) occurs.  Even so, with MGC-to-MGC (or MGC-to-MG) delays, speech clipping is not unlikely.

    These models also suffer from another problem -- if the terminating MG connects to a PSTN exchange interface (MF or SS7 trunk), the PSTN assumes the MG (after signaling) is providing an audio path back to the originating user.  This allows the PSTN to begin Audible Ringing at about the same time as Alerting to the far-end user.  More importantly, it allows the PSTN to provide ANNOUNCEMENTS to the originating user without Answer being signalled ("the number you have reached is not in service").  The elimination of speech clipping after answer is an intentional added benefit of this arrangement.  Even SS7, which signals Answer quickly back to the originating exchange, assumes the terminating exchange provides Audible Ringing tone.

    While it might be reasonable to declare a single MGC (controlling both originating MG and terminating MG) equivalent to a single exchange (and thus the originating MG could provide the Audible Ring), this cannot reasonably be extended to a multiple MGC environment.  That's why potential MGC-to-MGC protocols (H.323, SIP, BICC) have all been enhanced to allow Audible Ring and Announcements to be provided by the terminating MGC/MG.  That's in Version 2 of H.323, SIPs "183 Session Progress" message and the CS-1 version of BICC.

    I would assume you are not indicating Megaco/H.248 is only suitable for supporting the "old" VoIP protocols?  Or that Audible Ringing and Alerting cannot be provided by the same MG?  Also, there are other instances where signals/events on one MG termination must be quickly coordinated with another.  If H.248 cannot be made to do so (perhaps via new packages), then we do have a problem....

Al Varney   varney@lucent.com


> > -----Original Message-----
> > From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> > Sent: Tuesday, June 27, 2000 2:30 PM
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Re: Event Detection
> >
> > Well Tom can something be done now?
> >
> > It is a very important feature which can prevent speech clipping.
> > If the off-hook detected by the endpoint (TDM termination) has to result
> > in MG sending a notify to MGC.
> > Upon which MGC has to send a Modify to connection (RTP termination) to
> > stop ringback.
> > If there is any network delay, speech clipping could be pronounced.
> >
> > I thought one of the goal of Megaco is to at a minimun maintain the same
> > capability as MGCP.
> >
> > I guess the MG can always buffer the speech until the RTP ringing is
> > stopped.
> > Or just send the speech w/the ringing until ringing is stopped by MGC.
> > Or somehow has the MG detected speech ("signal"?) and stop ringing - a new
> > package?
> >
> >
> > Thanks
> > Chuong
> >
> > Flemming Andreasen wrote:
> >
> >       "Rosen, Brian" wrote:
> >
> >       > Hmm, did you just see the message from Chuong Nguyen or
> >       > is there a warp in the space/time fabric of the universe?
> >       >
> >       > The reply is the same - events are scoped to a termination,
> >       > not a context.  Off hook is not detectable on the RTP.
> >       > It occurs to me to wonder if this is the same as MGCP.
> >
> >       It is. In MGCP, if you want to detect an event on the endpoint you
> > use the
> >       normal event detection syntax, i.e. simply include the event in the
> > list of
> >       RequestedEvents for the endpoint. If you want to detect the event on
> > the
> >       connection, you use the "event@connection" syntax instead however
> > not all
> >       events can be detected on a connection (and vice versa actually).
> > The
> >       off-hook event (as defined right now) cannot be detected on a
> > connection.
> >
> >       One note related to Chuong's message. MGCP's single endpoint model
> >       inherently contains the synchronization you are looking for to turn
> > off
> >       ringback on a connection when detecting off-hook on the endpoint. To
> > achieve
> >       something similar in Megaco's dual endpoint model, you either need
> > some form
> >       of script as Brian suggested, or an event/signal construct similar
> > to MGCP's
> >       "@connection", e.g. "@termination". You could for example achieve
> > the latter
> >       by simply defining such a signal and define the semantics
> > accordingly - the
> >       worst that can happen is that the protocol police will come looking
> > for you.
> >
> >       -- Flemming
> >
> >       >
> >       > We intended it to be.  You can set an event using a
> >       > wildcard, as with MGCP, but I think that detection is
> >       > on an endpoint, not a connection, and you can't stop
> >       > the ringback signal on the RTP with the off hook event
> >       > on the analog line.
> >       >
> >       > Stream mode does not affect events.
> >       >
> >       > You can't have a Media Descriptor in an embedded event.
> >       >
> >       > Brian
> >       >
> >       > > -----Original Message-----
> >       > > From: Mario Monteiro [ <mailto:mmonteir@USA.ALCATEL.COM>]
> >       > > Sent: Friday, June 23, 2000 10:29 AM
> >       > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> >       > > Subject: Event Detection
> >       > >
> >       > >
> >       > > If there are two termination ids within a context, an SCN and an
> > RTP
> >       > > termination, will an event which occurs on the SCN termination
> > also be
> >       > > "seen" at the RTP termination?
> >       > >
> >       > > The specific case I am refering to is a terminating circuit
> > where an
> >       > > off-hook (answer) detected on the SCN is also seen at the RTP.
> > The RTP
> >       > > termination is connected via a IP network path to the
> >       > > originating side.
> >       > > Would like this event detection to trigger removal of the
> >       > > signal applied
> >       > > at the RTP (KeepActive off and off-hook event detection at RTP
> > armed)
> >       > > when the off-hook occurs. Also is my understanding correct that
> > the
> >       > > StreamMode at the RTP termination does not affect this event
> >       > > detection?
> >       > >
> >       > > Another question. Can the MediaDescriptor (StreamMode) be set as
> > an
> >       > > embedded event such that the stream mode gets changed when a
> > specified
> >       > > event occurs? Only noticed Signal Descriptor and Event
> >       > > Descriptor in the
> >       > > spec.
> >       > >
> >       > > An eary response will be much appreciated.
> >       > >
> >
> >       --
> >       Flemming Andreasen                Phone: +1 732 452 1667
> >       Cisco Systems                     Fax:   +1 240 359 5839
> >
> > --
> >   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
> >   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
> >

Al Varney - Lucent Technologies  +1 630 224-7493    varney@lucent.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jun 27 23:50:06 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02116
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 27 Jun 2000 23:50:05 -0400 (EDT)
Received: from standards (47.234.32.16:2626) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78F4F@standards.nortelnetworks.com>; Tue, 27 Jun 2000 23:40:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2514 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 23:40:01 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB78F4E@standards.nortelnetworks.com>; Tue, 27 Jun 2000 23:40:01
          -0400
Received: from chsharp-tecra.cisco.com (rtp-dial-1-67.cisco.com [10.83.97.67])
          by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id UAA21489; Tue, 27
          Jun 2000 20:49:26 -0700 (PDT)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.3.1.2.20000627234445.00b0ca90@dogwood.cisco.com>
Date:         Tue, 27 Jun 2000 23:48:54 -0400
Reply-To: Chip Sharp <chsharp@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chip Sharp <chsharp@CISCO.COM>
Subject:      Re: The difference between MGCP & MEGACO
X-To:         =?EUC-KR?B?wPzH/MHY?= <hjjun@freechal.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <1519.962113882781.JavaMail.Administrator@smtp01>

At 10:51 PM 6/27/00 +0900, =?EUC-KR?B?wPzH/MHY?= wrote:

>I'm preparing to implement MGC and MG which supports MGCP, because, as I know,
>
>MEGACO is not yet fixed as an standard.

ITU approved Recommendation H.248 a couple of weeks ago.  This is
effectively the same as the Megaco protocol.

Two drafts:
draft-ietf-megaco-protocol-08.txt
draft-ietf-megaco-errata-03.txt

have been approved for publishing as standards-track RFCs and are on the
RFC editor's queue.  They will have Proposed Standard status in IETF (not
Standard yet).

Chip



>But we still want to design the MGCP supporting MGC and MG easily migrate
>to support MEGACO.
>
>
>
>So I investigated the differences, cons & pros between those two protocols.
>
>I found that MGCP only defines text encoding, but MEGACO guides to MGC
>support text and binary
>
>encoding. The gateway control commands look similar(Only a few differences
>in their names and
>
>syntax). MEGACO supports TCP (I think it's for binary encoding.).
>
>
>
>Is there anybody who can explain the other differences between MGCP and
>MEGACO?
>
>And could you advise me how to design MGCP MGC and MG to easily move to
>MEGACO supporting systems?
>
>
>
>Thanks in advance!


-------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Change it.
http://www.netaid.org
-------------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 28 09:37:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22761
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 28 Jun 2000 09:37:22 -0400 (EDT)
Received: from standards (47.234.32.16:3067) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7913A@standards.nortelnetworks.com>; Wed, 28 Jun 2000 9:27:18 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3158 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 28 Jun 2000 09:27:18 -0400
Received: from ficon-tech.com (12.10.198.190:4536) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB79139@standards.nortelnetworks.com>; Wed, 28 Jun 2000
          9:27:16 -0400
Received: from hemantag (vacant4.india.ficon-tech.com [172.25.1.131]) by
          ficon-tech.com (8.9.3/8.9.3) with SMTP id TAA77762 for
          <megaco@standards.nortelnetworks.com>; Wed, 28 Jun 2000 19:05:54
          +0530 (IST) (envelope-from hemantag@globespan.net)
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 5.00.2615.200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <020501bfe105$d5dbc860$830119ac@india.ficontech.com>
Date:         Wed, 28 Jun 2000 19:06:11 +0530
Reply-To: Hemant Agrawal <hemantag@GLOBESPAN.NET>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hemant Agrawal <hemantag@GLOBESPAN.NET>
Organization: GlobeSpan.net
Subject:      topology descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,
I have a couple of questions regarding the processing of context
properties.

 1. When do we proces the topology descriptor in a Action Request ?
    (a) Before processing any command in that action request or
    (b) After processing all the commands in the action request.

If it is in the end,  then what should the audit of context properties
return?
(a) the context properties  after applying the topology descriptor or
(b) previous context properties?


 2. How do we return a failure in applying  the topology descriptor ?
If a topology descriptor fails, then should the
further processing of commands in the action request be stopped?

Thanks & regards,
Hemant Agrawal

________________________________________
Hemant Agrawal
GlobeSpan Inc
Tel: +91 575 4544028  ext 121
E-mail:hemantag@globespan.net
Web: http://www.globespan.net


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 28 13:00:40 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27881
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 28 Jun 2000 13:00:40 -0400 (EDT)
Received: from standards (47.234.32.16:3657) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB792A1@standards.nortelnetworks.com>; Wed, 28 Jun 2000 12:50:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3627 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 28 Jun 2000 12:50:31 -0400
Received: from mars.hss.co.in (202.54.26.197:60212) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB792A0@standards.nortelnetworks.com>; Wed, 28 Jun 2000
          12:50:29 -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          mars.hss.co.in (8.10.0/8.10.0) with SMTP id e5SH1Uv04255 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 28 Jun 2000 22:31:32
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525690C.005C9767 ; Wed, 28 Jun 2000 22:21:20 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525690C.005C966F.00@sandesh.hss.hns.com>
Date:         Wed, 28 Jun 2000 22:25:53 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      signal descriptor returned in response.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

(Reposting)
Hi all,

When signal Descriptor is specified in Audit descriptor,
what is the response expected from MG?
 The Signal descriptor earlier sent by MGC?  OR
The list of signals that are presently active on the termination?
-Madhu Babu
Hughes Software Systems.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jun 28 14:39:30 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01147
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 28 Jun 2000 14:39:29 -0400 (EDT)
Received: from standards (47.234.32.16:3657) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7934C@standards.nortelnetworks.com>; Wed, 28 Jun 2000 14:29:19 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3851 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 28 Jun 2000 14:29:18 -0400
Received: from mars.hss.co.in (202.54.26.197:60485) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7934B@standards.nortelnetworks.com>; Wed, 28 Jun 2000
          14:29:16 -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          mars.hss.co.in (8.10.0/8.10.0) with SMTP id e5SIeHv04996 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 29 Jun 2000 00:10:18
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525690C.0065A381 ; Thu, 29 Jun 2000 00:00:09 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525690C.0065A23D.00@sandesh.hss.hns.com>
Date:         Thu, 29 Jun 2000 00:04:42 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Embedded signal application failure.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

HI all,
At MG, when event detection triggers embedded signal descriptor processing,
how errors are informed to MGC, if this embedded signal application fails.

is the optional parameter "NotifyCompletion" mandatory for each signal
in the embedded signal descriptor?

-Madhubabu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 29 01:41:23 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16026
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 29 Jun 2000 01:41:23 -0400 (EDT)
Received: from standards (47.234.32.16:2678) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7951B@standards.nortelnetworks.com>; Thu, 29 Jun 2000 1:31:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4476 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 01:31:24 -0400
Received: from mars.hss.co.in (202.54.26.197:63219) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB7951A@standards.nortelnetworks.com>; Thu, 29 Jun 2000
          1:31:23 -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          mars.hss.co.in (8.10.0/8.10.0) with SMTP id e5T5gQv10346 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 29 Jun 2000 11:12:27
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525690D.001E6490 ; Thu, 29 Jun 2000 11:01:58 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525690D.001E62C3.00@sandesh.hss.hns.com>
Date:         Thu, 29 Jun 2000 11:05:30 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Packages extension queries.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

There are two packages A and B. Package B extends A,
Say, properties a1 and a2 are in package A and x1 in package B.
1) If a termination realizes package B, does it mean that it also realizes
package A?
2) Can property of package A be addressed as B/a1? If 1) is true, is it that
only A/a1 is
     possible?
------------------------------------------------------------------------------------------------------------------------
Lets there be third package C, which also extends A. and it also defines a
property x1
3) Can a termination realize packages B and C ?
------------------------------------------------------------------------------------------------------------------
Lets there be a third package C, which also extends A. and it also defines a
property c1
A termination realizes both package B and C.
4) what will be value of A/a1 which is referred by both B/a1 and C/a1.
If B/a1 value is changed is it that the value of C/a1 is also changed?

-Madhubabu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 29 15:37:54 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18579
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 29 Jun 2000 15:37:54 -0400 (EDT)
Received: from standards (47.234.32.16:3933) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79919@standards.nortelnetworks.com>; Thu, 29 Jun 2000 15:27:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0307 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 15:27:48 -0400
Received: from qhars002.nortel.com (47.101.112.102:38084) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB79918@standards.nortelnetworks.com>; Thu, 29 Jun 2000
          15:27:47 -0400
Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n) by
          qhars002.nortel.com; Thu, 29 Jun 2000 20:35:20 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg15e1.nortelnetworks.com; Thu, 29 Jun 2000 15:34:57 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <NQCAVJ7H>; Thu, 29 Jun 2000 15:34:56 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480B29@zcard00g.ca.nortel.com>
Date:         Thu, 29 Jun 2000 15:34:49 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: signal descriptor returned in response.
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The text doesn't say.  If everyone agrees, the returned value should be the
signals still active.  When it comes to a signal list, the same principle
could apply: the signals already completed are not returned, but the
remainder of the list is shown.

> -----Original Message-----
> From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> Sent: Wednesday, June 28, 2000 12:56 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      signal descriptor returned in response.
>
> (Reposting)
> Hi all,
>
> When signal Descriptor is specified in Audit descriptor,
> what is the response expected from MG?
>  The Signal descriptor earlier sent by MGC?  OR
> The list of signals that are presently active on the termination?
> -Madhu Babu
> Hughes Software Systems.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 29 17:57:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21001
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 29 Jun 2000 17:57:59 -0400 (EDT)
Received: from standards (47.234.32.16:3155) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79A22@standards.nortelnetworks.com>; Thu, 29 Jun 2000 17:47:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0648 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 17:47:57 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB79A21@standards.nortelnetworks.com>; Thu, 29 Jun 2000 17:47:57
          -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id RAA07774; Thu, 29 Jun 2000 17:57:29 -0400 (EDT)
Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com
          [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id RAA13124; Thu, 29 Jun 2000 17:57:30 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <NJWYT1TA>; Thu, 29 Jun 2000 17:57:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CFC99C00@whq-msgusr-02.fore.com>
Date:         Thu, 29 Jun 2000 17:57:24 -0400
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: signal descriptor returned in response.
X-To:         bmbabu@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I thought I had sent an answer to this,

I believe you get "live" information, which would be
the signals playing at the time, not was last sent.
If there were no signals, you get an empty descriptor.

For a signal list, I think it's not specified whether
you get only those active, or yet to be played items,
or whether you get the original list. I'd like to see
what is current and yet to go, but that may be hard to
implement.

Brian

> -----Original Message-----
> From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM]
> Sent: Wednesday, June 28, 2000 12:56 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: signal descriptor returned in response.
>
>
> (Reposting)
> Hi all,
>
> When signal Descriptor is specified in Audit descriptor,
> what is the response expected from MG?
>  The Signal descriptor earlier sent by MGC?  OR
> The list of signals that are presently active on the termination?
> -Madhu Babu
> Hughes Software Systems.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 29 18:21:31 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21372
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 29 Jun 2000 18:21:30 -0400 (EDT)
Received: from standards (47.234.32.16:3155) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79A52@standards.nortelnetworks.com>; Thu, 29 Jun 2000 18:11:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0707 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 18:11:30 -0400
Received: from qhars002.nortel.com (47.101.112.102:42298) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB79A4C@standards.nortelnetworks.com>; Thu, 29 Jun 2000
          18:01:30 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Thu, 29 Jun 2000 23:10:49 +0100
Received: from zcard015.ca.nortel.com (actually zcard015) by
          ertpg14e1.nortelnetworks.com; Thu, 29 Jun 2000 18:10:19 -0400
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id NQD29JP1; Thu, 29 Jun 2000 18:10:20
          -0400
Received: from americasm10.nt.com (pnc1m006.us.nortel.com [47.142.208.218]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id M38DW0Q1; Thu, 29 Jun 2000 18:10:19
          -0400
X-Sybari-Space: 00000000 00000000 00000000
X-Sender: "Brown, Michael [NC1:3T19:EXCH]" <mahubard@zrtpd00z>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480B2B@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------4209E01608AE1E98707902CB"
Message-ID:  <395BCA81.4830907@americasm10.nt.com>
Date:         Thu, 29 Jun 2000 18:15:29 -0400
Reply-To: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: Packages extension queries.
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
X-cc:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>,
              Christian Groves <Christian.Groves@ericsson.com>,
              John Segers <jsegers@LUCENT.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------4209E01608AE1E98707902CB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Comments inline.

Michael

"Taylor, Tom-PT [NORSE:B901:EXCH]" wrote:

>
>
>      -----Original Message-----
>      From:   Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
>      Sent:   Thursday, June 29, 2000 1:36 AM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Packages extension queries.
>
>      There are two packages A and B. Package B extends A,
>      Say, properties a1 and a2 are in package A and x1 in package B.
>      1) If a termination realizes package B, does it mean that it also
>      realizes
>      package A?
>      [PTT]
>      Yes.
>
>      2) Can property of package A be addressed as B/a1? If 1) is true,
>      is it that
>      only A/a1 is possible?
>      [PTT]
>      This was discussed in Red Bank when we finalized our package
>      schema, but I can't remember the conclusion.  Christian, John, or
>      Michael, do you remember?
>

I remember that the answer (consensus) was that the preferable way to
refer to a1 is as B/a1. One could use A/a1, because there really is only
one property defined where both names refer to it.


>
>
>      -
>      ----------------------------------------------------------------------------------------------------------------------
>
>      Lets there be third package C, which also extends A. and it also
>      defines a
>      property x1
>      3) Can a termination realize packages B and C ?
>

Well, I would say that the answer is yes that a termination COULD
realize both, but my feeling is that this situation would be due to a
poor definition of  the packages hierarchy. Given your hypothetical
description rather than a real example where this would appear to be a
desirable approach, I would think that C should extend B rather than A.

>
>      -
>      ----------------------------------------------------------------------------------------------------------------
>
>      Lets there be a third package C, which also extends A. and it
>      also defines a
>      property c1
>      A termination realizes both package B and C.
>      4) what will be value of A/a1 which is referred by both B/a1 and
>      C/a1.
>      If B/a1 value is changed is it that the value of C/a1 is also
>      changed?
>

Based on my previous two responses, C/a1 would be changed, but this
situation is one that to me would indicate that the package hierarchy
has not been properly defined. I don't think this should ever happen.

>
>
>      -Madhubabu
>

--------------4209E01608AE1E98707902CB
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Comments inline.
<p>Michael
<p>"Taylor, Tom-PT [NORSE:B901:EXCH]" wrote:
<blockquote TYPE=CITE>&nbsp;
<ul><font face="Arial"><font size=-2>-----Original Message-----</font></font>
<br><b><font face="Arial"><font size=-2>From:&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]</font></font>
<br><b><font face="Arial"><font size=-2>Sent:&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>Thursday, June 29, 2000 1:36 AM</font></font>
<br><b><font face="Arial"><font size=-2>To:&nbsp;&nbsp;&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>MEGACO@STANDARDS.NORTELNETWORKS.COM</font></font>
<br><b><font face="Arial"><font size=-2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>Packages extension queries.</font></font>
<p><font face="Arial"><font size=-1>There are two packages A and B. Package
B extends A,</font></font>
<br><font face="Arial"><font size=-1>Say, properties a1 and a2 are in package
A and x1 in package B.</font></font>
<br><font face="Arial"><font size=-1>1) If a termination realizes package
B, does it mean that it also realizes</font></font>
<br><font face="Arial"><font size=-1>package A?</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[PTT]</font></font></font></i></b>
<br><font face="Arial"><font color="#0000FF"><font size=-1>Yes.</font></font></font>
<p><font face="Arial"><font size=-1>2) Can property of package A be addressed
as B/a1? If 1) is true, is it that</font></font>
<br><font face="Arial"><font size=-1>only A/a1 is possible?</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[PTT]</font></font></font></i></b>
<br><font face="Arial"><font color="#0000FF"><font size=-1>This was discussed
in Red Bank when we finalized our package schema, but I can't remember
the conclusion.&nbsp; Christian, John, or Michael, do you remember?</font></font></font></ul>
</blockquote>

<p><br>I remember that the answer (consensus) was that the preferable way
to refer to a1 is as B/a1. One could use A/a1, because there really is
only one property defined where both names refer to it.
<br>&nbsp;
<blockquote TYPE=CITE>
<ul><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;
<p><font face="Arial"><font size=-1>------------------------------------------------------------------------------------------------------------------------</font></font>
<p><font face="Arial"><font size=-1>Lets there be third package C, which
also extends A. and it also defines a</font></font>
<br><font face="Arial"><font size=-1>property x1</font></font>
<br><font face="Arial"><font size=-1>3) Can a termination realize packages
B and C ?</font></font></ul>
</blockquote>

<p><br>Well, I would say that the answer is yes that a termination COULD
realize both, but my feeling is that this situation would be due to a poor
definition of&nbsp; the packages hierarchy. Given your hypothetical description
rather than a real example where this would appear to be a desirable approach,
I would think that C should extend B rather than A.
<blockquote TYPE=CITE>
<ul><font face="Arial"><font size=-1></font></font>&nbsp;
<br><font face="Arial"><font size=-1>------------------------------------------------------------------------------------------------------------------</font></font>
<br><font face="Arial"><font size=-1>Lets there be a third package C, which
also extends A. and it also defines a</font></font>
<br><font face="Arial"><font size=-1>property c1</font></font>
<br><font face="Arial"><font size=-1>A termination realizes both package
B and C.</font></font>
<br><font face="Arial"><font size=-1>4) what will be value of A/a1 which
is referred by both B/a1 and C/a1.</font></font>
<br><font face="Arial"><font size=-1>If B/a1 value is changed is it that
the value of C/a1 is also changed?</font></font></ul>
</blockquote>

<p><br>Based on my previous two responses, C/a1 would be changed, but this
situation is one that to me would indicate that the package hierarchy has
not been properly defined. I don't think this should ever happen.
<blockquote TYPE=CITE>
<ul><font face="Arial"><font size=-1></font></font>&nbsp;
<p><font face="Arial"><font size=-1>-Madhubabu</font></font></ul>
</blockquote>
</html>

--------------4209E01608AE1E98707902CB--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 29 22:11:54 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25442
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 29 Jun 2000 22:11:53 -0400 (EDT)
Received: from standards (47.234.32.16:4195) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79AFA@standards.nortelnetworks.com>; Thu, 29 Jun 2000 22:01:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0938 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 22:01:38 -0400
Received: from qhars002.nortel.com (47.101.112.102:47369) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB79AF7@standards.nortelnetworks.com>; Thu, 29 Jun 2000
          22:01:37 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Fri, 30 Jun 2000 03:11:06 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Thu, 29 Jun 2000 14:40:52 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <NQCK3AAX>; Thu, 29 Jun 2000 14:38:26 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480B2A@zcard00g.ca.nortel.com>
Date:         Thu, 29 Jun 2000 14:38:26 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Embedded signal application failure.
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Since the "NotifyCompletion" mechanism works, I think would be the way to
go.  An aslternative approach using Notify with ErrorDescriptor and
requestID=0 is possible, but I don't think we should define a second
alternative.

> -----Original Message-----
> From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> Sent: Wednesday, June 28, 2000 2:35 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Embedded signal application failure.
>
> HI all,
> At MG, when event detection triggers embedded signal descriptor
> processing,
> how errors are informed to MGC, if this embedded signal application fails.
>
> is the optional parameter "NotifyCompletion" mandatory for each signal
> in the embedded signal descriptor?
>
> -Madhubabu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jun 29 22:11:55 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25446
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 29 Jun 2000 22:11:54 -0400 (EDT)
Received: from standards (47.234.32.16:4195) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79AFE@standards.nortelnetworks.com>; Thu, 29 Jun 2000 22:01:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0943 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 22:01:38 -0400
Received: from qhars002.nortel.com (47.101.112.102:47370) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB79AF8@standards.nortelnetworks.com>; Thu, 29 Jun 2000
          22:01:38 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Fri, 30 Jun 2000 03:11:06 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Thu, 29 Jun 2000 14:44:29 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <NQCK3AFM>; Thu, 29 Jun 2000 14:42:46 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480B2B@zcard00g.ca.nortel.com>
Date:         Thu, 29 Jun 2000 14:41:17 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Packages extension queries.
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
X-cc:         Christian Groves <Christian.Groves@ericsson.com>,
              John Segers <jsegers@LUCENT.COM>,
              Michael Brown <C.Michael.Brown@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> -----Original Message-----
> From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> Sent: Thursday, June 29, 2000 1:36 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Packages extension queries.
>
> There are two packages A and B. Package B extends A,
> Say, properties a1 and a2 are in package A and x1 in package B.
> 1) If a termination realizes package B, does it mean that it also realizes
> package A?
        [PTT]
        Yes.

> 2) Can property of package A be addressed as B/a1? If 1) is true, is it
> that
> only A/a1 is possible?
        [PTT]
        This was discussed in Red Bank when we finalized our package schema,
but I can't remember the conclusion.  Christian, John, or Michael, do you
remember?
> --------------------------------------------------------------------------
> ----------------------------------------------
> Lets there be third package C, which also extends A. and it also defines a
> property x1
> 3) Can a termination realize packages B and C ?
> --------------------------------------------------------------------------
> ----------------------------------------
> Lets there be a third package C, which also extends A. and it also defines
> a
> property c1
> A termination realizes both package B and C.
> 4) what will be value of A/a1 which is referred by both B/a1 and C/a1.
> If B/a1 value is changed is it that the value of C/a1 is also changed?
>
> -Madhubabu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 30 03:20:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11208
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 30 Jun 2000 03:20:59 -0400 (EDT)
Received: from standards (47.234.32.16:1107) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79BAA@standards.nortelnetworks.com>; Fri, 30 Jun 2000 3:10:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1172 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 03:10:45 -0400
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se)
          by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with
          SMTP id <0.FFB79BA5@standards.nortelnetworks.com>; Fri, 30 Jun 2000
          3:00:45 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP
          id e5U7AFs13525; Fri, 30 Jun 2000 09:10:16 +0200 (MET DST)
Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by
          al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id
          JAA21326; Fri, 30 Jun 2000 09:10:15 +0200 (MET DST)
Received: from ericsson.com (mc2dh148.epa.ericsson.se [146.11.87.148]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          JAA16295; Fri, 30 Jun 2000 09:10:12 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480B2B@zcard00g.ca.nortel.com>
            <395BCA81.4830907@americasm10.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <395C47CF.D1C0F9AE@ericsson.com>
Date:         Fri, 30 Jun 2000 17:10:07 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Packages extension queries.
X-To:         Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Michael and Tom,

Please see my comments below marked CHG.

Cheers, Christian

Michael Brown wrote:
>
> Comments inline.
>
> Michael
>
> "Taylor, Tom-PT [NORSE:B901:EXCH]" wrote:
>
> >
> >
> >      -----Original Message-----
> >      From:   Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> >      Sent:   Thursday, June 29, 2000 1:36 AM
> >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      Subject:        Packages extension queries.
> >
> >      There are two packages A and B. Package B extends A,
> >      Say, properties a1 and a2 are in package A and x1 in package B.
> >
> >      1) If a termination realizes package B, does it mean that it
> >      also realizes
> >      package A?
> >      [PTT]
> >      Yes.
> >
> >      2) Can property of package A be addressed as B/a1? If 1) is
> >      true, is it that
> >      only A/a1 is possible?
> >      [PTT]
> >      This was discussed in Red Bank when we finalized our package
> >      schema, but I can't remember the conclusion.  Christian, John,
> >      or Michael, do you remember?
> >
>
> I remember that the answer (consensus) was that the preferable way to
> refer to a1 is as B/a1. One could use A/a1, because there really is
> only one property defined where both names refer to it.

[CHG] That's what I understand.

>
> >
> >      Lets there be third package C, which also extends A. and it
> >      also defines a
> >      property x1
> >      3) Can a termination realize packages B and C ?
> >
>
> Well, I would say that the answer is yes that a termination COULD
> realize both, but my feeling is that this situation would be due to a
> poor definition of  the packages hierarchy. Given your hypothetical
> description rather than a real example where this would appear to be a
> desirable approach, I would think that C should extend B rather than
> A.

[CHG] I'm not sure of the question or the response but to me even if two
packages B & C extend A with a property x1 then the two instances of x1
are uniquely identified by the package name B&C. The two instances of x1
could be completely different functions but (unfortunately) have the
same name.

>
> >
> >      -
> >      ----------------------------------------------------------------------------------------------------------------
> >
> >      Lets there be a third package C, which also extends A. and it
> >      also defines a
> >      property c1
> >      A termination realizes both package B and C.
> >      4) what will be value of A/a1 which is referred by both B/a1
> >      and C/a1.
> >      If B/a1 value is changed is it that the value of C/a1 is also
> >      changed?
> >
>
> Based on my previous two responses, C/a1 would be changed, but this
> situation is one that to me would indicate that the package hierarchy
> has not been properly defined. I don't think this should ever happen.

[CHG] I think A/al, B/al and C/al will all change because they are the
same property.

>
> >
> >
> >      -Madhubabu
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 30 03:52:27 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11363
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 30 Jun 2000 03:52:27 -0400 (EDT)
Received: from standards (47.234.32.16:1107) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79BE3@standards.nortelnetworks.com>; Fri, 30 Jun 2000 3:42:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1252 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 03:42:25 -0400
Received: from qhars002.nortel.com (47.101.112.102:60689) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB79BE2@standards.nortelnetworks.com>; Fri, 30 Jun 2000
          3:42:25 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Fri, 30 Jun 2000 08:51:44 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Thu, 29 Jun 2000 20:42:03 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <NQCK3GSZ>; Thu, 29 Jun 2000 20:40:19 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480B2F@zcard00g.ca.nortel.com>
Date:         Thu, 29 Jun 2000 20:40:22 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      FW: Embedded signal application failure.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Resend

> -----Original Message-----
> From: Taylor, Tom-PT [NORSE:B901:EXCH]
> Sent: Thursday, June 29, 2000 3:38 PM
> To:   bmbabu@HSS.HNS.COM; megaco
> Subject:      RE: Embedded signal application failure.
>
> Since the "NotifyCompletion" mechanism works, I think would be the way to
> go.  An alternative approach using Notify with ErrorDescriptor and
> requestID=0 is possible, but I don't think we should define a second
> alternative.
>
>       -----Original Message-----
>       From:   Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
>       Sent:   Wednesday, June 28, 2000 2:35 PM
>       To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject:        Embedded signal application failure.
>
>       HI all,
>       At MG, when event detection triggers embedded signal descriptor
> processing,
>       how errors are informed to MGC, if this embedded signal application
> fails.
>
>       is the optional parameter "NotifyCompletion" mandatory for each
> signal
>       in the embedded signal descriptor?
>
>       -Madhubabu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 30 06:23:44 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12251
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 30 Jun 2000 06:23:44 -0400 (EDT)
Received: from standards (47.234.32.16:3036) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79CA5@standards.nortelnetworks.com>; Fri, 30 Jun 2000 6:13:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1470 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 06:13:33 -0400
Received: from ficon-tech.com (12.10.198.190:4297) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB79C83@standards.nortelnetworks.com>; Fri, 30 Jun 2000
          6:03:03 -0400
Received: from hkumar (hkumar.india.ficon-tech.com [172.25.1.130]) by
          ficon-tech.com (8.9.3/8.9.3) with SMTP id PAA67240; Fri, 30 Jun 2000
          15:41:38 +0530 (IST) (envelope-from hkumar@globespan.net)
References:  <4FBEA8857476D311A03300204840E1CFC99C00@whq-msgusr-02.fore.com>
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 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <007601bfe27b$0cde1900$820119ac@india.ficontech.com>
Date:         Fri, 30 Jun 2000 15:37:47 +0530
Reply-To: Hemant Kumar <hkumar@globespan.net>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hemant Kumar <hkumar@globespan.net>
Organization: GlobeSpan, Inc.
Subject:      Signal descriptor returned in response.
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Everyone,
         I think that in response to audit of signal descriptor, the signals
and signal lists in the previous descriptor should be returned. As Brian had
pointed out in his earlier mail (on June 16) the MG might not be in sync
with the MGC. There is always the possiblity of completion of signal (or/and
signal lists) play by the time the message containing the "active" signal
(or/and signal lists)reaches the MGC (especially for brief signals).
Therefore sending active signals (or/and signal lists)only in the audit
response would be of little value (The MGC can never be sure of whether the
signals(or/and signal lists) that have been received are actually playing or
not)

Regards,
Hemant Kumar

----- Original Message -----
From: Rosen, Brian <Brian.Rosen@MARCONI.COM>
To: <MEGACO@standards.nortelnetworks.com>
Sent: Friday, June 30, 2000 3:27 AM
Subject: Re: signal descriptor returned in response.


> I thought I had sent an answer to this,
>
> I believe you get "live" information, which would be
> the signals playing at the time, not was last sent.
> If there were no signals, you get an empty descriptor.
>
> For a signal list, I think it's not specified whether
> you get only those active, or yet to be played items,
> or whether you get the original list. I'd like to see
> what is current and yet to go, but that may be hard to
> implement.
>
> Brian
>
> > -----Original Message-----
> > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM]
> > Sent: Wednesday, June 28, 2000 12:56 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: signal descriptor returned in response.
> >
> >
> > (Reposting)
> > Hi all,
> >
> > When signal Descriptor is specified in Audit descriptor,
> > what is the response expected from MG?
> >  The Signal descriptor earlier sent by MGC?  OR
> > The list of signals that are presently active on the termination?
> > -Madhu Babu
> > Hughes Software Systems.
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 30 07:38:52 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13992
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 30 Jun 2000 07:38:52 -0400 (EDT)
Received: from standards (47.234.32.16:4799) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79CFB@standards.nortelnetworks.com>; Fri, 30 Jun 2000 7:28:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1589 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 07:28:42 -0400
Received: from janus.cypress.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB79CE0@standards.nortelnetworks.com>; Fri, 30 Jun 2000 7:18:41
          -0400
Received: from cobweb.mis.cypress.com (cobweb.mis.cypress.com [172.16.2.5]) by
          janus.cypress.com (8.9.1a/8.9.1) with ESMTP id EAA22117 for
          <megaco@standards.nortelnetworks.com>; Fri, 30 Jun 2000 04:28:13
          -0700 (PDT)
Received: from Simba.India.Cypress.Com (simba.India.Cypress.Com [157.95.25.1])
          by cobweb.mis.cypress.com (8.8.8/8.8.8) with ESMTP id EAA16927 for
          <megaco@standards.nortelnetworks.com>; Fri, 30 Jun 2000 04:28:07
          -0700 (PDT)
Received: from mailhost.india.com (simba-4 [157.95.25.213]) by
          Simba.India.Cypress.Com (8.9.3/8.9.3) with ESMTP id RAA22346 for
          <megaco@standards.nortelnetworks.com>; Fri, 30 Jun 2000 17:01:14
          +0531 (IST)
X-Sender: "B.S. Prasanna" <bsp@mailhost.india.cypress.com> (Unverified)
X-Mailer: Mozilla 4.7 [en]C-gatewaynet  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------7671EB869AEDB554A1494C4A"
Message-ID:  <395C8444.C1826781@mailhost.india.com>
Date:         Fri, 30 Jun 2000 04:28:04 -0700
Reply-To: bsp@cypress.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "B.S. Prasanna" <bsp@cypress.com>
Organization: Cypress Semiconductor Corp.
Subject:      On line membership
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------7671EB869AEDB554A1494C4A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

Can I become on line member for Megaco now??

Prasanna

--------------7671EB869AEDB554A1494C4A
Content-Type: text/x-vcard; charset=us-ascii;
 name="bsp.vcf"
Content-Description: Card for B.S. Prasanna
Content-Disposition: attachment;
 filename="bsp.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Prasanna;B S
tel;fax:+91 80 343 8679
tel;work:+91 80 353 0132 Extn 246
x-mozilla-html:FALSE
url:http://www.cypress.com
org:Cypress Semiconductor Technology India Pvt. Ltd
version:2.1
email;internet:bsp@cypress.com
title:Director - DCD India
adr;quoted-printable:;;Sharada Towers I & II Floor =0D=0A56, Nandidurg Road=0D=0ABenson Town;Bangalore;Karnataka;560 046  ;INDIA
fn:B S Prasanna
end:vcard

--------------7671EB869AEDB554A1494C4A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 30 14:30:48 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23643
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 30 Jun 2000 14:30:47 -0400 (EDT)
Received: from standards (47.234.32.16:4321) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79EBC@standards.nortelnetworks.com>; Fri, 30 Jun 2000 14:20:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2206 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 14:20:34 -0400
Received: from mailcity.com (209.1.236.7:43808) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB79EBB@standards.nortelnetworks.com>; Fri, 30 Jun 2000 14:20:34
          -0400
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri Jun 30 11:29:47
          2000
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
X-Sender-Ip: 216.6.88.34
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Message-ID:  <OCCGANLGLFKDCAAA@mailcity.com>
Date:         Fri, 30 Jun 2000 11:29:47 -0700
Reply-To: hussainmf@mailcity.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hussain F Mohammad <hussainmf@mailcity.com>
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Subject:      Modifications in Local and Remote descriptors.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

HI,
The interpretation of the contents of local and remote descriptor along with reserve
properties define the action to be taken at MG . Is it true that this modiciation of local
(remote) descriptor is done only during the inital call setup phase or can be it
be done on the fly (other than codec) when the call is through.
If yes, what will be the mode (in local control descriptor) when local/remote descriptor
information is modified?(as any mode other than Inactive seems to be illogical)
-HFM


Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 30 14:55:03 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24211
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 30 Jun 2000 14:55:02 -0400 (EDT)
Received: from standards (47.234.32.16:4321) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79F09@standards.nortelnetworks.com>; Fri, 30 Jun 2000 14:44:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2306 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 14:44:56 -0400
Received: from qhars002.nortel.com (47.101.112.102:37335) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB79F08@standards.nortelnetworks.com>; Fri, 30 Jun 2000
          14:44:56 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Fri, 30 Jun 2000 19:54:02 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Fri, 30 Jun 2000 13:40:46 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <NQCK3XNQ>; Fri, 30 Jun 2000 13:42:26 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <28560036253BD41191A10000F8BCBD11480B32@zcard00g.ca.nortel.com>
Date:         Fri, 30 Jun 2000 13:42:30 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Modifications in Local and Remote descriptors.
X-To:         "hussainmf@mailcity.com" <hussainmf@mailcity.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The Local and Remote descriptors can and will be modified at various points
in a call.  The MGC sets the mode at any point depending on the current
situation.   Are you thinking of a transient situation at the MG as it
implements the altered descriptors, when you talk about the mode logically
being "inactive"?

> -----Original Message-----
> From: Hussain F Mohammad [SMTP:hussainmf@MAILCITY.COM]
> Sent: Friday, June 30, 2000 2:30 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Modifications in Local and Remote descriptors.
>
> HI,
> The interpretation of the contents of local and remote descriptor along
> with reserve
> properties define the action to be taken at MG . Is it true that this
> modiciation of local
> (remote) descriptor is done only during the inital call setup phase or can
> be it
> be done on the fly (other than codec) when the call is through.
> If yes, what will be the mode (in local control descriptor) when
> local/remote descriptor
> information is modified?(as any mode other than Inactive seems to be
> illogical)
> -HFM
>
>
> Send FREE Greetings for Father's Day--or any day!
> Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jun 30 15:18:27 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24693
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 30 Jun 2000 15:18:27 -0400 (EDT)
Received: from standards (47.234.32.16:4321) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79F2D@standards.nortelnetworks.com>; Fri, 30 Jun 2000 15:08:23 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2352 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 15:08:22 -0400
Received: from mailcity.com (209.1.236.7:61401) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB79F2B@standards.nortelnetworks.com>; Fri, 30 Jun 2000 15:08:22
          -0400
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri Jun 30 12:17:46
          2000
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
X-Sender-Ip: 216.6.88.34
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Message-ID:  <LKDNEBALJPMDCAAA@mailcity.com>
Date:         Fri, 30 Jun 2000 12:17:46 -0700
Reply-To: hussainmf@mailcity.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hussain F Mohammad <hussainmf@mailcity.com>
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Subject:      Re: Modifications in Local and Remote descriptors.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

 My Intention here is in the modification of IP address and the Port number used for the ephemeral termination. Can that be done while media is through??OR mode any thing other than Inactive
--

On Fri, 30 Jun 2000 13:42:30
 Tom-PT Taylor wrote:
>The Local and Remote descriptors can and will be modified at various points
>in a call.  The MGC sets the mode at any point depending on the current
>situation.   Are you thinking of a transient situation at the MG as it
>implements the altered descriptors, when you talk about the mode logically
>being "inactive"?
>
>> -----Original Message-----
>> From:        Hussain F Mohammad [SMTP:hussainmf@MAILCITY.COM]
>> Sent:        Friday, June 30, 2000 2:30 PM
>> To:  MEGACO@STANDARDS.NORTELNETWORKS.COM
>> Subject:     Modifications in Local and Remote descriptors.
>>
>> HI,
>> The interpretation of the contents of local and remote descriptor along
>> with reserve
>> properties define the action to be taken at MG . Is it true that this
>> modiciation of local
>> (remote) descriptor is done only during the inital call setup phase or can
>> be it
>> be done on the fly (other than codec) when the call is through.
>> If yes, what will be the mode (in local control descriptor) when
>> local/remote descriptor
>> information is modified?(as any mode other than Inactive seems to be
>> illogical)
>> -HFM
>>
>>
>> Send FREE Greetings for Father's Day--or any day!
>> Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct
>


Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct